Final Documentation (G-9)

Dormitory and Cafeteria System for Wolaita Sodo University
WOLAITA SODO UNIVERSITY

COLLEGE OF NATURAL AND COMPUTATIONAL SCIENCE
DEPARTMENT OF COMPUTER SCIENCE AND INFORMATION

TECHNOLOGY
Project Title: - Dormitory and Cafeteria System for Wolaita Sodo University
GROUP MEMBERS ID_No
1. Elilta Hagos NSC/R/410/04
2. Erediat Yalew NSC/R/427/04
3. Fentahun worku NSC/R/468/04
4. Jemal usman NSC/R/627/04
5. Kidist siasb NSC/R/674/04
Advisor: Feven Teferi
Submitted to Department of Computer Science and Information Technology, college of Natural

and Computational Science, Wolaita Sodo University, in partial fulfillment for the requirement of
the degree of bachelor science in (CSIT)
Wolaita Sodo, Ethiopia
Submission date 08, 10, 2007 E.C
WSU-CSIT@Group-9 Page 1
Abstract
The main objective of this project is to develop Dormitory and cafeteria System for wolaita Sodo
University to enable the student’s dorm placement on the web and preparing the students
cafeteria menu. The project will purposely do on automating the manual functioning of the
Dormitory and cafeteria system of WSU. The implementation of this project is by using
application such as HTML, MySQL, PHP and JavaScript and some other applications that are
needed for our project. The system that we want to develop for wolaita Sodo University is simple
graphical user interface, so that the students or the users can use and interact with the system in
simple way and students’ friendly manner by preparing the form that the students profile are
inserted to it for accessing the system database. The form that we will prepare can be inserted the
students’ information which is needed to access the system database. This project examines how
the system flow and work process in Dormitory placement and menu preparation of student
cafeteria by web based application.
Acknowledgement
We are grateful to our project advisor mis Feven T. for the guidance, inspiration and
constructiveness the team and idea generation which is helpful for the preparation of this
proposal and documentation.
ABBRIVATION
WSU Wolaita Sodo University
PHP Hypertext per processor
HTML Hypertext markup language
WAMP Window Apache MySQL PHP
MYSQL Microsoft structural query language
CD-RW Compact Disk rewritable
CSS cascading style sheet
RAM Random Access Memory
FBE faculty of business and economics
NSC Natural science and Computational
UML unified modeling language
COM cafeteria office manager
POM proctor office manager
DSTV digital satellite Television
SRS System Requirement Specifications
UC use case
Table of Contents
Abstract............................................................................................................................................ii
1.1 Introduction...........................................................................................................................1
1.2 Background................................................................................................................................2
1.2.1 Background of the organization..........................................................................................2
1.2.1.1 Motivation:.....................................................................................................................2
1.2.1.2 Background of the project................................................................................................2
1.3 Statement of the Problem...........................................................................................................3
1.4 Team Composition................................................................................................................4
1.5 Objectives of the project.......................................................................................................5
1.5.1 General Objective...............................................................................................................5
1.5.2 Specific objective................................................................................................................5
1.6 Scope of the Project..............................................................................................................5
1.7 Methodology and Development Tools..................................................................................6
1.7.1 Data Collection Mechanisms..............................................................................................6
1.7.2 Tools....................................................................................................................................7
1.7.2.1 Software........................................................................................................................7
1.7.2.2 Hardware......................................................................................................................7
1.8 Cost of project.......................................................................................................................8
1.9 Limitation of the Project.......................................................................................................8
1.10 Time schedule of the project.................................................................................................8
1.11 Reference..............................................................................................................................9
CHAPTER TWO...........................................................................................................................10
2. Description about the existing system.......................................................................................10
2.1 Introduction..............................................................................................................................10
2.2 Players in the existing system..................................................................................................10
2.3 Major function or activities in the existing system..................................................................11
2.3.1 Inputs in existing system...................................................................................................11
2.3.2 Work flow of the dorm placement....................................................................................12
2.3.3 Outputs in existing system................................................................................................13

2.4 Business rules..........................................................................................................................13
2.5 Reports Generated in the existing System...............................................................................14
2.6 Forms and other documents of the existing system.................................................................15
2.7 Bottlenecks of the existing system...........................................................................................16
2.8 Practices to be preserved........................................................................................................16
2.9 Alternative options to address problems of the existing system............................................16
2.10 Requirements of the proposed system..................................................................................17
2.10.1 Functional requirement..................................................................................................17
2.10.2 Non-functional requirement...........................................................................................17
CHAPTER THREE.......................................................................................................................19
3. SYSTEM ANALYSIS...............................................................................................................19
3.1 Introduction..............................................................................................................................19
3.2 System Requirement Specifications (SRS)..............................................................................19
3.2.1 Use Case diagram.................................................................................................................19
3.3 Sequence diagrams..................................................................................................................26
3.4 Activity diagram......................................................................................................................30
3.5 Class Diagram...........................................................................................................................36
3.6 User Interface Prototyping......................................................................................................37
CHAPTER FOUR..............................................................................................................................38
4 System Design............................................................................................................................38
4.1 Introduction.........................................................................................................................38
4.2 Class type architecture.........................................................................................................38
4.2.1 User interface layer.......................................................................................................38
4.2.2 Process layer..................................................................................................................39
4.2.3 Business or Domain layer..............................................................................................39
4.2.4 Persistence layer............................................................................................................39
4.2.5 System layer..................................................................................................................39
4.3 Class modeling.....................................................................................................................40
4.4 State chart modeling.............................................................................................................41

4.5 Collaboration modeling........................................................................................................43
4.6 Component Modeling...........................................................................................................44
4.7 Deployment modeling..........................................................................................................44
4.8 Persistence modeling............................................................................................................45
4.9 User Interface design...........................................................................................................47
4.9.1 Homepage......................................................................................................................47
4.9.2 Login user interface.......................................................................................................48
4.12 Student Cafeteria Menu.........................................................................................................50
CHAPTER FIVE...........................................................................................................................53
5.1 Implementation and testing......................................................................................................53
CHAPTER SIX..................................................................................................................................70
6.1 Conclusion...............................................................................................................................70
6.2 Recommendation.....................................................................................................................70
References......................................................................................................................................71
1.1Introduction
Management is one of the difficult and complex works around the world. Every organization
needs talent management system to facilitate the work and achieve the goals of that institute
especially to manage resource and personal activities it needs to use the computerized system as
well, due to this WSU has its own management system in student cafeteria and dormitory
placement, both systems that the university used currently is totally manual. So our objective
from this proposed project we try to improve these manual forms into automated system.
1.2 Background
1.2.1 Background of the organization

