WOLLEGA UNIVERSITY

INISTITUTE OF ENGINEERING AND TECHNOLOGY

DEPARTMENT OF INFORMATICS
PROGRAM OF COMPUTER SCIENCE
PROJECT TITLE:

ONLINE BASED CAFETERIA MANAGEMENT SYSTEM FOR WOLLEGA UNIVERSITY

Intellectual property
The project is developed by Wollega University institute of technology Computer Science
department students to full fill the requirement of bachelor degree as final year project in order to
graduate. Since the project is the result of our effort someone who will take it to present as
his/her work is totally illegal and plagiarism. But someone can modify and add additional
functions that will write in the future works with the permission of authors.
Authors:-
Name ID Signature

1. Keyre Kemal------------------------------1655/14 ___________

2. Gutu Tadase-------------------------------1623/14 ___________
3. Chaltu Malkamu--------------------------1526/14 ___________
4. Ebise Bulcha-------------------------------1563/14 ___________
5. Dinknash Mitiku--------------------------1555/14 ___________

It is approved that this project has been written in a compliance with the formatting rules laid
down by the Institute. And to certify in my opinion the project is fully adequate in the scope and
quality, as a thesis for the Bachelor degree of science.

------------------------------------- ---------------------------------------------
Advisor Name Signature

Examining committee:
Name Signature Date
1. Chairman ____________ ___________ ___________
2. Examiner 1 ____________ ___________ ___________
3. Examiner 2 ____________ ___________ ___________
4. Examiner 3 ____________ ___________ ___________

i
Acknowledgment
First of all we would like to thank Almighty GOD for the strength, and throughout on this
project; nothing could happen without the help of GOD.We are also very great full and would
like to extend our sincere thanks to our staff members and students for sharing their ideas and
suggestions especially for their commitment. We really give a great respect and credit to
everyone who involved in our work.

ii
Table of Contents
Abstract......................................................................................................................................................v
1.Chapter One.............................................................................................................................................1
1.1. Introduction................................................................................................................................1
1.2. Background of the project..........................................................................................................1
1.3. Statement of the project.............................................................................................................2
1.4. Objective of the project..............................................................................................................2
1.4.1. General objective................................................................................................................2
1.4.2. Specific objective.................................................................................................................2
1.5. Scope of the project....................................................................................................................3
1.6. Limitation of the project.............................................................................................................3
1.7. Methodology of the project........................................................................................................3
1.7.1. Requirement gathering methodology................................................................................3
1.7.2. Requirement analysis and modeling..................................................................................4
1.8. Significance of the project..........................................................................................................4
1.9. Development of environment programming tools................................................................5
1.9.1. Software tool.......................................................................................................................5
1.9.2. Hardware tool.....................................................................................................................5
1.10. Feasibility analysis...................................................................................................................6
1.10.1. Operational feasibility.........................................................................................................6
1.10.2. Technical feasibility.............................................................................................................6
1.10.3. Economic feasibility............................................................................................................6
1.10.4. Schedule feasibility.............................................................................................................7
1.11. Beneficiaries of the project.....................................................................................................8
1.12. Project organization................................................................................................................8
1.13. Budget of the project..............................................................................................................9
2. Chapter Two......................................................................................................................................10
2.1. Description of the current system............................................................................................10
2.2. Major functions/activities of the existing system....................................................................10
2.3. Players/actors of the existing system.......................................................................................10

iii
 2.4. Report generated in the existing system..................................................................................10
2.5. Form and documentation used in the existing system............................................................11
2.6. Use case diagram for the existing system................................................................................12
2.7. Alternative solution..................................................................................................................12
3. Chapter Three...................................................................................................................................13
3.1. Proposed system/New system.................................................................................................13
3.2. Overview of the system............................................................................................................13
3.3. Requirement analysis for the new system...............................................................................13
3.3.1. Functional requirement....................................................................................................13
3.3.2. Non-functional requirement.............................................................................................14
3.4. User interface Prototype..........................................................................................................14
3.5. User interface description.........................................................................................................16
3.6. Actors and use case identification............................................................................................17
3.6.1. Actor identification...........................................................................................................17
3.6.2. Use case identification......................................................................................................18
3.7. Business rules(proposal system)...............................................................................................19
3.8. System security and safety procedure......................................................................................19
4. Chapter Four.....................................................................................................................................20
4.1. System modeling using object oriented paradigm...................................................................20
4.2. Use case diagram for new system............................................................................................20
4.3. Use case Description.................................................................................................................22
4.4. Object modeling(Class diagram)...............................................................................................37
4.5. Dynamic modeling....................................................................................................................38
4.5.1. Sequence diagram.............................................................................................................38
4.5.2. Activity diagram................................................................................................................48
4.5.3. Component diagram.........................................................................................................58
4.5.4. Deployment diagram........................................................................................................59
4.5.5. Database design................................................................................................................60
4.5.6. User interface design........................................................................................................60
5. Chapter Five......................................................................................................................................66
6. Chapter Two......................................................................................................................................77
6.1. Conclusion.................................................................................................................................77
6.2. Recommendation......................................................................................................................78

iv
References................................................................................................................................................79

Table content

Table 1.1: tangible benefit...........................................................................................................................6

Table 1.2: Budget of the project..................................................................................................................8
Table 2.1: Form of student’s registration...................................................................................................10
Table 4.1: use case documentation for manage account..........................................................................21
Table 4.2: use case documentation for login.............................................................................................22
Table 4.3: Use case documentation for assign ticker.................................................................................23
Table 4.4: Use case documentation for register student.............................................................................24
Table 4.5: Use case documentation for register employee.......................................................................25
Table 4.6: Use case documentation for delete student.............................................................................26
Table 4.7: Use case documentation for update student............................................................................27
Table 4.8: Use case documentation for post news....................................................................................28
Table 4.9: Use case documentation for ticking..........................................................................................29
Table 4.10: Use case documentation for send comment..........................................................................30
Table 4.11: Use case documentation for generate report.........................................................................31
Table 4.12: Use case documentation for view report................................................................................32
Table 4.13: Use case documentation for receive comment......................................................................33
Table 4.14: Use case documentation for add stock...................................................................................34
Table 4.15: Use case documentation for send request.............................................................................35