Wolaita Sodo University is one of the governmental higher universities founded in Ethiopia in
southern part of the country in Sodo area. It was established on 1999. The university has 6
colleges, 3 schools and 41 undergraduate programs, 11 graduate programs and 1Phd.
1.2.1.1 Motivation:
As the other universities WSU have its own student management system in dormitory and
cafeteria. But the system is totally worked in manual system. It must be needed to automate the
system of the existing system.
At the beginning of the year students are confused by the dorm placement because it is very
complicated and that has no any regular format to place the student in the dormitory. In each
every year the students and dormitory workers are confused by the placement. From this serious
issue we are initiated to develop the automated system about the student placement in dorm and
to be more informed and announcing the student’s cafeteria menu for WSU. Our automated
system needs the students profile from the registrar and buildings profile from the proctor and
develop the system based on the information we are listed before.
1.2.1.2 Background of the project

Background of our project has already manual system which is needed many things those are
materials and workers with takes long period of time. The system is done the activities by paper
each and every thing. It means that the existing system is done the activities in such away:-
firstly receive the students file from the registrar office then determine the students sex,
department and batch by the proctor office after that sort each students by considering the above
listed things which means sex, department and batch then assign the students in each dorm, for
one dorm six students must be available and each student is assigned accordingly by paper and
pen or by the hand of human power(employees). After that the paper is attached to its building or
block. This is the manual system sequential activity of the dormitory placement when we see that
of the student cafeteria menu there is no displayed menu before now. Generally, the manual
system is activating the works in such away. So our main objective is that preparing the
automated system for the area of dormitory and cafeteria for WSU.
1.3 Statement of the Problem

Today in the 21st century every activity is done by the help of computerized system or automated
system, even though anything which is done anywhere that is already known by the genuine
technology rather WSU has no any automated system for dormitory placement and student
cafeteria menu it is totally manual system. Due to this the institute has face some categorized
problems.
 Time:
The existing system is totally done by manual system to place the student dorm and announcing
the cafeteria menu, so the system takes more time, tedious and complicated to run it for the
students and workers.
 Resource:
It needs high energy or human powers to do the activity around the student management system
in dormitory and cafeteria or to reduce the human power we must be automate the system. In
addition to this it requires much more resource like paper and pen.
 Lose of Data
When the paper is lost all the data recorded on that paper is destroyed or loss. Finally the
students do not get relevant data. Generally the student files are fully risky because it has not any
computerized or moderate system to keep the data lost.
1.4. Team Composition

Name ID No Phone & Email Team responsibility
0918590371 Project manager

Fentahun worku www.fentahun21wor
NSC/R/468/  Establish the sequence activities to meet
ku@gmail.com
04 delivery dates.
 Generally, work the overall management

system.
0910329400 System analyzer

www.kidistsias@gm
NSC/R/ 674  Coordinates preparation reports through
ail.com
Kidist siasb /04 gathering, analyzing and summarizing
data and information from the team and
providing support project manager.
0940198172 Programmer
www.redi12yalew@
 Arranges project requirements in
gmail.com
Erediat Yalew NSC/R/427/ programming sequence by preparing a
04 code using knowledge of programming
language.
0910680053 Designer
Elilta Hagos NSC/R/410/ www.eluhagos@gma
 Develop design documentations.
04 il.com
 Prepare design layouts and sketches according
to design standards.
0924549213 Tester
Jemal usman NSC/R/627/ www.jemalusman62
 Analyses the application functionality with
04 7@gmail.com
requirement documents like functional
requirement Specification documents.
Table 1.1: table of team composition
1.4 Objectives of the project
1.5.1 General Objective

Our proposed system mainly aims to change current manual system to automated system, to
make the system fast and easy to access.
1.5.2 Specific objective

 To design the automate system regarding to student management system in WSU.
 Develop the forms with functional buttons displayed on the webpage which is the
students are insert there profile and retrieve or access the wanted data.
 To build the students record on the database.
 Develop the building, dorm and bed records.
 Develop dynamic webpage to display the student’s cafeteria menu in our web based
system.
1.5 Scope of the Project
The scope of the project is the boundary of the project. So after we are developing the
system we have the hope handle the following difficulties.
 The system will have large Storage Capacity of students profile, building and dormitory
profile on the database.
Personal information for the students such as:
 Student name
 Student ID No
 Students sex (male or female)
 Department of the student and also

Building profile as well, such as:
 Block Number
 Dorm Number
 Quick search facility for the users (students) if the user (student) has been entered the
relevant information means that he/she type the correct name and department the system
replay the student’s dorm placement and any one can access the databases easily by using
the graphical interfaces with simple computer knowledge and also everywhere when it is
connected to the internet.
 Make Computerize all the activities of the system, so it makes Easy to update the students
profile and also provide all necessary services for databases such as updating and
searching information.
 Delete and retype the student profile when the student has been leaved in the
organization or institution by any means.
 In the cafeteria we will try to develop the dynamic webpage for displaying the students’
cafeteria menu or preparing a menu on the web.
1.6 Methodology and Development Tools
1.7.1 Data Collection Mechanisms

Information is one of the major requirement for accomplish our project. So, we went to use the
student dormitory and student cafeteria of Wolaita Sodo University to collect information. As all
of us know there are different mechanisms to gather information. Such as, document analysis,
interview and observation. We prefer the two methods, as we think as they used us to collect the
major information. These are:
 Observation:
As the student of the university we have ours dorm and we are eating in the cafeteria so we know
it. We will be used in order to analyze the conditions to which the current system is acting. It is
useful to observe how jobs are done. By being observing the way they used to perform the
required student dorm placement, we will acquire the information we need.
 Interview:
The team used open ended questionnaires by direct contact with the proctor office manager and
student cafeteria manager.
1.7.2 Tools
1.7.2.1 Software
Tools Activities
MySql To record the students and building profiles.
PHP Used to create pages and user forms.
HTML and CSS For designing the style sheet.
WAMP Used as a server.
Microsoft office For the documentation.
Java script For validate the forms.
StarUML, Edraw, For UML Diagram
Microsoft visio 2013
Table 1.2 software tools
1.7.2.2 Hardware
CD/RW
Pen
Paper
printer
Computer: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz processor and 2.00 GB (1.88 GB
usable) installed memory or RAM.
1.7 Cost of project
Item name Quantity Price /Unit Total price

Paper 1 packet 100 birr 100 birr
Pen 5 5 birr 25 birr
Print 75 pages 2 birr 150 birr
CD-RW 5 30 birr 150 birr
Total price 425 birr
Table 1.3: cost of the resource
1.8 Limitation of the Project

Our project has the following limitation:
 It does not check the academicals status of the student.

 For first year student the dorm placement is not in its department, because in some
colleges the student does not know those departments. Such as college of engineering,
college of NCS, college of other social science, school of FBE and school of Agriculture.
 Students those are disabled are not placed in special case before they are asked, but after
the disabled students are inform we can placed in special case.
1.9Time schedule of the project

Phase Task Date
I Proposal Nov 03, 2007-Nov 15, 2007
II Requirement specification Nov 17, 2007-Dec 02, 2007
III System Analysis Dec 04, 2007-Dec 27, 2007
IV System design Dec 30, 2007-Jan 12, 2007
V Implementation Jan 14, 2007-
Table 1.3: schedule of the project
1.10 Reference
 OOSAD course Object-Oriented Systems Analysis and Design Joey F. George, Dines
Bart, Joseph S. Valacich, Jeffrey A. Hoofer.
 A guide to the project management body of knowledge (PM BOOK Guide)- project
management institute, Pennsylvania, USA, Edition 2000
 Proposed resolution on guidelines for remuneration to senior executives, item 14
CHAPTER TWO
2. Description about the existing system
2.1 Introduction
Wolaita Sodo University manual system is used for managing the various activities and services
in dormitory and cafeteria system. So we shall to describe the major functions of the existing
system. Its main features of the current system are contains large amount of student’s, buildings
and dorms data can maintain in manual way. The basic operations on the system are like adding
new students, buildings and dorms, searching and updating information’s, deleting student’s
information in traditional way (i.e. paper based). It take a lot of time to search particular student
and dorms even if buildings (i.e. searching is difficult and time consuming), no proper record of
data’s and retrieve a particular data is very slow and time consuming.
2.2 Players in the existing system

The Existing system has many employees that are responsible for different tasks. Those are:
1. Student dean
 Receive the report from the proctor office manager. Like dorm placement of
student.
 Receive the question from student union like cafeteria improvement.
2. Proctor office manager
 Manage the proctors those are worked in each building.
 Control the overall works around dormitory.
3. Proctors in each building
 Control the students those are allocated to the dorm in each indicated block and
dorm number.
 Manage the dorm materials such as chairs, tables, bed, pillow, foam and lockers
are must be fulfilled in each dorm.
4. Students or users
 View the block and dorm placement then the students are distributed to the dorm.
 View or access the cafeteria menu.
5. Student cafeteria manager
 To prepare the cafeteria menu by considering the input resource and consumed
materials or foods.
2.3 Major function or activities in the existing system

The WSU dormitory system has major functions or activities each activity has their own input
and output. The inputs are used as a row material for the result of the activities or output.
2.3.1 Inputs in existing system
The whole process of the existing system is done by manually or paper based. The inputs in the
system are:
 students profile
 building profile
 menu prepare inputs
 The students profile that are used as an input are:
o Name
o ID No
o Sex
o Department
o Batch
 The building profile that is used as an input is:
o Building ID or number
 The dorm profile that is used as an input is:
o Dorm Number
 The cafeteria menu can be used as an input like:
o Days of the week
o Food contents.
2.3.2 Work flow of the dorm placement

To make the entire student dorm placements depend on the student’s data receiving from student
dean and to consider input resource or consumed materials to student then to distribute the
following requirement.
 Student dean: generates the student data to proctor office manager.
 Proctor office manager: distributes the students profile to the block proctor.
 Block proctor: - placed the students in the specific dorm number.
- Check up the dorm materials.
2.3.2.1 Distribute the students profile to the block proctor

The student’s data or profiles are distributed by the proctor office manager to each of the block
proctor. After the student’s data reached to the block proctor, the block proctor must be assigned
students in to each dorm number.
2.3.2.2 Register the blocks

The employers must write department with respect to the block number which is assigned for
those department students by according to their sex. This paper is posted to somewhere around
the university gate door. And also in every block, the block proctor is list out the students name
and their placement dorm number by paper and posted around the building. In one block or
building more than one department students can be contained.
2.3.2.3 Register the students

 The students must be search the dorm number that is assigned for him/her.
 Report to the block proctor to get the keys of that dorm by the student’s university formal
ID card.
 Checking the materials which are available for that dorm those are chair, table, chipud,
pillow, foam, bed, locker and bed ladder.
2.3.2.4 Check up the Dorm materials

The block proctors are checking up the dorm materials in to two phases, before and after the
students are come to the university or campus.
 Before the students came to the university, the block proctor check up all materials in
each of the dorm.
 After the students are come to the university, block proctor must be checking the
materials with the students those are placed in that specific dorm number for more
evident within the students.
2.3.3 Outputs in existing system

Outputs in the manual system of dorm placement in WSU are:-
 After searching or finding the dorm number the students are reached to the appropriate
dorm placement.
 Checking the materials which must be provided in the dorm or fulfilled the dorm
materials.
 Menu is announced for the cafeteria employees.
2.4 Business rules

In every organizations or institutions there are rules and policies, which are used to govern all
activities in specified workflow and control the workflow performed in the working
environment.
The following are the rules and regulation around dormitory placement and cafeteria menu
preparation of WSU:
 The students must be regular and summer university student.
 Male and female students can’t live together.
 In one dorm more than six students are forbidden.
 Every student must be live with their assigned dorm number, except some special
problems.
 Except first year students, the students must be live with their department student.
 The students those are some disables are assigned in the first floor of the building.
There is a consideration to prepare the student cafeteria menu such as:
 The total budget of student cafeteria in the university must be considered

primarily.
 The total consumption of the student in each day with respect to food content.
Those are the main consideration for preparing the students cafeteria menu.
2.5 Reports Generated in the existing System

The flow of report in the dormitory management system has been done in two ways:
 From the block proctor to the proctor office manager and
 From the proctor office manager to the student dean office.