Figure content
Figure 1.1: Time schedule for the project....................................................................................................7
Figure 2.1: use case for existing system.....................................................................................................11
Figure 3.1: User interface prototype for cafeteria Manager......................................................................14
Figure 3.2: User interface prototype for Ticker.........................................................................................15
Figure 3.3: User interface prototype for Student......................................................................................15
Figure 4.1: use case diagram for proposed system....................................................................................20
Figure 4.2: class diagram for proposed system..........................................................................................36
Figure 4.3: sequence diagram for Login.....................................................................................................37
Figure 4.4: sequence diagram for student registration.............................................................................38
Figure 4.5: sequence diagram for delete student......................................................................................39
Figure 4.6: sequence diagram for assign ticker.........................................................................................40

v
Figure 4.7: sequence diagram for update student.....................................................................................41
Figure 4.8: sequence diagram for Post announce.....................................................................................42
Figure 4.9: sequence diagram for send comment page.............................................................................43
Figure 4.10: sequence diagram for generate report..................................................................................44
Figure 4.11: Sequence diagram for add stock............................................................................................45
Figure 4.12: sequence diagram for send request......................................................................................46
Figure 4.13: activity diagram for login page..............................................................................................47
Figure 4.14: activity diagram for student registration...............................................................................48
Figure 4.15: activity diagram for assign ticker...........................................................................................49
Figure 4.16: activity diagram for post advertisement................................................................................50
Figure 4.17: activity diagram for ticking page............................................................................................51
Figure 4.18: activity diagram for generate report.....................................................................................52
Figure 4.19: activity diagram for update student......................................................................................53
Figure 4.20: activity diagram for delete student........................................................................................54
Figure 4.21: Activity diagram for send comment.......................................................................................55
Figure 4.22: Activity diagram for add stock...............................................................................................56
Figure 4.23: Component diagram for proposed system............................................................................57
Figure 4.24: Deployment diagram for proposed system...........................................................................58
Figure 4.25: Database design for proposed system...................................................................................59
Figure 4.26: User interface design for Login.............................................................................................60
Figure 4.27: User Interface design for Student Registration......................................................................60
Figure 4.28: User interface design for Ticker Registration.........................................................................61
Figure 4.29: User interface design for Student Deletion...........................................................................61
Figure 4.30: User interface design for add stock.......................................................................................62
Figure 4.31: User interface design for post announcement......................................................................62
Figure 4.32: User interface design for Ticking...........................................................................................63
Figure 4.33: User interface design for store keeper registration...............................................................63
Figure 4.34: User interface design for generating report..........................................................................64
Figure 4.35: User interface design for update student..............................................................................64

vi
Abstract
Wollega University student’s cafeteria system is giving service for its students manually. It has
its own problem with managing the café, students and estimating the budget daily, weekly,
monthly, yearly, managing students and workers manually. Regarding to manage student
manually the ticker stand in front of the gate and receives the meal card of the student then mark
or tick on a separate paper. But this process is too much lengthy and inaccurate. The solution to
this problem is computerization of café system. This system helps to make the budget calculation
simple and accurate. And also, the system simplifies the total work of the cafeteria system.

vii
 1.Chapter One
1.1. Introduction
Wollega University student’s cafeteria system is giving service for its students manually. It
has its own problem with managing the café, the students and estimating the budget daily,
weekly, monthly, yearly. Regarding to management, Ticker stand in front of the gate and
receives the meal card of the student then mark or tick on the number that listed on the paper.
But this process is too much lengthy and inaccurate. There are three Students cafeteria in the
university. The first café has three gets therefore three Tickers are marking student meal card
and the second café has three gets therefore three Tickers are marking student meal card and
the third cafe has two gets therefore two Tickers are marking student meal card. But they
could not manage them properly because of the number of students which is very lot.
Therefore other solution should be invented. This is computerized café system. The system
has database, so that a lots of works are done. Generally, the system simplifies the total work
of the cafeteria system.

1.2. Background of the project

Wollega University is one of the thirteen Universities which were established by the federal
democratic republic government of Ethiopia. Its foundation stone was laid in 1997
E.C/.2005. The university is located around three kilometers east from the central square of
the town. It is laid out on 100 hectares. It is found in north eastern part of Ethiopia at
nekemte town.

The town is located 330 K.M West of Addis Ababa and Its altitude is 2400msabove sea level
and it has a comfortable weather condition. After the completion of some buildings of the
first phase of the construction (4 G+1 buildings of classrooms, 1 dining room, 12 G+2
dormitories, 2 G+1 libraries,2 cafeteria and 3 lecture halls), the university admitted the first
760 regular students in February 1999 E.C/2007.
In the cafeteria the students are in the compound with the permitted course registered they
will have a food service in the cafeteria. The cafeteria service given to students doesn't
include extension students.

1
 1.3. Statement of the project
Currently the services that are given in our cafeteria are handled manually. That made the
cafeteria managing system so inflexible. Common problem in existing system are Student do not
get information online, Schedule information which is posted on announcement board did not stay
long time. Assigning one ticker for two or more gates at the same time. Difficult to generate report
those are problem happen in existing system.

Cafeteria management system is facing many problems in the existing system:-

 Ticking paper should be daily printed

 Require much man power
 Difficult to manage all student
 Require much time
 Difficult to know meal schedule
 Take much more time to search student

1.4. Objective of the project

1.4.1. General objective
The main objective of our project is to develop online cafeteria management system for Wollega
University.

1.4.2. Specific objective

Some of the Specific Objects are the following:-
 To store detail information about Ticker, employees, students in secured way.
 To facilitate the communication ways in the cafeteria.
 To make optimum utilization of resources.
 To create flexible cafeteria managing system.
 To minimize the problems in cafeteria managing system.
 To generate reliable and timely reports to the manager.
 To improve data availability.

2
 1.5. Scope of the project
Our scope is to develop online based cafeteria management system. Our project do the
following
 To make the ticker to generate report
 To make the ticker to search and retrieves student’s information
 To make the manager to register student
 To make the ticker easily tick
 To make the manager to search student
 To make the manager to add stock.
 To make the manager to assign ticker to each cafeteria
 To make the administrator to manage account
 To make the manager to view student information
 To make the student to write comment
 To make the manager to view comment
 To make the manager to register ticker
 To make the manager to register employee
 To make the store keeper to send request
 To make the manager to update student
 To make the manager to delete student

1.6. Limitation of the project

 Our project is limited to cafeteria management system for Wollega University.
 Our project is compatible to the barcode system. Due to the lack of barcode
machine availability, in this project we have concentrated on manual verification
of the student Meal number only.

1.7. Methodology of the project

1.7.1. Requirement gathering methodology
We have used different methods to collect data. Data collection is the most important part of
the project to find the main requirement of the system and to understand how the system
does. Among the methods, we used the following:
 Interview: we use it to get direct information from the worker and manager of the
cafeteria.
 Observation: to analyze the difficulties of the WU cafeteria management.

3
 1.7.2. Requirement analysis and modeling
Object Oriented System Analysis and Design (OOSAD) using Unified Modeling Language
(UML) and Visio Software. Because of the following reasons:
 These techniques enable to reduce the communication gap between user and designers.
 These techniques enable designers to model the real world accurately.
 These techniques have usability features (it allows to use codes repeatedly on other
system).
 Allows full exploitation of the power of object-based and object-oriented programming
languages
 Object-based models appeal to the workings of human cognition, and hence the human
input into the development of a software system is likely to be more natural and less
error prone.

1.8. Significance of the project

The proposed project aimed to improve the overall work of the Wollega University student’s
cafeteria. The following are significance of the project
 To give enough information to the user (the manager)
 To minimize from more expenditure
 To generate report of student to manager who act illegally.
 To automate and manage the worker management and ticking system.
 To simplify shifting process of the worker.
 To get information easily (i.e. student, ticker, employer).
 Information accessing is easy and fast.
 Reduce time and energy during the process like urgent case shift of service schedule,
applicant registration for meal Number.
 To generate meal number to each student.
 To Checks the students Meal Number to get the cafeteria services.

4
 1.9. Development of environment programming tools
1.9.1. Software tool
The software requirements are:

I. Front End
 PHP and JavaScript: is used for coding.
 Cascade style sheet are combined and are used to web design.
 Window 8.1 Operating system.

II. Back End

 Wamp server
III. Documentation
 Microsoft word 2007 for preparing document,
 Microsoft power point for presentation and
 Microsoft Visio 2007 modeling tool

1.9.2. Hardware tool

For the successful run of the proposed system, the personal computer should have the following
hardware requirement:

 Computer(core i3, 4GB RAM)

 Flash disk(8 GB )
 Hard disk (500GB)
 Paper
 pen
 Projector

5
 1.10. Feasibility analysis
Feasibility study can be defined as the practical extend to which a project can be performed
successfully .Feasibility determines whether the solution consider to accomplish the
requirement is practical and workable in the software application. Any developed software
has to satisfy the criteria for feasibility. This project is also going to satisfy the following
criteria:
1.10.1. Operational feasibility
It might not be possible to see fully operational system within the given limit of time for
software development. However with great cooperation of the project team the system can
address over all problem that occur in WU cafe.
1.10.2. Technical feasibility
The new system doesn’t need any ideal technology in order to operate properly. Such
systems have been tried and succeed in many national and international organizations.
General study in the project area has shown that the current technology and ability exist in
order to complete the proposed system's objectives.
1.10.3. Economic feasibility
Is the measure of cost effectiveness in the project. That is why we sometimes call economic
feasibility as cost benefit analysis, for which the project we are working on have the
following benefits and costs.

Cost Benefit Analysis

A. Tangible Benefits

This Wu cafeteria management system is expected that it will be economically feasible because
it will save the budget of the university. That is spending on papers and printer toners.

No Resource Cost(birr)

1. Cost Reduction 5000

2. Increased Speed of service 4000
3. Planning & managing control 2500
Total tangible benefits 11500

Table 1.1:tangible benefit

6
B. Intangible benefits

The intangible benefits we suggest from the developing system are:

 Increase reliability
 Increase portability
 Increase efficiency
 Faster processing
 Organized file management
 Reduce cost for manual data management
 Easy update & retrieval on stored records
 Less errors occur

By considering these conditions our team confidentially says that our system is economically
feasible

1.10.4. Schedule feasibility

We arrange a program for finishing our task within the specified period of time . The following
figure (Gantt chart) illustrates the predefined tentative schedule of our project.

Figure 1.1:Time schedule for the project

1.11. Beneficiaries of the project

Wollega University cafeteria management system beneficiaries are into two. These are for
the student and for the University.
For student
 Wollega University cafeteria management system has the following beneficiaries for
student.
 Satisfaction of student
 Information accessing is easy and fast.
 Minimize the time that it takes to achieve a specific operation.
 Reduce time and energy during the process like urgent case shift of service schedule,
applicant registration for meal card.

7
For WU
 The workers satisfy on proposed system
 To minimize more expenditure on paper that printed every day
 Reduce the manpower required during the management activity and ticking process.
 Easy to handle student record after they start using the cafeteria services.
 To minimize workers load and number and to speed up the working system.
 Minimize the time that it takes to achieve a specific operation.
 Easy to handle student record after they start using the cafeteria services.
 To manage a lot of student and worker. That means using database we can store
number of student and worker
 To minimize complexity of the system like managing worker.

1.12. Project organization

 Chapter one is about introduction of the study. This chapter deals with background
information of the existing system including its scope and limitation. The other
components of the chapter are statement of the problem, objectives (general and
specific), feasibility analysis (operational, technical and economic feasibilities) and
significance as well as methodologies used in data collection season.
 Chapter two is about description of the existing system which in turn deals with: the
major functions of the existing system. The aim is to describe things in the existing
system.
 Chapter three is about requirements and proposed system. It deals with what kind of
functionality did the users expect from the system and what quality requirement the
system should achieved.
 Chapter four deal about UML diagram type. From behavioral diagram, it possesses
use case and sequential diagram. And from structural diagram, it contain conceptual
class diagram. The chapter is deals with the proposed system architecture, class
modeling, component and deployment modeling, persistence data management.
 Chapter five shows the conclusion of the document.

8
1.13. Budget of the project
We are running our project by using some resource which used for us and others are purchased by
us from our pocket. The resources are:

Resources Table 1.2: Budget of the project

Amount Price(birr)
1 Laptop 1 13500
2 Paper 90 30
3 Flash disk 1 200
4 CDRW 2 60
5 Pen 2 10
6 Print 90 90
Total 13890

2. Chapter Two
2.1. Description of the current system
Wollega university cafeteria which is the main area of our study is the one who is responsible
to give food service for students. Cafeteria give food service to students in manual way. That
9
 means the general management of cafeteria is done manually. In the current system, wollega
university cafeteria management use manual ticking system According to the student’s
registration they can print the meal card number that has its unique numbers for each student
and distribute it for all students.Then the meal card number copied to A4 paper for ticking.
The students are use cafeteria service by showing their meal card number and the ticker tick
the number which is listed on the paper.
2.2. Major functions/activities of the existing system
The Major and fundamental functions of the existing system is to give food service for
students at every meal time.
 The cafeteria manager collects student data and gives or assign cafe for each
student based on the amount of student (collected data).
 A student has see posts by going physically to post board.
 Each ticker checks the schedule and if there is any problem (e.g. overlap time)
tells to the manager.
 Tickers are take ticking materials by going to manager physically.

2.3. Players/actors of the existing system

The actors of the existing system are;
 Manager
 Tickers
 Students
 Store keeper
2.4. Report generated in the existing system
Reports in the existing system are generated using paper and specified on the notice board or by
other body like ticker. They generate report monthly.

2.5. Form and documentation used in the existing system

Forms and documentation currently used:
The form is used only for student registration to get meal card for cafeteria service.

10
Table 2.3: Form of student registration

Documents used in the existing system

There is no documentation to use. The manager guide all activity orally and they use rule and
regulation of the university to manage worker and students.

2.6. Use case diagram for the existing system

11
Figure 2.2: use case for existing system

2.7. Alternative solution

This project has come up with solutions that can minimize the problems of the manual
ticking system listed in statement of the problems section and enable the ticking system to
have an effective and efficient ticking process by considering the limited resources they have
and the strengths of the existing system.

3. Chapter Three
12
 3.1. Proposed system/New system
 Checks the students Id card manually to get the cafeteria services.
 After checking it ticker can allow the student to get the cafeteria services.
 When the students try to enter the cafeteria twice it can reject this kind of students.
 While rejecting the student the system generate the reports of this student to the
manager.
 To make users can be easily accessed and used at any time.
 Manager to store all information about Student, ticker, store keeper.
3.2. Overview of the system
The system is proposed to computerize the working environment of the existing
system and to overcome the problem regarded with manual work and to benefits
the community of the café in common.

The following list are the over view of the proposed system

 Saves time which is spent on searching the records by hand,

 Reduce space that occupied by manual document,

 Helps, admin to have an easy access and control over the system,
 Helps to reliable information among the community of the café,
 Helps to registering, searching, updating and to keep all the file in safe
way,
 Generate report,
 Online feedback between the communities of the café.

3.3. Requirement analysis for the new system

13
 3.3.1. Functional requirement
The functional requirements are functions or features that the system must include to satisfy the
user need and to be acceptable by the user.

Among the functional requirements included in our system are:

 The system would be able to register student.

 The system would be able to post announcement and news.
 The system would be able to assign ticker to cafe.
 The system would be able to assign students to café based on Id card.
 The system would be able to generate report.
 The system would be able to view report.
 The system would be able to search, delete, update for user (i.e. student, store keeper,
ticker, and employee).
 The system would be able to view post.
 The system would be able to write comment.
 The system would be able to send comment.
 The system would be able to view comment.
3.3.2. Non-functional requirement
Non-functional requirement is a requirement that specifies criteria that can be used to
judge the operation of the system, rather than specific behaviors of the system which are
specified under functional requirements of the system.
Non-Functional requirements of the system described as follows:

 Response time: the system should give the right response for the user as fast as possible.

 Reliability: All information modified or uploaded by user didn’t lead to any conflict or
error to the system.

 Availability: Our system can also available to give services and as it needed it can be
maintained.

 Maintainability :Maintainability is characteristic of design and installation which

determines the probability that a failed equipment, machine or system can be restored to

14
 its normal operable state within a given timeframe, using the prescribed practices and
procedures

 Portability:The system is able to run on different platform as long as operating system is

installed.

3.4. User interface Prototype

User interface prototype is to indicate the surface that can be used by user and the system to
communicate to each other, but, not actual work area.

Figure 3.3: User interface prototype for cafeteria Manager

15
Figure 3.4: User interface prototype for Ticker

Figure 3.5: User interface prototype for Student

3.5. User interface description

Login user interface: users (i.e. cafeteria manager, ticker) to login into the system.
Register student user interface:This is to able administrator to register student into the
system.
Assign ticker user interface: manager able to assign ticker to the cafeteria.
Update student user interface:This is to able administrator to update student into the
system.
Post announcement/ news user interface: manager to post announcement or news.

16
 Generate Report user interface: the ticker able to generate report to manager.
Register ticker user interface:This is to able administrator to register ticker into the system.
Make tickuser interface: the ticker able to make tick.
Update ticker user interface:This is to able administrator to update ticker into the system.
Delete student user interface: This is to able manager to delete student from the system.
Add stock user interface: This is to able manager to add stock into the system.
Register employee user interface:This is to able administrator to register employee into the
system.
View Schedule user interface:This is to able student to view Schedule which in to the system.
Update employee user interface:This is to able administrator to update employee from the
system.
View post user interface:This is to able student to view post which is posted by the manager
through the system.
View student user interface:This able the manager to view student information from the
system.
Delete employee user interface:This is to able administrator to delete employee from the
system.
Write comment user interface:This is to able student to write comment to the system.

17
 3.6. Actors and use case identification
3.6.1. Actor identification
The following are Actors in our project:
 Administrator
 Manager
 Ticker
 Student
 Store keeper