That means block proctor has formulate the report to the proctor office manager and the proctor
office manager also formulates the report to the student dean because the block proctor is
responsible for proctor office manager and the proctor office manager is responsible for the
student dean.
The reports that are generated from block proctor to proctor office manager is considered the
cases especially when some problems are happened and the report from proctor office manager
to student dean has formal report schedule in each three months except some unexpected and
grave problems are not happened.
The report that generates from block proctor to proctor office manager, when the following
thoughtful problems are happened like:
 The shortage of dorm in the block.
 The dorm materials are not fulfilled.
 Other related problems like: toilet, water and DSTV room problems.
Report generates from proctor office manager to the student dean when:
 The report which is derived from the block proctor and that problem isn’t solved by
the proctor office manager.
Finally this report is important for the university to handle the problems around the dorm
materials and related complications which is reported to the student dean. The university
respects that problem as a feedback for minimizing the scarcity of services.
2.6 Forms and other documents of the existing system

There is a form in the existing system which is used for place the students in the dorm by
recording the necessary information’s from the students, such as student name, ID No, block No,
Dorm No and materials which is providing in that dorm such as chair, table, locker, foam, pillow,
bed, bed ladder and original dorm key.
The form in fig 2.1 below is the dorm placement agreement form between the student and the
block proctor.
Fig 2.1: WSU students’ dorm placement form
The student cafeteria menu has no any form at all currently.
2.7 Bottlenecks of the existing system

The existing or manual system of student dormitory placement and cafeteria menu preparation
has many bottlenecks. For example as we are told before the block proctor has grouping the
students by six members to allocate those dorm number is very complicate to do in simple way.
So, our automated system eliminates the bottlenecks of the existing system. The following are
the bottlenecks of the existing system.
2.7.1 Response time: - everything in the existing system has done manually, so as a manual
system it takes time to do every single activity like searching block No and student dorm No.
2.7.2 Input/output bottlenecks: - as we try to explain above the main inputs of the existing system
are the students’ sex and the whole information about the students. The recording method is very
tedious and wastage of material such as paper and pens.
2.7.3 Efficiency related problem: - the students those have the different sex doesn’t placed together
in the same dorm, but sometimes this problem has been occurred.
2.8 Practices to be preserved

The existing manual system of student dorm placement and cafeteria menu preparation has its
own strength. Its strengths must be preserved to enhance the automated system. The following
strengths are outlined to be preserved in the automated system.
 As we are listed from the above the existing system has use some input profiles like
students name, ID No, batch, department and sex. Those are also important for our
automated or proposed system.
 Students are placed in the dorm by considering sex, name, batch and ID No of the
students.
 In one dorm not more than six students can be placed.
2.9 Alternative options to address problems of the existing system

The problems those are placed in the above sub title under bottlenecks of the existing systems are
trying to handle in the automated systems. Those are:
 Developing large storage capacity of databases to store all the students’ data.
 Simple searching of building and dorm number.
2.10 Requirements of the proposed system

Requirements of the new system can be categorized in to Functional and Non-Functional.
2.10.1 Functional requirement

Functional requirements capture the intended behavior of a system and it defines what a system
is supposed to do.
Therefore the following functional requirements are stated for the new automated system.
 It has login form in some authors except students, because students have their own
form to access the database on the system.
 It displays the student block and dorm numbers.
 The system administrator can create, remove and update account.

 The users or students can access the database by inserting the information on the
provided form.
 The officer can insert, delete and update the students and blocks information.
 The students or users can access the cafeteria menu.
2.10.2 Non-functional requirement

Non-functional requirement is a requirement that specifies criteria that can be used to judge the
operation of a system, rather than specific behaviors. It is simply things that our system may not
include as functional requirement. Some of the non-functional requirement listed below:
2.10.2.1 Performance
The system should work properly with its storage capacity, accuracy, speed and the likes.
2.10.2.2 User Interface

The developed software should be user friendly by making it easily accessible.
2.10.2.3 Compatibility
The system would be fully compatible with different type of browser like Microsoft Internet
Explorer, Mozilla Firefox, opera mini and Google chrome.
2.10.2.4 System modification

The system can be modified when every the authorized body needed to modification.
2.10.2.5 Response time
The automated system will have a great response time it access with a fraction of minute.
2.10.2.6 Portability
The system needs to be portable on all major platforms. This system should not be restricted by
any specific technology such as operating system.
2.10.2.7 Reliability
Reliability is the probability that the system will be able to process work correctly and
completely without being aborted.
2.10.2.8 Recoverability
Our system is the ability to restore function and data in the event of a failure.
2.10.2.9 Backup and recovery requirement:
The process of backing up refers to the copying and archiving of computer data by using
removable storage media such as Disk, CD-R and CD-RW so it may be used to restore the
original data after a data loss event is performed by our system.
2.10.2.10 Security
The security Section describes the need to control access to the data. This includes controlling
who may view and alter application data by using strong password on the system.
2.10.2.11 Maintainability
Our system has been easily maintained when some difficulty or problems will occur. This covers a
wide variety of activities, including removing program and design errors, updating documentation and
test data and updating user support in Adaptive Maintenance.
CHAPTER THREE
3. SYSTEM ANALYSIS
3.1 Introduction
Systems analysis is a process of collecting actual data, understand the procedures involved,
recognizing problems and recommending practicable suggestions for improving the system
functioning. This involves studying the business processes, gathering operational data,
understand the information flow, finding out bottlenecks and developing solutions for
overcoming the weaknesses of the system so as to achieve the organizational goals. System
Analysis is also includes sub-dividing of complex process involving the complete system,
identification of data store and manual processes.
The major objectives of the system analysis are to find answers for each business process. It
focuses on what is being done, How is it being done, who is doing it, When is he/she doing it,
Why is it being done and How can it be improved? It is more of a thinking process and involves
the creative skills of the System Analysis. It gives a new well organized system that fulfills the
current needs of the user and has scope for future evolution within the organizational constraints.
The result of this process is a logical system design. Systems analysis is an iterative process that
continues until a preferred and acceptable solution occurs.
3.2 System Requirement Specifications (SRS)
3.2.1 Use Case diagram

Use cases are used during requirements elicitation and analysis to represent the functionality of
the system. It describes what a system does from the viewpoint of an external observer. A use
case describes a function provided by the system that yields a visible result for an actor. An actor
describes any entity that interacts with the system.
3.2.1.1 Actors identification

Actor classes are used to model and represent roles for "users" of a system, including human
users and other systems. Actors are denoted as stick person icons. In our proposed system there
are seven actors which participating with system. The following are the actors of the proposed
system.
 Admin: A person, who manage over all the system’s activity and Administrator.
 Student and Student union: Those are the users or beneficiaries of the system and
student union can generate student cafeteria menu.
 Officers (COM and POM): are actors produce student cafeteria menu and dorm
placement in the system respectively.
 Proctors and cafeteria workers: are access the database and view student cafeteria
menu respectively.
3.2.1.2 Use case identification

A use case represents a function that the system performs. Alternatively, a use case can be
thought of as a goal that some actor can achieve with the system. Identifying use case uses to
visualize the overall system functions and the actors interacting with use cases. By concerning
this concept our project identifies the following use cases.
 Login/Logout
 Manage account
o Create account
o Delete account
o Update account
 View placement
o View Block number
o View Dorm number
 Generate menu
 Generate report
 View menu
3.2.1.3 Defining Use case

 Login/ Logout: authenticates and authorizes users it accepts username and password.
 Manage system: admin create, delete and update user account according to their situation.
 View placement: students and proctors can view block and dorm number by their access
privilege.
 Generate menu: cafeteria office manager and student union can generate student cafeteria
menu
 Generate report: COM, proctor and student union can generate report to concerned body.
 View menu: the students and cafeteria workers can view the student cafeteria menu.
3.2.1.4 A use case diagram contains four components
 Boundary: This defines the system of interest in relation to the world around it.
 Actors: usually individuals involved with the system defined according to their roles.
 Use cases: are the specific roles played by the actors within the system.
 The relationships between and among the actors and the use cases.
Our use case diagram looks as follow
Fig 3.1 use case Diagram
3.2.1.5 Use Case Documentation
Use case name Login(uc-01)

Actors Administrator, proctor office manager and proctor, cafeteria
office manager.
Description This use case permits qualified user to login to the system.
Precondition The user must have user name and password
Post condition The system determines suitability.
Event flow 1. User wants to login to the system.
2. The system display "Login Screen".

3. The user’s fill user name and password.
4. The system validates the user.
5. The use case ends when “main menu screen" activates.
Alternative solution Use name and/or user password not valid
1. The system confirms to re-enter Account information.
2. The system informs the user as his/her information is wrong.
3. Use case continues as step 3 of the basic course of action.
4. Use case ends.
Table 3.1 description of login in the system
Use case name Create account(uc-02)

Actor Administrator
Description Describe in detail, create user account for users of the system.
Precondition  The admin must login to the system
 The system displays services home page
Post condition New account and new user can be added to the system.
Event flow 1. Admin click on the create account link from the main
home page.
2. The system displays the registration page.
3. Admin fill all the information’s needed.
4. Admin click register button.
5. The system validates the information’s.
6. The system displays successful message.
7. Use case ends
Table 3.2 description about the create account
Use case name Remove account(uc-03)

Actor Administrator
Precondition
 Administrator must be suitable to login.
 The existed account is invalid or not functional.
Post condition The account has been removed or deleted from the system.
Event flow 1. The admin click on the delete account link on the
administrator page.
2. Select the account which is deleted then click on
delete.
3. The system validates the deletion.
4. The system displays the successful message.
5. Use case ends.
Table 3.3 description about the removal of account
Use case name Update account (uc-04)

Actors Administrator
Precondition  The admin must login to the system
 The system displays services home page

Event flow 1. Admin Click on the update link from the administrator
Home page.
2. The system displays the update page.
3. Select the updated account
4. Admin Click update button.
5. Use case ends.
Post condition The system displays the successful message.
Table 3.4 describe about updating of account
Use case name View placement(uc-05)

Actors Students and proctors
Description The system displays the block and dorm number.
Precondition He/she must be fill the form provided from the system.
Post condition The system displaying the block and dorm number.
Event flow 1. The student click on the system home page.
2. The system displays the form.
3. Fill the information on the form provided.
4. Press the button view placement.

5. The system displayed block and dorm number.
And also proctor can be view the student placement by
his/her login account.
1. The Proctor is login to the system
2. Select database name which authenticated for the
specific proctor
3. Click on view data base
4. Display the database on the system page.
5. Use case ends.
Table 3.5 describe about databases access privilege.
Use case name Generate menu(uc-06)

Actor Student union and Cafeteria office manager(COM)
Description Display the student cafeteria menu on the system.
Pre-condition COM login to the system.
Event flow 1. COM click on the cafeteria menu link page
2. click on update link in the cafeteria menu link page
3. COM updates menu
4. Use case ends
Table 3.6 describing the generating student cafeteria menu
Use case name View menu(uc-07)

Actor Student union, students, cafeteria worker
Event flow 1. Open the system by using url
2. Click on cafeteria menu link page
3. View the menu
4. Use case ends
Table 3.7 description of accessing cafeteria menu
Use case name Generate report (uc-08)
Actors POM, proctor and student union
Description Sending report to the other actors
Work flow 1. Actors Click on the generate report link from the Home
page.
2. The system displays the post report page.
3. Actors upload the report.

4. click on post button
5. The system displays successful message
6. Use case ends.
Table 3.8 Description of generate report
3.3 Sequence diagrams

Sequence diagrams are used to formalize the behavior of the system and to visualize the
communication among objects. They are useful for identifying additional objects that participate
in the use cases. We call objects involved in a use case participating objects. A sequence diagram
represents the interactions that take place among these objects.
Sequence diagram for login
Fig 3.2 Sequence diagram for create account
Fig 3.3 sequence diagram for create account
Fig 3.4 sequence diagram for update account
Fig 3.5 sequence diagram for update menu
Fig 3.6 sequence diagram for view placement
3.4 Activity diagram

An activity diagram describes a system in terms of activities. Activities are states that represent
the execution of a set of operations. The completion of these operations triggers a transition to
another activity. Activity diagrams are similar to flowchart diagrams in that they can be used to
represent control flow (i.e., the order in which operations occur) and data flow (i.e., the objects
that are exchanged among operations).
Fig 3.7 activity diagram for login
Fig 3.8 activity diagram for create account
Fig 3.9 activity diagram for update account
Fig 3.10 activity diagram for view placement of proctor
Fig 3.11activity diagram for view placement of student
Fig 3.12 Activity Diagram for update menu
3.5 Class Diagram