Administrator: is a computer professional, who can control system technically. He/she is
mainly responsible in managing the user accounts.
Manager: is a Café manager. Manager will be able to post news in post page for public, which
the Manager want to announce to the student. Also will be assign tickers to each cafe. The
manager can able to update student’s data and delete the data of the student when he/she is
graduate or non _café.
Ticker: Tickers are able to tick students who came to eat at meal time to café.Also tickers have
able to generate report to Manager when students act unethically and another
reports which are concerned with the manager.
Student:is students of Wollega University. Students can see posts which are posted from the
manager and students can able to give comments.
Store keeper:is able to hold stock in the store. Store keeper can send request to the cafeteria
manager.
3.6.2. Use case identification
The following are the Use cases of our system:
 Manage user account:administrator to create, delete, block, and change
password of user account.
 Register students: The manager can able to register students to the system.
 See report: The manager can see reports from the system which are sent by
tickers.
 Assign tickers: The manager assigns tickers to each café.
 Post news: The Manager post news to the students.
 Update students information: The manager can update student info.
 Store keeper: The store keeper send request to the manager.

18
  Add stock: The manager can add stock.
 Delete student’s information: The manager can delete student information.
 Making tick: Tickers tick the student’s meal no when students enter to café.
 Generate report: Tickers give send reports to the manager.
 See post: Students can see posts from the post page (from the system) which is
posted by the Manager. Students can use the system by guest account.
 Write comment: students can sent comments to the manager based on cafeteria
service.

3.7. Business rules(proposal system)

In order to effectively operating the software satisfy a principles or policy with
regarding to access control issues, and principles of the organization.
Therefore, the system operates this software are identified by the following
business rules.
BR1: Authorize to the system
Manager and ticker must have a valid user name and password.
BR2: To get cafeteria service student must have meal no.

3.8. System security and safety procedure

Once the system is configured means connected with computer it is real that
everybody can access the system. Also employee and student of the cafeteria
may can try to access without any permission that affects managing system.
Because of such reasons system access control and security is the main issue of
the project. Therefore system identify someone who is, what he/she wants to
access and where he/she wants to access, check whether the somebody is
authority or not and granting permission or deny.
Thus the system provide protection over system from an unauthorized users
and allows those who have an authority to access the system and even an
authorized body forgot either of his/her user name or password the system
prompts to correct again.

19
 4. Chapter Four
4.1. System modeling using object oriented paradigm

System modeling is the conceptual model that describes and represents a system. The system
comprises multiple views such as planning, analyzing, designing, implementing, input data
and output data view. Modeling is the interdisciplinary study of the use of models to
conceptualize and construct systems. It expresses complex matter in the context of software
development projects. Involves in making decision about which abstraction is the part of the
system under consideration and which fall outsides its boundaries. Improving understanding
of situations; identifying problems or formulating opportunities and supporting decision
making.

20
 4.2. Use case diagram for new system
A use case is an interaction between user and a system. It captures the goal of the users and
responsibility of the system to its users. It is the functionality of the system or the service
provided by the system.

Figure 4.6: use case diagram for proposed system

4.3. Use case Description

21
Name Manage user account
ID UC#1
Description It allows the administrator to create account, block account, and delete
account, and change password.
Actor Administrator
Precondition The users should have login into the system
Post condition User account has created, or deleted, or blocked, or password is changed.
Basic course of Actor action System response
action: Step 1.User open create account, or delete account, Step2. The system
or block account page, or change password page. Displaysform of the
Step3.The user fill all required information’s in the requested Page.
form. Step5.The system
Step 4. The use click on action okay button display successful
message.
Step6. The use case
ends.

Alternate =>Invalid information entries.

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3.

Name Login
ID UC#2
Description It allows users to login into the system
Actor Manager, Ticker, Administrator
Precondition The user should have an account
Post condition The user will login in to the system

22

Table 4.4: use case documentation for manage account

Basic course of Actor action System response
action: Step 1.The user initiate to login into the system Step2. The system
Step3.The user fills user name and password. Displays the
Step4. The user click Login button User Login Page.
Step5. The system
verifies the username
and password.
Step6.The system
displays home page.
Step7. The use case
ends

Alternate =>The username/password is invalid.

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3.

Name Assign Ticker

ID UC#3
Description It allows the manager to assign ticker to the café
Actor Manager
Precondition The users should have login into the system
Post condition Ticker is assigned successfully

23

Table 4.5: use case documentation for login

 Basic course of Actor action System response
action: Step 1. The user initiate to open assign ticker page Step2. The system
Step3.The user fill the required information in the display Ticker
form assigns form.
Step4. Press assign button Step5. Display
assignation
successful.
Step6. The use case
ends.

Alternate =>Invalid information entry

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3

Table 4.6:Use case documentation for assign ticker

Name Register student

ID UC#4
Description It allows manager to register student in the system database
Actor Manager
Precondition The users should have login into the system
Post condition Student registered successfully

24
 Basic course of Actor action System response
action: Step 1. The user initiate to open register student Step2. The system
page display student
Step3.The user fill the required information in the registration form.
form Step5. Display
Step4. Press submit button registration
successful.
Step6. The use case
ends.

Alternate =>Invalid information entry

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3

Table 4.7:Use case documentation for register student

Name Register Employee

ID UC#5
Description It allows manager to register employee in the system database
Actor Manager
Precondition The users should have login into the system

25
 Post condition Employee registered successfully
Basic course of Actor action System response
action: Step 1. The user initiate to open register employee Step2. The system
page display employee
Step3.The user fill the required information in the registration form.
form Step5. Display
Step4. Press submit button registration
successful.
Step6. The use case
ends.

Alternate =>Invalid information entry

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3

Table 4.8: Use case documentation for register employee

Name Delete student

ID UC#6
Description It allows manager to delete student from the system database
Actor Manager
Precondition The users should have login into the system
Post condition Student deleted successfully

26
 Basic course of Actor action System response
action: Step 1. The user initiate to open delete student page Step2. The system
Step3. Check the availability of the student display student
Step5.Press delete button delete form.
Step4. The system
display the student
data.
Step6. Display
delete successful.
Step7. The use case
ends.
Alternate =>Invalid information entry
course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3

Table 4.9: Use case documentation for delete student

Name UpdateStudent
ID UC#7
Description It allows manager to update student from the system database
Actor Manager
Precondition The users should have login into the system
Post condition Student updated successfully

27
 Basic course of Actor action System response