We use class diagrams to describe the structure of the system. Classes are abstractions that
specify the common structure and behavior of a set of objects. Objects are instances of classes
that are created, modified, and destroyed during the execution of the system. Objects have state
that includes the values of its attributes and its relationships with other objects. Class diagrams
describe the system in terms of objects, classes, attributes, operations, and their associations.
Fig 3.13 class diagram for our system
3.6 User Interface Prototyping
Fig 3.14 user interface prototype
CHAPTER FOUR
4 System Design
4.1 Introduction
System design is the process of defining the elements of a system such as the architecture,
modules and components, the different interfaces of those components and the data that goes
through the system. It is meant to satisfy specific needs and requirements of a business or
organization through the engineering of a coherent and well-running system. So, mainly this
phase concerned with the design part of our project to reduce the complexity of our system.
4.2 Class type architecture
4.2.1 User interface layer

The user interface layer represents the front end of the system web Client, and contains the actual
GUI (graphical user interface) elements that users view and click. The user interface is based on
a flexible activate application, hosted on the system web Client application server that runs in the
user’s Web browser.
The user interface of the system has been easy to use by each user of the system with little
training. Our interface contains different buttons which guide the users what to click and fill to
enter to their page to do what they want. So our system user interface is easy to use. We also do
our system clear which means the interface shows the user where to go in the system.
User Interfaces in our system are:

 Homepage
 Login
 Contact as
 Dorm placement form
 View menu
4.2.2 Process layer

The process layer defines the process steps, the sequence in which they are executed, the roles
that execute them, and how the context data of a process is passed between the process steps. A
process is designed using Guided Procedures. Guided Procedures is a frame for composing user-
centric process flows. It offers the means to bond diverse back-end applications and services into
a single business workflow. It provides role-based access to resources and guidance through the
workflows at runtime, thus, helping end users to identify and complete their tasks easily.
The process layer implements business logic that involves collaborating with several Sub domain
classes or even other process classes.
The business logic is the key element that control the workflow in the system such as our system
should check the placement request is from the student or not, this is checked by the controller or
process layer.
4.2.3 Business or Domain layer

It consists of entities, value objects, domain services and domain events. It focuses on the data
aspects of the business objects plus Behaviors specific to individual objects and the concept
related to the business domain focusing on the data aspects of the business.
4.2.4 Persistence layer

Persistence layer is any software layer that makes it easier for a program to persist its state. Most
persistence layers will not achieve persistence directly but will use an underlying database
management system. It provides persistence of the execution of a system, usually by writing its
state to files or to a database. For example our system uses MySQL database.
The purpose of our application's persistence layer is to use a session at run time to associate
mapping metadata and a data source in order to create, read, update, and delete persistent objects.
4.2.5 System layer

System layer provide operating system specific functionality for the applications, isolating the
software from the operating system by wrapping operating system specific features, increasing
the portability of the application developed.
Our system will be developed using dream weaver web builder and PHP programming language,
HTML and CSS for the style of the webpage. And also the system will perform its task on
WAMP server. On the other hand for database system MYSQL is needed to run the system.
Interface
(User interface, system interface)
Process
(Application, controller)
System
(Infrastructure
platform)
Domain
(Business)
Persistence
(Data)
Data sources of
the system
Fig 4.1 Class Type Architecture
4.3 Class modeling

The class model shows static class objects in a system and the relationships between them. Two
particularly important relationships are generalization or inheritance and aggregation or whole-
part. Each class object on the diagram often shows the class name, its attributes and operations.
Details like data types for attributes and arguments for operations can also be shown on the
diagram for some notations as follows:
Fig 4.2 class modeling diagram
4.4 State chart modeling

State chart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered. So
the most important purpose of State chart diagram is to model life time of an object from
creation to termination.
State chart diagram is used to describe the states of different objects in its life cycle. So the
emphasis is given on the state changes upon some internal or external events. These states of
objects are important to analyze and implement them accurately.
Fig 4.3 state chart diagram for Login
Fig 4.4 state chart diagram for view student dorm placement
4.5 Collaboration modeling

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.
Fig 4.5 collaboration diagram for user login
Fig 4.6 collabration diagram for student view placement
4.6 Component Modeling

The component model illustrates the software components that will be used to build the system.
Component model specifies the standards and conventions that are needed to enable the
composition of independently developed components. It is a set of agreements that is needed to
enable the composition of components. So our system component model is like:
Fig 4.7 Component Diagram of our system
4.7 Deployment modeling

Deployment diagram shows execution architecture of systems that represent the deployment of
software. Deployment diagram depicts a static view of the run-time configuration of processing
nodes and the components that run on those nodes.
Fig 4.8 Deployment diagram
4.8 Persistence modeling

Persistence are used the schema of database. The strength of persistence models is that data
entities are conceptually the same as the table of relation database and that attributes are the same
as table columns.
Persistence Model, entities can be talked about synonymously with the backing database tables
that hold the persisted information.
STUDENT
F.NAME M.NAME L.NAME ID_NO. Sex Department Dorm_No.
DORM
Dorm_NO. No bed BLDG_NO
BUILDING
BLDG_Name BLDG_NO. PR.ID
WORKS ON
PRO.ID D.NO.
PROCTOR
F.Name M.Name L.Name Proctor.ID. Sex Stud_ID
Fig 4.9 Database schema of Dormitory management system
4.9 User Interface design

4.9.1 Homepage
Fig 4.10 Homepage user interface
4.9.2 Login user interface
Fig 4.11 login user interface
4.11 view Dorm
Fig 4.12 View dorm
4.12 Student Cafeteria Menu
Fig 4.13 student cafeteria menu interface
4.13 create user account page
Fig:4.14 Create user account
4.15 user interface for generating menu
CHAPTER FIVE
5.1 Implementation and testing

Introduction
For the implementation and testing part we use a WAMP server to store the system data and
work as a server for the system. And also Dream waver web builder and notepad++ for writing
the source code and designing phase.
In this chapter we mainly focuses on the implementation part, implementation concerned with
the type of material (Hardware and software required), techniques to develop the system,
algorithm for the system, code samples of the system, data preparation, some testing techniques,
startup strategy for the new installed system are briefly described in this part of documentation.
5.2 Final Testing of the system
Testing includes the error result when the user accesses unprivilaged data or
activites in the system. Such as when the unauthorized person try to access the user
account the system display error message.
Sample PHP source codes
PHP Code for login
<?php
$conn=mysql_connect("localhost","root","") or die (mysql_error);
mysql_select_db("wsudcms", $conn);
if (isset($_POST['submitlogin'])){
$username=$_POST['username'];
$password=$_POST['password'];
$sql = "SELECT * FROM users WHERE username='$username' AND

password='$password'";
$result = mysql_query($sql);
$rowCheck = mysql_num_rows($result);
$row=mysql_fetch_array($result);
$status=$row['status'];
if($row['level']==1){
if($status==1)
{ $_SESSION['user_id']=$row['user_id'];
echo "<script>window.location='admin.php';</script>";
} else {
echo' Your Account is not active Please contact the system Admin';
echo' <meta content="4;login.php" http-equiv="refresh" />';
}} else if($row['level']==2){
if($status==1)
{ $_SESSION['user_id']=$row['user_id'];
echo' <meta content="1;pro_manager.php" http-equiv="refresh" />';
}else {
echo' Your Account is not active Please contact the system Admin';
}}else if($row['level']==3){
if($status==1){
$_SESSION['user_id']=$row['user_id'];
echo' <meta content="1;proctor.php" http-equiv="refresh" />';
}else {
}}else if($row['level']==4){
if($status==1) {
$_SESSION['user_id']=$row['user_id'];
echo' <meta content="1;cafe_manager.php" http-equiv="refresh" />';
}else {
}}else {
echo' ';
echo' Check Your username or/and Password';
}}
mysql_close($conn);
?>
PHP sample code for View Dorm
<?php
$conn=mysql_connect("localhost","root","") or die (mysql_error);
mysql_select_db("wsudcms", $conn);
if (isset($_POST['submitlogin'])){
$idno=$_POST['idno'];
$view=mysql_query("select * from students where stud_id='$idno'");
$row = mysql_num_rows($view);
if($row<1)
echo'The ID no is not found';
echo' <meta content="5;viewdorm.php" http-equiv="refresh" />';
}else{ while($row = mysql_fetch_array($view))
$fname=$row['fname'];
$mname=$row['mname'];
$dorm=$row['room_no'];
$block=$row['block_no'];
echo"<table align='center' style='border-radius:15px;border:1px solid

#336699;' width='250px' height='100px'>";
echo"<tr>";
echo"<th colspan='2' bgcolor='#336699'>".

$fname." ".$mname."<a href='viewdorm.php'><img align='right'
src='images/close_icon.gif'></a></th>";
echo"</tr><tr>";
echo"<td>Block No:</td><td>".

$block.'</td></tr>';
echo"<td>Room No:</td><td>".

$dorm.'</td></tr>';
echo"</table>";
} }
?>
PHP sample codes for Assign students in Dorm
<?php
if(isset($_POST['save']))
$block=$_POST['block'];
$sex=$_POST['sex'];
$batchs=$_POST['batchs'];
$sql= "SELECT * FROM `registrar` WHERE sex='male' and batch='4th Year' and
faculty='NCS'";
$result=mysql_query($sql);
$count=mysql_num_rows($result);
if($count<1)
echo('The requirements does not exist!');