action: Step 1. The user initiate to open update student page Step2. The system
Step3. Check the availability of the student display student
Step5.Press update button update form.
Step4. The system
display the student
data.
Step6. Display
update successful.
Step7. The use case
ends.
Alternate =>Invalid information entry
course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3

Table 4.10:Use case documentation for update student

Name Post advertisement/ news

ID UC#8
Description It allows manager to post advertisement or news
Actor Department
Precondition The users should have login into the system
Post condition News or advertisement is posted

28
 Basic course of Actor action System response
action: Step 1. The user open post advertisement/ news page Step2. The system
Step3.The manager write news or upload post in the display post
form advertisement/ news
Step4. Press post button form.
Step5.The system
display post
successful.
Step6. The use case
ends.

Alternate => For error occurs during post

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3

Table 4.11: Use case documentation for post news

Name Make Tick

ID UC#9

Description It allows ticker to make tick on student meal number

Actor Ticker

Precondition Ticker should login to the system

Post condition Successfully Ticked

29
 Basic course of Actor action System response
action: Step 1. The user initiate to open make tick page Step2. The system
Step3. Check the availability of the student meal display make tick
number. form.
Step5.Press tick button Step4. The system
display the student
data.
Step6. Display
successfully ticked.
Step7. The use case
ends.
Alternate =>Invalid information entry.
course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3.

Table 4.12: Use case documentation for ticking

Name Send comment

ID UC#10

Description It allows student to send comment to manager

Actor Student

Precondition student should use guest account

Post condition Comment is sent

30
 Basic course of Actor action System response
action: Step 1. The user open send comment page Step2. The system
Step3.The user fill the required information in the display send
form comment form.
Step4. Press send button Step5.The system
Display successfully
sent.
Step6. The use case
ends.

Alternate =>Invalid information entry.

course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3.

Table 4.13: Use case documentation for send comment

Name Generate Report

ID UC#11

Description It allows ticker to generate report to manager

Actor Ticker

Precondition Ticker should login to the system

Post condition Report is generated

31
 Basic course of Actor action System response
action: Step 1. The user open generate report page Step2. The system
Step3.The user fill the required information in the display generate
form report form.
Step4. Press send button Step5.The system
Display successfully
sent.
Step6. The use case
ends.

Alternate =>Invalid information entry.

course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3.

Table 4.14: Use case documentation for generate report

Name View Report

ID UC#12
Description It allows manager to view report.
Actor Manager
Precondition User should be login into the system
Post condition Report Viewed

32
 Basic course of Actor action System response
action: Step 1. The user open the system. Step2. The system
Step3. The user read the report. display the report.
Step4. The use case
ends.

Alternate
course of
action:

Table 4.15: Use case documentation for view report

Name Receive Comment

ID UC#13
Description It allows manager to get comment from student.
Actor Manager
Precondition User should be login into the system
Post condition comment received

33
 Basic course of Actor action System response
action: Step 1. The user open the system. Step2. The system
Step3. The user read the request. show the comment.
Step4. The use case
ends.

Alternate
course of
action:

Table 4.16: Use case documentation for receive comment

Name Add Stock

ID UC#14
Description It allows manager to Add Stock in the system database
Actor Manager
Precondition The users should have login into the system
Post condition Stock added successfully

34
 Basic course of Actor action System response
action: Step 1. The user initiate to open add stock page Step2. The system
Step3.The user fill the required information in the display add stock
form form.
Step4. Press submit button Step5. Display
stock added
successful.
Step6. The use case
ends.

Alternate =>Invalid information entry

course of 4.1. The system displays error message.
action: 4.2. The system continues at step 3

Table 4.17: Use case documentation for add stock

Name Send Request

ID UC#15

Description It allows store keeper to send request to manager

Actor Store keeper

Precondition Store keeper should login to the system

Post condition Request is sent

35
 Basic course of Actor action System response
action: Step 1. The user open send Request page Step2. The system
Step3.The user fill the required information in the display send Request
form form.
Step4. Press send button Step5.The system
Display successfully
sent.
Step6. The use case
ends.

Alternate =>Invalid information entry.

course of 3.1. The system displays error message.
action: 3.2. The system continues at step 3.

Table 4.18: Use case documentation for send request

4.4. Object modeling(Class diagram)

36
 Figure 4.7: class diagram for proposed system

4.5. Dynamic modeling

37
 4.5.1. Sequence diagram
Sequence diagram in Unified Modeling Language (UML) is a kind of 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 sequence of
messages exchanged between the objects needed to carry out the functionality of the
scenario.

Figure 4.8: sequence diagram for Login

38
Figure 4.9: sequence diagram for student registration

39
Figure 4.10: sequence diagram for delete student

40
Figure 4.11: sequence diagram for assign ticker

41
Figure 4.12: sequence diagram for update student

42
Figure 4.13: sequence diagram for Post announce

43
Figure 4.14: sequence diagram for send comment page

44
Figure 4.15: sequence diagram for generate report

45
Figure 4.16: Sequence diagram for add stock

46
Figure 4.17: sequence diagram for send request

4.5.2. Activity diagram

47
Activity diagrams are graphical representations of workflows of stepwise activities and actions
with support for choice, iteration and concurrency. In the unified modeling language, activity
diagrams can be used to describe the business and operational step-by-step workflows of
components in a system. In its basic form an activity diagram is a simple and intuitive illustration
of what happens in a workflow, what activities can be done in parallel, and whether there are
alternative paths through the workflow.

Figure 4.18: activity diagram for login page

48
Figure 4.19: activity diagram for student registration

49
Figure 4.20: activity diagram for assign ticker

50
Figure 4.21: activity diagram for post advertisement

51
Figure 4.22: activity diagram for ticking page

52
Figure 4.23: activity diagram for generate report

53
Figure 4.24: activity diagram for update student

54
Figure 4.25: activity diagram for delete student

55
Figure 4.26: Activity diagram for send comment

56
Figure 4.27: Activity diagram for add stock

57
 4.5.3. Component diagram
Component diagrams show how the physical components of a system are organized.
In this Diagram components of the system will be wired showing that there is
relation among components, management of the system, database and operations
performed on databases such security issue.

Figure 4.28: Component diagram for proposed system

58
 4.5.4. Deployment diagram