echo'<meta content="5;assign.php" http-equiv="refresh"
/>';
} else{
for($i=1;$i<=8;$i++)
for($j=1;$j<=6;$j++)
{ $cnt=1;
while($row = mysql_fetch_array($result))
$r0=$row['fname'];
$r1=$row['mname'];
$r2=$row['lname'];
$r3=$row['stud_id'];
$r4=$row['sex'];
$sql=mysql_query("INSERT INTO students

(fname,mname,lname,stud_id,sex,batch,faculty,block_no,room_no)
VALUES
('$r0','$r1','$r2','$r3','$r4','$batchs','$faculty','$block','$j')");
if($cnt++%6==0)
break;
echo' success!';
echo'<meta content="30;assign.php" http-equiv="refresh"/>';
}}
?>
PHP sample code for View Student Cafeteria menu
<?php
$result = mysql_query("SELECT * FROM menu");
echo "<table width=450px border='1' cellpadding='5' bgcolor='#fffff' align='center'

width='650px'>;
<tr>
<td colspan='4'>
<div align='center' style='background-color:#336699;border-radius:5px;font-family:Arial,

Helvetica, sans-serif; color:#000000; padding:5px; height:22px;'>
WSU Student Cafeteria Menu
</td></tr>
<tr>
<th>Day of Week</th>
<th>Break Fast</th>
<th>Lunch</th>
<th>Dinner</th>
</tr>";
while($row = mysql_fetch_array($result))
echo "<tr>";
echo "<td>" . $row['Day'] . "</td>";
echo "<td>" . $row['BreakFast'] . "</td>";
echo "<td>" . $row['Lunch'] . "</td>";
echo "<td>" . $row['Dinner'] . "</td>";
echo "</tr>";
echo "</table>";
mysql_close($conn);
?>
PHP source code for Create user account
<?php
$conn=mysql_connect("localhost","root","");
mysql_select_db("wsudcms",$conn);
if(isset($_POST['save']))
$level=$_POST['actype'];
$password=md5($_POST['password']);
$cpassword=md5($_POST['confirmpassword']);
$query="SELECT * FROM users where username='$_POST[username]'";
$resultw=mysql_query($query);
$count=mysql_num_rows($resultw);
if($count==1){
while($row=mysql_fetch_array($resultw)){
$user=$row[8];
if($user==$_POST['username'])
echo' 
User Name is used by another user';
echo'<meta content="3;cua.php" http-equiv="refresh" />';
else
if($password==$cpassword)
$sql="INSERT INTO users (FNAME,mNAME,lname,user_id,sex,level,phone_no,username

,password,confirmpassword,status)
VALUES
('$_POST[fname]','$_POST[mname]','$_POST[lname]','$_POST[user_id]','$_POST[sex]','$_PO
ST[actype]','$_POST[phone]','$_POST[username]','$_POST[password]','$_POST[confirmpassw
ord]','1')";
if (!mysql_query($sql,$conn))
echo' Already Registered';
die('Error: '.'Already Exist'.mysql_error());
else
echo' Account is created successfully';
echo' <meta content="6;cua.php" http-equiv="refresh" />';
else
echo' ';
echo' Your Password Does not match!!';
echo'<meta content="3;cua.php" http-equiv="refresh" />';
mysql_close($conn)
?>
5.3 Hardware software acquisition
For the proper functioning of the system the following hardware and software are
required
 Hardware’s
 Computer
 Hard Disk
 Web application and database server

 Processor: GHz.
 RAM: GB.
 Software’s
 Notepad++
 Dreamweaver
 Browsers
 Wamp server
 MSQL server
5.4 Installation Process
Firstly instal the software adobe dreamwaver or Notepad++ and wamp server, after that follow
the steps:
Step 1- put the developed system folder on C:\wamp\www on your computer.
Step 2- Active your installed wampserver software
Step 3- open the browser on your computer and write localhost (127.0.0.1) or
(localhost/foldername/index.php) on the place of URL or as a url.
Step 4- finally you can view and access the sysem.
NB: Before you are run the system you must have import the databse which is arrived on your
folder to the wamp server databse (on phpmyadmin).
Follow the folllowing steps to success you activity
Step one install the wamp server.
After finishing installation active the wamp server as follows:
THEN :
 check your folder which is available on the C:\wamp\www

 open any of the browser and write on the pace of url “localhost/foldername/filename.file
extention” then run it.
NB: REMEMBER THAT:
Before you are run the project on the wamp server you must have import the database on the
mysql server. To import the databse on the wampserver follow the steps here:
 Step1: activate the wamp server.

 Step2: write “localhost/phpmyadmin” on the browser.
 Step3: then click on “localhost” on the displayed page and click on the “Databases” then
go to “create database” and create the database by the name of your databse name then
click on “create” button. After that:
 Open the newly created database.
 Select import
 Then browse database by pushing the “choose file” button then say “Go” at the bottom of
the page.
 Finally it is successful importing of database.
Finally installation can be successful when you are follow the steps appropraitly.
The n you can run the project.
CHAPTER SIX
6.1 Conclusion
An effort has been made to study as partial fulfillment of WSUDCMS (Wolaita sodo university
dormitory and cafeteria management system). To satisfy the project the team has tried to follow
HTML, PHP, Java script and MySQL methodology for a Good completion of the started project.
In our campus wolaita sodo university Dormitory and cafeteria management Systems are
Management systems found in the Universities Management system especially for managing the
students. This system is a web based application to serve students as well as the working group
of the system in different direction. Specially:-
1) Students now made possible to know their dorm and students cafeteria menu online which
overcomes extra expenditure of student’s time and resource.
2) saving proctors time lost for assigning dorm for students, preparing report while student leave
from campus, etc.
6.2 Recommendation
While doing this system the team members has faced different challenges. But by the
cooperation of all the group members and the advisor the team is now able to reach to the final
result i.e all the group members strongly fight these challenge and take the turn to the front.
So now all the group members strongly recommend the department that for the coming students,
it has to provide them with better service than the present in better hard ware, guaranteed
software’s, giving orientations how to proceed, offering guest to provide them with more
experienced work, support morally, manually, forming good relation with students, giving
students description of each phases and so on. So that it will get what it expects from its students
and satisfy with them.
References
Books
 HTML, XHTML, & CSS Bible, 3rd Edition (2004)

 JavaScript Bible, 5th Edition (2004)
 PHP Programming With PEAR (2006)
 PHP Solutions - Dynamic Web Design Made Easy (2006)
 PHP5 Recipes - A Problem-Solution Approach (2005)
Websites
 www.tutorialspoint.com/index.html
 www.w3schools.com/index.php
DORMITORY AND CAFETERIA MANAGEMENT

SYSTEM FOR WOLAITA SODO UNIVERSITY
A project Report
Submitted by:
1. Fentahun Worku NSC/R/468/04
2. Erediet Yalew NSC/R/427/04

3. Elilta Hagos NSC/R/410/04
4. Kidist Siasib NSC/R/674/04
5. Jemal Usman NSC/R/627/04
In partial fulfillment for the award of the degree of
BSc in Information Technology.

Wolaita Sodo University
Department of CSIT
Approval: Signature: Date:
Advisor: _________________ ________ ________
Examiner 1:_______________ ________ ________
Examiner 2:_______________ ________ ________

Final Documentation (G-9)

Uploaded by

Document Information

Original Description:

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

Final Documentation (G-9)

Uploaded by

Copyright:

Available Formats

Dormitory and Cafeteria System for Wolaita Sodo University

WOLAITA SODO UNIVERSITY

DEPARTMENT OF COMPUTER SCIENCE AND INFORMATION

GROUP MEMBERS ID_No

1. Elilta Hagos NSC/R/410/04

2. Erediat Yalew NSC/R/427/04

3. Fentahun worku NSC/R/468/04

4. Jemal usman NSC/R/627/04

5. Kidist siasb NSC/R/674/04

Advisor: Feven Teferi

Submitted to Department of Computer Science and Information Technology, college of Natural

Wolaita Sodo, Ethiopia

Submission date 08, 10, 2007 E.C

WSU Wolaita Sodo University

PHP Hypertext per processor

HTML Hypertext markup language

WAMP Window Apache MySQL PHP

MYSQL Microsoft structural query language

CD-RW Compact Disk rewritable

CSS cascading style sheet

RAM Random Access Memory

FBE faculty of business and economics

NSC Natural science and Computational

UML unified modeling language

COM cafeteria office manager

POM proctor office manager

DSTV digital satellite Television

SRS System Requirement Specifications

2.3.3 Outputs in existing system................................................................................................13

4.4 State chart modeling.............................................................................................................41

1.2.1 Background of the organization

1.2.1.2 Background of the project

1.3 Statement of the Problem

1.4. Team Composition

0918590371 Project manager

 Generally, work the overall management

0910329400 System analyzer

Table 1.1: table of team composition

1.4 Objectives of the project

1.5.1 General Objective

1.5.2 Specific objective

1.5 Scope of the Project

 Department of the student and also

1.6 Methodology and Development Tools

1.7.1 Data Collection Mechanisms

Table 1.2 software tools

1.7 Cost of project

Item name Quantity Price /Unit Total price

1.8 Limitation of the Project

 It does not check the academicals status of the student.

1.9Time schedule of the project

2. Description about the existing system

2.2 Players in the existing system

 Receive the question from student union like cafeteria improvement.

2. Proctor office manager

 Manage the proctors those are worked in each building.

 Control the overall works around dormitory.

3. Proctors in each building

 View or access the cafeteria menu.

5. Student cafeteria manager

2.3 Major function or activities in the existing system

2.3.1 Inputs in existing system