Deployment diagrams are used to visualize the topology of the physical components
of a system, where the software components are deployed [5]. It describes how a
system will be physically deployed in the hardware environment. It depicts the a
static view of run time configuration of processing node (either physical machine or
virtual machine node) and the components that run on those nodes i.e. the hardware
of the system and the software.

Figure 4.29: Deployment diagram for proposed system

59
 4.5.5. Database design

Figure 4.30: Database design for proposed system

4.5.6. User interface design

User interface design is the overall process of designing how a user will be able to
interact with an application. User interface design is the specification of
communication/interaction mechanism between the system users and a system.
Our system user interfaces are:-

60
Figure 4.31: User interface design for Login

Figure 4.32: User Interface design for Student Registration

61
Figure 4.33: User interface design for Ticker Registration

Figure 4.34: User interface design for Student Deletion

62
Figure 4.35: User interface design for add stock

Figure 4.36: User interface design for post announcement

63
Figure 4.37: User interface design for Ticking

Figure 4.38: User interface design for store keeper registration

64
Figure 4.39: User interface design for generating report

Figure 4.40: User interface design for update student

65
 5. Chapter Five
Implementation
Implementation can be defined as it is the sample code of the given project. These are some of
the sample codes that we have done . Sample code of the system for login to the system is:
<?php
session_start();
include("db/connection.php");
$message="";
if(is_scalar($_POST['submit'])){
$user=$_POST['user'];
$pass=$_POST['pass'];
$account=$_POST['account'];
$us=mysqli_query($conn,"SELECT user_name FROM account where user_name='$user' and
role='$account'");
$ps=mysqli_query($conn,"SELECT password FROM account where password='$pass' and
user_name='$user'");
$us=mysqli_num_rows($us);
$ps=mysqli_num_rows($ps);
if($us==0&&$ps!=0){
$message= "<div align=center style=color:red>No such type of account!</div>";
}else if($ps==0&&$us!=0){
$message= "<div align=center style=color:red>Wrong password</div>";
}else if($us==0&&$ps==0){
$message= "<div align=center style=color:red>No such type of account!</div>";
}
else{
$_SESSION[user]=$_POST['user'];
if($_POST['account']=="Administrator"){
header("location:homea.php");

66
 }else if($_POST['account']=="Manager"){
header("location:homem.php");
}else if($_POST['account']=="Ticker"){
header("location:homet.php");
}else if($_POST['account']=="StoreKeeper"){
header("location:homes.php");
}
}
}
mysqli_close($conn);
?>
<title>Home</title>
<link rel="stylesheet" type="text/css" href="css/style.css">
<style type="text/css">
.input{
width: 300px;
height: 30px;
}
.select{
width: 300px;
}
.button{
background-color:56789;
text-align: center;
border: none;
font-size: 17px;
border-radius: 3px;
width: 100px;

67
 height: 30px;
color: white;
}
</style>
<script type="text/javascript" src="js/studentval.js"></script>
<body>
<img src="images/wu.png" style="width: 100%;height: 80px;">
<br>
<br>
<div id="container">
<div id="container_body" align="right">
<div style="width: 350px;margin: auto;color:rgb(200,150,50);font-size: 24px; " "><marquee
behavior="alternate"><p style=" margin-top: 10px; font-size: 24;"><b>Cafeteria Management
System</b></p></marquee></div>
<form class="contain" name="home" method="post" onsubmit="return index();" >
<table class="table">
<tr>
<td>
<tr><td colspan="3"><?php echo "$message";?></td></tr>
<tr>
<td rowspan="4"><img src="images/user.png"></td>
<td><label>User Name:</label></td>
<td><input type="txt" name="user" placeholder="User Name"></td>
</tr>
<tr>
<td><label>Password:</label></td>
<td><input type="Password" name="pass" placeholder="Password"></td>
</tr>
<tr>

68
 <td><label>Account Type: </label></td>
<td>
<select name="account">
<option value="">Select account type</option>
<OPTION value="Administrator" >Administrator</OPTION>
<option value="Manager">Manager</option>
<option value="Ticker">Ticker</option>
<option value="StoreKeeper">StoreKeeper</option>
</select>
</td>
</tr>
<tr>
<td></td>
<td><input type="submit" name="submit" value="Login">
<a href="change.php" >forgott Password</a></td>
<td><a href="Studentlogin.php">STUDENT</a></td>
</tr>
</table>
</td>
</tr>
</table>
</form>
</div>
</div>
</body>
<?php
include("footer.php");
?>

69
//Sample code of the system for Student Registration is:
<?php
session_start();
if(!isset($_SESSION[user])){
header("Location:index.php");
}
include("adminhead.php");
include("db/connection.php");
if (is_scalar($_POST['submit'])) {
$id=$_POST['stuId'];
$fname=$_POST['fname'];
$mname=$_POST['mname'];
$lname=$_POST['lname'];
$sex=$_POST['sex'];
$col=$_POST['col'];
$dep=$_POST['dep'];
$year=$_POST['year'];
$remark=$_POST['remark'];
$sql="INSERTINTO
studentreg(student_id,student_fname,student_mname,student_lname,sex,college,department,batc
h,remark) values('$id','$fname','$mname','$lname','$sex','$col','$dep','$year','cafe') ";
$sql2="INSERT INTO cafe_user(student_id) values('$id') ";
$result=mysqli_query($conn,$sql);
$result2=mysqli_query($conn,$sql2);
if ($result&&$result2) {
$mes="successfully registerd!";
}else{
echo "".mysqli_error($conn);
}

70
 }
?>
<link rel="stylesheet" type="text/css" href="css/style.css">
<style type="text/css">
.input{
width: 300px;
height: 30px;
}
.select{
width: 300px;
}
.button{
background-color:56789;
text-align: center;
border: none;
font-size: 17px;
border-radius: 3px;
width: 100px;
height: 30px;
color: white;
}
</style>
<script type="text/javascript" src="js/studentval.js"></script>
<div id="container">
<div id="container_body" align="center">
<h4 align="center"><font size=6 face="Algerian">Student Registration </font></h4>
<form method="post" name="sreg" onsubmit="return studentreg();">
<p align="center"><?php echo "$mes"; ?></p>

71
 <table cellpadding="5" align="center">
<tr>
<td >Student Id: </td>
<td><input class="input" name="stuId" type="text" id="stuId" placeholder="Student Id"
size="30"/> </td>
</tr>
<tr>
<td>First Name:</td>
<td><input class="input" name="fname" type="text" id="fname" placeholder="First Name"
size="30" /></td>
</tr>
<tr>
<td>Middle Name:</td>
<td><input class="input" name="mname" type="text" id="mname" placeholder="Middle
Name" size="30" /></td>
</tr>
<tr>
<td>Last Name:</td>
<td><input class="input" name="lname" type="text" id="lname" placeholder="Last Name"
size="30" /></td>
</tr>
<tr>
<td>Sex:</td>
<td><input name="sex" type="radio" value="Male" id="sex" />Male
<input name="sex" type="radio" value="Female" id="sex"/>Female
</td>
</tr>
<tr>
<td><label>College:</label></td>
<td>

72
 <select class="select" name="col" id="col" >
<option value="">------select college------</option>
<?php
$idq="SELECT * FROM college";
$result = mysqli_query($conn, $idq);
while ($row = mysqli_fetch_array($result,MYSQL_ASSOC)){
$r=stripcslashes($row[college]);
?>
<option value="<?php echo $r ?>" > <?php echo "$r"; ?> </option>
<?php
}
?>
</select>
</td>
</tr>
<tr>
<td>Department:</td>
<td name="a">
<select class="select" name="dep" id="dep" >
<option value="">------select department------</option>
<?php
$idq="SELECT program FROM education";
$result = mysqli_query($conn, $idq);
while ($row = mysqli_fetch_array($result)){
$r=stripcslashes($row[program]);
?>
<option value="<?php echo $r ?>" > <?php echo "$r"; ?> </option>
<?php

73
 }
?>
</select>
</td>
</tr>
<tr>
<td>Year:</td>
<td><select class="select" name="year" id="year">
<option selected="selected" value="">-------select batch--------</option>
<option value="1">I</option>
<option value="2">II</option>
<option value="3">III</option>
<option value="4">IV</option>
<option value="5">V</option>
<option value="6">VI</option>
</select>
</td>
</tr>
<tr>
<td></td>
<td><input class="button" type="submit" name="submit" value="Register" />
<input class="button" type="reset" name="Reset" value="Reset" />
</td>
</tr>
</table>
</form>
</div>
</div>

74
<?php
include("footer.php");
?>
//Sample code of the system for Student Registration is:
<?php
session_start();
if(!isset($_SESSION[user])){
header("Location: index.php");
}
include("header.html");
include("db/connection.php");
if(is_scalar($_POST['sub'])){
$cafe=$_POST['cafe'];
if ($cafe!=NULL) {
$result=mysqli_query($conn,"INSERT INTO caffe(caffe_name)values('$cafe') ");
if($result){
$mes="You submited sccessfully!";
}else{
$mes="Failed ".mysqli_error($conn);
}
}else{
$mes="Please select all below fields...";
}
}
?>
<link rel="stylesheet" type="text/css" href="css/style.css">
<style type="text/css">
.input{
width: 300px;
height: 30px;
}
.select{
width: 300px;
}
.button{
background-color:56789;
text-align: center;
border: none;
font-size: 17px;

75
 border-radius: 3px;
width: 100px;
height: 30px;
color: white;
}
</style>
<script type="text/javascript" src="js/assignval.js"></script>
<script type="text/javascript">
function gateData(cafe){
window.location="assign_gate2.php?cafe="+cafe;
}
</script>
<div id="container">
<div id="container_body" align="center">
<h4 align="center"><font size=6 face="Algerian">Select Cafeteria for
assign...</font></h4>
<form method="post" name="ass" onsubmit="return assign_gate();">
<p><?php echo "$mes"; ?></p>
<table cellpadding="5" align="center">
<tr>
<td><label>Cafeteria:</label></td>
<td>
<select class="select" name="cafe" id="cafe" onchange="gateData(this.value);" >
<option value="">--select cafeteria--</option>
<?php
$idq="SELECT * FROM cafeteria ";
$result = mysqli_query($conn, $idq);
while ($row = mysqli_fetch_array($result,MYSQL_ASSOC)){
$r=stripcslashes($row[cafeteria]);
?>
<option value="<?php echo $r ?>" > <?php echo "$r"; ?> </option>
<?php
}
?>
</select>
</td>
</tr>
</table>
</form>
</div>
</div>

76
 6. Chapter Two
Conclusion And Recommendation

6.1. Conclusion
The computers and computerization technology in the world is growing along the fast lane where
Ethiopia is attempting to run along this lane in which there are achievements recorded. And as
years, pass by, we are pretty much confident that extent progress will be made in our country.
System development is one of the ways in which we can make progress by making a lot of tasks
easier and the overall use of computers along with the developed systems is believed to lead to
the peak of the technology standard. It is known that developing a system for an organization is
not easy. But the team have tried its best and developed interesting system web based cafeteria
Management System for wollega University. It is flexible, accurate and attractive with easy GUI
approach. Generally, the team confidently can say that the software is completed successfully
with negligible errors. Concussively, the issues raised in the summary of finding will be
discussed in this conclusion part. There for, we conclude

1. The program complete in modular forms and in its overall status where it
consists of all the necessary features required for a system to link a system.
The testes and evaluations made show that the system is full-fledged and
complete.
2. The developed system can conclusively be called user friendly in which the
form developed are suitable for use by any user who will defiantly get
accustomed to the system’s environment easily.
3. We can be also concluding that the graphical user interface is fully developed
with all the necessary dropdown menu and textual representation.
4. The system is strongly secure with the use of identification user name and a
password.

77
6.2. Recommendation
 We would like to recommend that the system is open for interested groups or
individuals who wish to add new functionalities and fully done our limitations like
bide barcode reader application and anther functionalities in the office of wollega
university cafeteria management system.
 We would like to recommend the system to be integrated with integrated payment
system.
.

78
References
1. James Rumbaugh, The Unified Modeling Language User Guide, (2nd Edition), 2004.
2. Michele Cyran, Database Concepts, October 2005.
3. http//:www.wikipidia.org.
4. http//:www.google.com.
5. YouTube tutorials.

79