Table of Contents

CHAPTER ONE ............................................................................................................................................... 1

1.1. Introduction ....................................................................................................................................... 1

1.2. Background ........................................................................................................................................ 1

1.3 Description of Existing System ............................................................................................................ 2

1.3.1 Use Case of Existing System ......................................................................................................... 3

1.4 Statements of the Problem ................................................................................................................. 4

1.5 Objective of the Project ...................................................................................................................... 4

1.5.1 General Objectives ....................................................................................................................... 4

1.5.2 Specific Objectives ....................................................................................................................... 4

1.6 Methodology....................................................................................................................................... 5

1.6.1 Data Collection Method ............................................................................................................... 5

1.6.2 Data Processing and Use .............................................................................................................. 5

1.6.3 System Development Tools ......................................................................................................... 6

1.6.4 Implementation Tools .................................................................................................................. 6

1.6.5 Approach ...................................................................................................................................... 7

1.7 Feasibility ............................................................................................................................................ 7

1.7.1 Economic Feasibility ..................................................................................................................... 7

1.7.2 Operational Feasibility ................................................................................................................. 8

1.7.3 Technical Feasibility ..................................................................................................................... 8

1.7.4 Time Feasibility (using Gantt chart) ............................................................................................. 8

1.7.5 Team Organization ....................................................................................................................... 9

1.7.6 Communication Plan .................................................................................................................... 9

i
 1.8 Project Scope and Limitation ............................................................................................................ 10

1.8.1 Scope of the Project ................................................................................................................... 10

1.8.2 Limitation of the Project ............................................................................................................ 10

1.9 Significance of the Project ................................................................................................................ 11

1.10 Organization of the Project…………………………………………………………………………………………………………11

CHAPTER TWO ANALYSIS ............................................................................................................................ 12

2.1. Existing System Description ............................................................................................................. 12

2.2 Activities Performed under the Existing System ............................................................................... 14

2.3 Role players in the existing system ................................................................................................... 14

2.3.1 Cafeteria Managers .................................................................................................................... 14

2.3.2 Tickers ........................................................................................................................................ 15

2.3.3 Students ..................................................................................................................................... 15

2.3.4 Store keeper ............................................................................................................................... 15

2.4 Business Rule .................................................................................................................................... 15

2.5 New System (Proposed System) ....................................................................................................... 16

2.6 Non-Functional Requirements and Constraints................................................................................ 17

2.7 Functional Requirements…………………………………………………………………………………………………………….18

2.8 Use Case View ................................................................................................................................... 19

2.8.1 Use case Identification ............................................................................................................... 20

2.9 Use case Diagram .............................................................................................................................. 20

2.10 Use Case Documentation ................................................................................................................ 22

2.11 Sequence diagram model ............................................................................................................... 33

2.12 Activity diagrams............................................................................................................................. 41

2.13 State Chart Diagrams ...................................................................................................................... 47

2.14 Key Abstraction with CRC Analysis.................................................................................................. 53

2.15 Conceptual modeling: class diagram .............................................................................................. 54

ii
 2.16 User Interface Prototype ................................................................................................................ 55

2.16.1 Essential User Interface Prototyping ....................................................................................... 55

CHAPTER THREE: DESIGN ............................................................................................................................ 59

3. Purpose and Design Goals................................................................................................................... 59

3.1 Introduction ...................................................................................................................................... 59

3.2 Design Goals ...................................................................................................................................... 59

3.3 Proposed Software Architecture ...................................................................................................... 60

3.3.1. System decomposition .............................................................................................................. 60

3.3.2. Design Class Diagram ................................................................................................................ 61

3.3.3. Inheritance Class Diagram......................................................................................................... 62

3.4 Collaboration Diagram ...................................................................................................................... 63

3.5 Layering Class Diagram ..................................................................................................................... 66

3.6 Component Diagram ......................................................................................................................... 67

3.6 Deployment Diagram ........................................................................................................................ 68

3.7 Persistence Modeling for Object Oriented Database ....................................................................... 69

3.8 Access Control and Security .............................................................................................................. 70

3.9 Appendix………………………………………………………………………………………………………………………………………72

3.10 Reference………………………………………………………………………………………………………………………………….76

iii
Table of Figures
Figure 1 Existing System Use Case Diagram.................................................................................................. 3
Figure 2 the Architecture of Cafeteria Management System ...................................................................... 13
Figure 3 use case diagram of the proposed system..................................................................................... 21
Figure 4 Sequence diagram for login .......................................................................................................... 34
Figure 5 Sequence diagram for register student.......................................................................................... 35
Figure 6 Sequence for generate report ........................................................................................................ 36
Figure 7 Sequence diagram for update student ........................................................................................... 37
Figure 8 Sequence diagram for view comment .......................................................................................... 38
Figure 9 Sequence diagram for serve student ............................................................................................ 39
Figure 10 Sequence diagram for post news ................................................................................................ 40
Figure 11 Login activity diagram................................................................................................................ 41
Figure 12 Registration activity diagram...................................................................................................... 42
Figure 13 Update student info activity diagram.......................................................................................... 43
Figure 14 Report generate activity diagram ................................................................................................ 44
Figure 15 Post news activity diagram ......................................................................................................... 45
Figure 16 Serve student activity diagram ................................................................................................... 46
Figure 17 State-chart for login .................................................................................................................... 48
Figure 18 State chart for register student .................................................................................................... 49
Figure 19 Generate report state chart .......................................................................................................... 50
Figure 20 State chart for update student info .............................................................................................. 51
Figure 21 State chart for serve student........................................................................................................ 52
Figure 22 CRC diagram .............................................................................................................................. 53
Figure 23 Conceptual Class Diagram ......................................................................................................... 54
Figure 24 create account prototype ............................................................................................................. 55
Figure 25 login prototype............................................................................................................................ 56
Figure 26 change password prototype ....................................................................................................... 56
Figure 27 User interface of home page ....................................................................................................... 57
Figure 28 Registration form user interface .................................................................................................. 58
Figure 29 Subsystem decomposition diagram ............................................................................................ 60

iv
Figure 30 Design Class Diagram ................................................................................................................. 61
Figure 31 Inheritance Class Diagram .......................................................................................................... 62
Figure 32 Collaboration diagram for login .................................................................................................. 63
Figure 33 Collaboration diagram for serve student .................................................................................... 64
Figure 34 Collaboration diagram for report generate ................................................................................. 65
Figure 35 layering class diagram ................................................................................................................. 66
Figure 36 Component diagram ................................................................................................................... 67
Figure 37 Deployment Diagram .................................................................................................................. 68
Figure 38 Persistence modeling diagram .................................................................................................... 69

v
 Table of Table
Table 1 time feasibility .................................................................................................................................. 9
Table 2 team organization ............................................................................................................................ 9
Table 3 login use case scenario ................................................................................................................... 22
Table 4 register student use case scenario .................................................................................................. 24
Table 5 Use case scenario to generate report ............................................................................................. 26
Table 6 Use case scenario post news .......................................................................................................... 27
Table 7Use case scenario of update student info ........................................................................................ 29
Table 8 use case scenario of give comment ................................................................................................ 31
Table 9 Use case scenario of serve student ................................................................................................. 32
Table 10 Access control and Security ……………………….......................................................73
Table 11 summery of Appendix……………………………………………...............................75

vi
 Acknowledgement

First of all we would like to express our special thanks to Almighty Allah who helped me a lot in
all our life. Next we would like to express our deepest gratitude to our Department Information
Technology for his all way help and kind assistance in our project.

This project would not have been possible without the support of many people. From the
formative stages of this paper to the final, we would like to express our Last but not the least we
would like to give our best gratitude from bottom of our heart to our advisor Mr. ABEBAW
ESHETU for his valuable advice and comments.

We would also like to thank our Coordinator Mr.Wogayehu and all staffs in Information
Technology department those who help us in our project. Special thanks also to all our graduate
friends, especially group members Sadik, Aliy, Mohammed, Miftaha and Sherifa for sharing the
literature and invaluable assistance. Not forgetting to our best friends who always been there.
We would also like to convey thanks to the Department of Information Technology for
providing the computer laboratory facilities. We wish to express our love and gratitude to our
beloved families; for their understanding & endless love, through the duration of our studies.
Finally we want to thanks all people who give necessary information and help us during
information gathering.

vii
 Abstract

The study focus on the functionality of Automated Student Meal service management system in
terms of Ticking system, data handling, accuracy, security, stability and adaptability in giving
service to students. This study was conducted in Haramaya University specifically in college of
computing and informatics by group members of Information Technology department students
during the first semester academic year 2014-2015. The respondents of this study were the
manual system Ticker of all cafeterias of the Haramaya University Tickers and food item
distribution of them. They properly respond to us over all activity of the process of making the
ticking and also we asked Cafeteria manager. The study concluded that the manual and the
automated Student Meal service management system are both functional. However, the
automated system is more functional because of its extra features which solve the primary
problems in ticking system. We used object oriented approach to analysis and to design the
system. Also we used method of data collection interview and observation. The system is
developed by JAVA SERVLET and MYSQL Server and the system is successfully deployed to
support all cafeteria of the Haramaya University. The system analysis phase shows that what the
existing system do and what the problems are. But the design phase shows the new proposed
system and it shows the solutions to the problems of the existing syste

viii
1
 CHAPTER ONE

1.1. Introduction
One of the remarkable and much known products of technology advancement is the conversion
of manual system into automated system. Automation produces a great impact in the lives of
man, particularly in the field of industry, business, medicine and educations. It is the fact that
making the cafeteria barcode enabled ticking system and automation of some activities such as
food item distribution, meal menu, redundancy of data, double entry of students, report of the
activities in the cafeteria and identifying depends on their case(i.e. fasting and non-fasting). But
before cafeteria use the manual system to perform these activities. This application improves the
traditional manual processing system.

With the manual system, more time, money and labor force is required to plot, to prepare meal
card, arrange and control the attendance of the workers and meal menu. With these problems, we
have planned to improve ticking system and food item distribution control by making barcode
enabled cafeteria ticking system and automated food item distribution control. Through these
advancement errors in operations have been minimized and time, cost and manpower have been
conserved.

1.2. Background
HU cafeteria was established in 1952 and the system is paper based, no one has been tried to
automate it. Still the office is working different activities through this manual system. Because of
this, the office is facing a lot of problems such as loss of data or paper, wastage of time in data
processing, lack of manageable tasks, burdens of work on the workers, conflict between student
and tickers and so on.

As the Cafeteria becomes growing its services providing also became complex and it is difficult
to accomplish in efficient way because the system is manual system. So, need to be automated.

1
1.3 Description of Existing System
The cafeteria management of HU is manual. It has many drawbacks like, managing workers and
students while using cafeteria services, which leads to be unmanageable. Since it works
manually, information accessing is very slow, and get some task to be accomplished it goes
through many processes this is time consuming and it is costly.

The cafeteria management System has four major subsystems; namely workers management,
resource management, operational and student’s management during they are getting services
from cafeteria. Among these subsystems we are going to automate the food item distribution
control and students management subsystem that can involve in the cafeteria services. Since,
activities of Cafeteria Management System are performed in the manual system, there are many
drawback starting from giving meal card to students up to managing while they are using the
service and managing whether the workers of cafeteria giving appropriate service or not. Our
aim is to make ticking system and workers management computerized and so that the problems
faced in the manual system will be minimized. The purpose of this system is to automate and
manage the ticking system and food item distribution control.

2
1.3.1 Use Case of Existing System

Figure 1 Existing System Use Case Diagram

3
1.4 Statements of the Problem

HU Meal Service Management System currently has so many problems, because the system is
manually operating. Those problems are:-

 Time consuming and costly:- by giving the meal card to the students, which can
take much time, money and need many labor force
 Boring: - Ticking the students’ meal card while they are entering the cafeteria to
get food services.
 Re-printing when the students lost their meal card
 Problem of information distribution
 Problems of information redundancy
 Inaccuracy of information:- due to fault occurred during food item distribution to
each cafeteria
 Error during reporting
 Problems occur concerning special case and readmitted students

1.5 Objective of the Project

1.5.1 General Objectives

The general objective of this project is to develop interactive web-based system in order to
overcome the problems with the existing system by making the ticking system of cafeteria
Barcode Enabled and computerized food item distribution control.

1.5.2 Specific Objectives

 To minimize work complexity of the existing system
 To reduce the wastage of time
 To change meal system into barcode enabled
 To control and monitor not allowed students from entering cafeteria
 Enabling students to use their cost share
 Managing food item inquiry of each cafe

4
  To minimize the amount of cost paid by semester to print meal card
 To reduce the redundancy of information
 To generate efficient report
 To handle the problem of readmitted and special case student

1.6 Methodology

A system development methodology refers to the framework that is used to structure, plan,
and control the process of developing an information system. Generally we are going to do a
thorough research and inspection to gather the right amount of data needed to develop this
website either directly from the client or by research methods.

1.6.1 Data Collection Method

The method we use for data collections are:

A) Interview: This is one of data collection method that enables to gather information from
the organization directly in the form of asking question and getting answers for those
questions. So, we have used this method to gather information by asking the head and
staff of cafeteria management system some basic questions.
i) Question that we are asked
 How ticking system is going on?
 During ticking are there any problems? If there what are they?
 What requirements are needed for the process?
 Who is responsible for what?
 How to handle problem of special case and readmitted student?
 How to control food item distribution to each cafeteria?
 How to generate report?
B. Observation: This is also another data collecting method. In fact we have also used
this observation method to gather data. This method enables us observing and
understanding how the cafeteria management system is done.

1.6.2 Data Processing and Use

We have gathered information by using the above methods, and the methods help us to
get information about the existing system. As we have asked the student cafeteria

5
 management system. They told us the main actors of the system and their responsibilities.
From the documents given to us we understand some terms which are new for us, and we
used those terms and their interpretation in the time of identifying actors and use cases of
the system.

1.6.3 System Development Tools

We used UML, Visual Paradigm 12.0 and Microsoft Visio while we are designing our new
system. The development tools that we will use are:

 For the front-end application we used JAVA BOOTSTRAP

 For the back-end application we used MYSQL database
 And we use XAMPP server to configure a MYSQL database.
 Server side scripting JAVA(servlet)
 Client side scripting by considering the following characteristics we use Java script. It
can be embedded in HTML page and it is very popular in validation process.
 Power point and MS-word for presentation

1.6.4 Implementation Tools

The tools that we would like to use for the implementation of these projects are listed below:

i) Software:-
 Window 7 operating system
 Netbeans
 MYSQL server version 5.1.4
 XAMPP Server
 MICROSOFT OFFICE 2010
 Star UML
ii) Hardware
 Computers
 Cables
 Barcode reader
 Barcode
 News TV

6
1.6.5 Approach
The object-oriented approach to software development is decidedly a part of the mainstream
simply because it has proven to be of value in building systems in all sorts of problem domains
and encompassing all degrees of size and complexity. Furthermore, most contemporary
languages, operating systems, and tools are object-oriented in some fashion, giving greater cause
to view the world in terms of objects. Object-oriented development provides the conceptual
foundation for assembling systems out of components using different technology such as.

1.7 Feasibility
Feasibility is a measure of how beneficial and practical the development of an information
system will be. Given enough time, money, and personnel, almost all system projects are
feasible. Feasibility studies provide the information that allows management to:

 Pick one of several possible alternative systems that meet the requirements.
 Decide if a system project should proceed to the next phase
 Choose between several systems projects that must compete for the same set of limited
resources.

1.7.1 Economic Feasibility

I) Tangible Benefits: - Benefits that are easily quantified from the conducted system
are:
Fastest processing time and reduced processing error.

Small response time and many services

Reduce cost for manual data management (Reduced expenses)

Easy update & retrieval on stored records

II) Intangible Benefits: -Benefits from the system that areas unquantifiable are;
Better decision making

Better service to the cafeteria

Little job burden to employees of cafeteria

7
1.7.2 Operational Feasibility
Operational feasibility is a measure of how well the solution will work in the organization.
Operational feasibility is dependent up on the human resources available for the system. It can
solve the problems in Student meal card ticking system and food item distribution management;
therefore it will minimize the amount of effort to do all through manually. And it will perform
the basic content Barcode enabled ticking system and food item distribution management
functionality.

1.7.3 Technical Feasibility

Technological feasibility measures the practicality of a specific technical solution to the problem.
It is also a measure of the availability of technical resources and expertise. Technical feasibility
is assessing the organization’s ability to construct the system. Since the SMSMS needs technical
resources to implement, like computer with barcode reader and barcode. We expect that, the
system can be operated in simple way and concerned users can access easily by giving some
training for them.

1.7.4 Time Feasibility (using Gantt chart)

This involves questions such as how much time is available to build the new system, when it can
be built (i.e. during holidays) interference with normal business operation etc. The schedule for
this project is feasible due to rich information exchange between the organization (client) and the
developing team. In addition to the time set to develop the system is enough to complete the
project on time.

8
 2014 2015
No. Task Name Dec15,2013 Dec24,2013 Jan3,2014 jan18,2014
Mar26, 2014 May 20,2014
1 Requirement
gathering i

2 SRS
3 Design Document

4 Implementation
document
5 Operation testing

Table 1 time feasibility

1.7.5 Team Organization

Time organization provides a description of our team member’s roles and reporting relationships.
The project team has 5 members for the accomplishment of the SMSMS. Generally, the task of
each member can be expressed in a table form as follows.

Team member Responsibility

Aliy Hussein Manager and Programmer

Sadik Abas Coordinator and Programmer

Mohammed Ahmed Assistant Designer

Miftaha Abadir Designer

Sherifa Shemsadin Analyst

Table 2 team organization

9
1.7.6 Communication Plan
Communication plan provides a description of the communication procedures to be followed
management and our team members. Rules that we assign for the success of our project is as
follows.

 We meet minimum 4 days per week.

 Communicate or gather new information is our main target

1.8 Project Scope and Limitation

1.8.1 Scope of the Project

The scope of our project is limited to the barcode enabled ticking system and food item
distribution of HU cafeteria. We limit our scope to only the activity that can be done by the
manager, ticker and store keeper and automating ticking system of the cafeteria subsystem due to
the following constraints.

Among those constraints time, budget, and information accessing are the major ones. We select
the activity that can be done by automating ticking system and by the manager of the subsystem
of the cafeteria management system of HU.

Generally the scopes of our project are:

 Making ticking system barcode enabled

 Identifying the students by their case (i.e. health case, fasting, non-café, punished)
 Report generating
 Checks the re-admitted student and update their information to take the cafeteria service.
 News (in the case of time postpone, menu change, special days)
 Food item distribution management
 Cost share management

1.8.2 Limitation of the Project

Due to the shortage of time and others mini projects the following activities will not be include
to be automated in the existing system. It is better to inform others who are interested to on this
project.

10
  Connecting with branch campus(Pilate project)
 Attendance track of the workers

1.9 Significance of the Project

After completion of this project it will provide the following significant for the Haramaya
University Student Cafeteria Meal Service Management System; it will reduce cost of meal card
to duplicate and distribute. It provides updated information to students such as announcing the
menu change, give comment and etc.

 Students can get news information from internet

 The tickers can serve student easily and
 The manager and the storekeeper can generate information they need.
 The problem with special case and readmission will be solved
 Cost share management will be done easily

1.10 Organization of the Project

This project has three chapters and every chapter has unique contents. The first chapter is the
proposal part that deals about the background of the Organization, statement of the problem,
scope of the project, limitation of the project and feasibility of the project. Chapter two is overall
analysis of the existing system and proposed system that contains details of use case
documentation and use diagram for the new proposed system. It also contains the flow of activity
that show how each and every activity of the project is performed such as sequence diagram,
activity diagram and state chart diagram. The other thing which is discussed under this chapter is
CRC card for the system that helps to identify object of the system and how they interacts or
collaborate with each other and class diagram which is the building block of the system which
we will develop

11
CHAPTER TWO ANALYSIS

2.1. Existing System Description

The current cafeteria system is operated manually. This system has some drawbacks. Like
managing food item distribution and student while they are using the cafeteria services, which
may leads to be unmanageable.

Some of the activities which are performed under the existing systems are:

 Printing meal card by the number of the students

 Distributing the meal card to the students
 Ticking meal card while students getting services from cafeteria
 Managing food item distribution

The cafeteria management system has four subsystems, namely workers management, resource
management, operational management and student’s management during they are getting
services from cafeteria. Among this subsystem we are going to automate food item distribution
and barcode enabled cafeteria system. The architecture of existing cafeteria management system
is as follow

12
 Head of cafeteria

Assistant chief

Worker leader Head ticker Resource leaders Operator

leaders

Shift leader Guard Tickers

Laundry Boiler
(Ticking system) operators operators

Junior shift

Store men Injera house Bread store

leader controller

Cook Dish Food

washer prepare
Dough Injera
makers prepare

Fixed asset Consumable Vegetable

store men store men store men

Figure 2 the Architecture of Cafeteria Management System

13
2.2 Activities Performed under the Existing System
Activities performed in the existing system of HU CMS are done manually. Starting from giving
meal card to the students which can take many times and needs man labor force up to ticking
students meal card while they are entering the cafeteria hall to get food services.

The ticking system of HU cafeteria using now is first they print the meal card that has its unique
number for each student and distribute it for all students. This need much man power and money
efforts of that man power and approximately 2 weeds. These meal cards are only used for one
semester and the process is continues in the second semester. These can take much time, man
power effort and many losses of printed papers every semester. After that when the students use
the cafeteria services the tickers used to tick for all students for breakfast, lunch and dinner three
times per day. This is a difficult work to control those much student properly.

The distribution of food item was the big serious issues that may leads to conflict coworkers of
the cafeteria. The reason of this is that, the number of food items that was distributed at one time
for one cafeteria was so many this difficult to manage. The other reason behind this that, the
workers do not give attention while they took these food items this leads to inappropriate report
on the food item distribution of cafeteria to the manager. Due these and the other reasons the
students cannot use their cost sharing properly as budgeted from the campus.

2.3 Role players in the existing system

The role players of these systems are cafeteria managers, tickers, storekeeper, and
students.

2.3.1 Cafeteria Managers

 Preparing the meal card number.
 Assigning ticker for each cafeteria.
 Receiving registered student form registrar.
 Controlling overall activities of cafeteria.
 Controlling all workers of cafeteria.
 Prepare report to student service directorate.

14
  Punish the wrongdoer student based on the cafeteria rule.

2.3.2 Tickers
 Give meal card to the students.
 Ticking the meal card of the student while they take service.
 Post news related with cafeteria.
 Control student

2.3.3 Students
 Appling to be registered.
 Getting the meal card.
 See news posted by ticker on board.
 Give comment by coming physically to the tickers’ head, manager etc. ---.
 Getting cafeteria service.

2.3.4 Store keeper

 Mange the store.
 Order item.
 Distribute the item to each cafeteria according to their need.
 Generate report by paper to cafeteria manager.

2.4 Business Rule

Business rule is a rule of business, company or corporation. It is a rule that defines or constrains
some aspect of business and always resolves to either true or false. Business rules are intended to
assert business structure or to control or influence the behavior of the business. Business rules
describe the operations, definitions and constraints that applied to an organization. Business rules
can applied to people, processes, corporate behavior and computing system in an organization,
and are put in place to help the organization to achieve its goals.

The following common rules and constraints associated with different resources:

#BR1:-Cafeteria system management is the office who is responsible for giving meal
services for the students.

15
#BR2:-The office prepare meal card having two weeds and distribute for the students by the
semester

#BR3:-Students who is negligible to make meal card is the one who is registered and have the
slip

#BR4:-The time slot is 12:00-2:00 local time for breakfast

#BR5:-The time slot is 4:30-7:00 local time for lunch

#BR6:-The time slot is 10:45-1:30 local time for dinner

#BR7:-The students have to keep track of queue while entering cafeteria

#BR8:- The meal cards have to have office seal

#BR9:- The meal card has to be two weeds

#BR10:- The students cannot cross-cut the queue

#BR11:- The students cannot enter twice for one meal time

#BR12:- The students cannot enter the cafeteria without meal card

#BR13:- Using another students meal cards is impossible

#BR14:- Time slot can be scheduled for meals only if they are already informed by head of
cafeteria

#BR15:- Patient students have to have their own identity card

#BR16:- Food item must be distributed based on students cost sharing

2.5 New System (Proposed System)

The proposed system that we analyze has some alternatives that can solve some problem of the
existing system. When we see the solution, making barcode enabled cafeteria system and
automated food item distribution control system it will solve most of the problems in the
cafeteria system. This project has much significance since it is designed to solve particular

16
problem, providing the solution is the main significance but to specify the following are also the
significance:

 Reduce the time and tasks required to perform the operation within the cafeteria
 It will change the manual processing to the automated one
 It will provide speed, efficient, flexibility, reliability, and security
 For managers, better food items distribution control and report generation
 It will reduce information redundancy

2.6 Non-Functional Requirements and Constraints

Non-functional requirements are the requirements that specify criteria that can be used to judge
the operation of the system rather than the specific behavior. Those are:

I. Security

Consideration of the security issue has a great advantage for our system, because the database
server should be secured from unauthorized users. Only the system administrator (the cafeteria
manager should use system for security purpose) and those who have access permission can
access the database. To prevent from the unauthorized users, the administrator should have a
password and it is used privatized only for who has access right. To do this our system
introduces the hash security authentication for the manager of the cafeteria.

II. Performance

Performance characteristics include speed constraints: this system will be accessed by authorized
BEMFIDC system and it will handle huge amount of student’s records and food item records.
Therefore it is important to consider the speed of access data from the database.

 Response time, the speed imposed on the system. The system should be responsive
maximum number of tasks within a minimum time.
 Throughput:- number of tasks accomplished in a fixed period of times
 Memory: - memory space available for speed optimization should used efficiently.
III. Reliability

17
That’s no system error so far from testing, /therefore the system is reliable. All information
modified or uploaded by manager didn’t lead to any conflict or error to the system.

IV. Availability

In computer systems and networking, availability is a general term that is used to describe the
amount of time over a one year period that the system resources is available in the wake of
components failures in the system. Our system can also available to give services and as it
needed it can be maintained.

V. Maintainability

Maintainability is characteristics of design and installation which determines the probability that
a failed equipment, machine or system can be restored to its normal operable state within a given
timeframe, using the prescribed practices procedures. Its two main components are serviceability
(ease of conducting scheduled inspections and servicing) and reparability (ease of restoring
service after a failure).

VI. Portability

The system is able to run on different platforms as long as operating system is installed

2.7 Functional Requirements

Functional requirements are mandatory requirements that must be incorporated in any system.
Among the functional requirements included in our system are:

 Login into the system; authorized user can login the system
 Manage user’s account including creating and updating
 Post updated news; for students such information is, menu change time or date.
In addition to these our system performs the following functionality.
i. Provides Information about HU Students:

18
Since the existing system of CMS of HU particularly in giving the meal card and ticking system
is the major tasks that done to give service while the students are using the cafeteria.

ii. Data storage and Retrieval

The system stores the student’s record and information related to the ID’s barcode and the
process how to distribute to the student and should retrieve the information when necessary. The
retrieval of information should be easy and data should be saved properly in a well organized
database server so that the process of data retrieving would be simple and faster.

iii. Enquiries and report facilities

The system must incorporate reports generalization facilities so that an administrator of the
system can easily filter out the report of each task. The functional requirement of the system is to
reduce the degree of occurrence of the above mentioned problems. So it is very crucial to
identify the input and out requirements of the proposed system.

The functional requirement of the giving ID’s barcode and scanning system are the inputs and
outputs necessary for this subsystem.

2.8 Use Case View

Use case approaches require the analyst to determine all the potential actors involved in a
system. Actors are external to the system and make use of it. An actor is typically a person, but
may be a third-party organization or another computer system.

An actor makes use of a system in different ways. Each of these ways is known as use cases. Use
case is a behaviorally related sequence of transaction (performed by a user/actor) in a dialog with
the system. A use case may involve a number of actors, just as an individual actor may make use
of several use case.

In our system we have four actors:

1. Manager:-the person who control overall activity of the cafeteria as administrator of the
cafeteria

19
 2. Ticker:-is the person who serves the students while they are using cafeteria by ticking
their meal card and give the meal card in the case of existing system.
3. Student:- is the user of the cafeteria who is available in the campus for educational
purpose
4. Store keeper:- the person who manage and distribute food item for all cafeteria and
generate report for the manager.

2.8.1 Use case Identification

Identifying the activities that are mainly performed on the proposed system is the basic thing in
analyzing a new system. The following use cases have been identified from the system
specification.

1. Login
2. View comment
3. Generate report
4. Post news
5. Update student info
6. Order item
7. Search item
8. Delete item
9. Update item
10. Serve student
11. Give Comment
12. register student
13. system security

2.9 Use case Diagram

Use case diagrams graphically describe system behavior (use case). These diagrams present a
high level view of how the system is used as viewed from an outsider’s (actor’s) perspective.
From the identified use cases and actors the use case diagram of the system is shown below:

20
 System

Generate
report

<<include>> logout
Update
<<Extend>>
manager student info
<<include>>
<<include>>Update

Post login item

<<include>>
news
<<include>>
storekeeper
<<include>>
View Search item
<<include>>
comment

Delete
Register item
<<include>>
student
Order item

Give
comment Serve
student

ticker
View
student news

Figure 3 use case diagram of the proposed system

21
2.10 Use Case Documentation
Table 3 login use case scenario

Login

Use case name

Identifier UC1

Description When user enters id and password, it checks the input

from the database. If it is
Valid, it allows the user to access and if not it returns to
login form.

Actor1 Manager

Actor2 Store keeper

Actor3 Ticker

Pre-condition The user must be authorized user who has username and
password to login to the system and access authorized
pages.

Post-condition
The user access the system.

22
Basic course of action 1. The use case is initiated when the user click on
the login link.
2. The session and cookies are created.
3. The user enters username and password.
4. The Authentication controller validates user
information.
5. The Authentication controller send user
information to account model
6. The system verifies whether the user is
authorized or not.
7. Authentication take user into appropriate page
8. Use case end.

Alternative course of action A4. If controller validate error and the system display
error.
A5. The use case continues at step 3.
A6. If the user does not fill the correct username and
password then the system display error message.
A7). The use case continues at step 3.
A8. Use case end.

23
Table 4 register student use case scenario

include Login

Extend ---

Use case name Register student

Identifier UC2

Description The manager registers the student list on his or her

database from the list of student to control the student
use the cafeteria service.

Actor1 Manager

Pre-condition The manger must be an authorized user who has user

name and password.

Post-condition The manger registers the student

Basic course of action 1. The use cases start after login to the
system.

2. Authentication controller loads the

registered from.

3. Manager fill data of student to

registrations form

24
 4. Deregistration controller validates
information entered.
5. The controller sends data to the register
table.
6. Student registered.
7. Use case end.

Alternative course of action A2. If Authentication control validate error and display
error message.

A3) The use case continues at step2.

A4. If DoResigteration controller validate error and

system display error message.

A5) The use case continues at step3

A6.Use case end.

25
Table 5 Use case scenario to generate report

Use case name Generate report

Include Login

Extend -

Identifier UC3

Description This process is performed by the manager and

store keeper

1. the manager have to provide daily or

monthly report to concerned body
2. the store keeper have to provide the
food item distribution menu to the
cafeteria manager

Actor1 Manager

Actor2 Store keeper

Pre-condition 1. the manager and store must be an

authorized user who has user name and
password

Post-condition 1. the manager generate necessary

information (report)
2. the store keeper generate report

Basic course of action 1. this use case is initiated when the user
wants to generate report
2. The use cases start after login to the

26
 system.
3. The login controller loads the report
generate form or pages
4. The user click on report link
5. The users(manager and stoke keeper)
fill the report they went to generate.
6. The report controller validates the filled
data by the manager and stoke keeper
in the form.
7. The report generated
8. The use case end.

Alternative course of action A6) If the controller validates and get error
then the system display the error

A7) The use case continues at step 5

B10) use case end

Table 6 Use case scenario post news

Use case name Post news

Include Login

Extend -

Identifier UC4

27
Description The process is performed by manager

1. The manager posts currently issues of the

cafeteria to the user on the site in the case sudden
change of food menu, time and other issues.

Actor Manager

Post-condition The manager then post the news to the site

Basic course of action 1. The use case starts after the user log in to the
system.
2. The account controller load the post news
form
3. The manager write the news
4.
5. The system save the news
6. The use case end

Alternative course of action A2.if the controller validate user name and password
and get error

A4. The use case continues at step 1

B3. if system validate the entered data is not valid

B4) The use case continues at step 1

B7) the use case ends.

28
Table 7Use case scenario of update student info

Use case name Update student info

include Login

Extend -

Identifier UC5

Description The process is performed by manager.

1. The manager updates student information time to

time.

Actor Manager

Pre-condition 1. The manager have to enter to username and

password
2. The privilege of the manager must be
administrator

Post-condition 1. The manager see updated information.

Basic course of action 1. The use case is start after the manager log in
to the system.
2. The account controller loads the update form.
3. The user fill up the form

29
 4. The user presses the update button.
5. The update controller validates the entered
information.
6. The controller send information to the update
table.
7. The system validates the entry.
8. The system changes the information on the
database.
9. The use case end.

Alternative course of action A1. If not login to the system.

A2. The use case continues at step 1

A5. If update controller validate error and display error

message.

A6. The use case continues at step 3

B7.if the system validate the entered information not

matched and display error message

B8. The use case continues at step 5

B9. Use case end.

30
Table 8 use case scenario of give comment

Use case name Give comment to the system

include -

Extend -

Identifier UC6

Actor Student

Pre-condition The use case needed to give comment to the manager

Post-condition Entered user comment or saved suggestion.

Basic course of action 1. The user initiate the page to give comment
2. The system display the comment form
3. The user writes the comment to be sent to
manager.
4. The comment controller validates the entry.
5. The system save the comment
6. The use case end.
.

Alternative course of action A4) if the form is not filled.

A5) The use case continues at step 3.

A6) the use case end.

31
Table 9 Use case scenario of serve student

Use case name Serve student

include Login

extend -

Identifier UC7

Description The process is performed by ticker.

The ticker scan the student Id to make the

student to use their cafeteria service in correct
manner

Actor Ticker

Pre-condition The ticker need to scan students ID

Basic course of action 1. This use case is initiated when the user
went to give service to the student or
when the user went to scan student ID
2. The ticker wants to loin to the system
3. The user enter his/her name and password
4. The account controller validate the entry
5. The controller send the information to the
student data model
6. The system verifies whether the user is an
authorized or not.
7. The controller loads the Ticker page.

32
 8. The ticker scan the student Id
9. The system validate the scanned Id
10. The students get service.
11. The use case end.

Alternative course of action A4. Validate the information error and display error
message

A5. The use case continues at step 3

B9, validate information is error, system display error

message.

B10. The student communicates with ticker.

Post-condition The student get food services

2.11 Sequence diagram model

A sequence diagram links use case with objects. It shows the interaction between participating
objects in a given use case. It is helpful to identify the missing objects that are not identified in
the analysis object model. From the use case and the class diagrams shown in the previous
section the sequence diagrams of the system is shown as follows:

33
 Web server Logon screen Main Contoller Security Control Model: session store Model: cookie store Model: database
| | | | | | |
| | | | | |
|
Startup | | |
|
| |
|
| | | | |
Initialize page | | | | |
| | | |
Create new session()| | | |
| | |
| | |
|
| | |
Create| new cookie() |
| |
|
| |
|
| | | |
| |
| | | |
| |
| | | |
| |
Login | | | |
|
| | | |
Onlogin click() | Validate User(name, | |
| |
|
password) | | | |
| | |
|
| | |
| | |
User Detail: |check user detail() |
| |
Validate() | | |
| | |
| | |
| | |
Result Set() | | |
| | |
|
Bool success/failure | | | |
| | | |
Access denied/successful | |
| | | |
| | | |
| |
| | | |
| close | | | | |
| | | | |
| |
| | | |
Take user to alternative page | |
| | | |
| |
| | |
| | |
| | | |
| | |
| | |
| | |
| | close
| close | |
close |
| | close | | close
| close | |

Figure 4Sequence diagram for login

34
 login DoRegistration authentication Account model Student model
registerform
manger

Enter(un,pass)

Check user(un,pass)
Validate()

Do select(un,pass)
Close()
success

Load registration form

Display() Do validation()

Close()
Fill form() Close()
Do register()
Do insert(in put value)

Validate()
View update() Success()
Successful registered

Close()
Close() Close()

Close()
Figure 5Sequence diagram for register student

35
 login reportpage displayreport authentication reportcontroller doreportdisplay account cafeteria

manager
request

Username, password, usertype

Validate()
Check()

Success()
|
| Validate()
| Load()
| |
Filldata() |
| |
Create() | |
Submit()| | | |
| | Validate()
| |
| | Generate()
| |
| | | Success() |
| | | |
| | | Validate() |
| | Load() |
| |
| | | | |
| | displayreport
| | |
| | |
| | |
| | |
| | |
| | | Success() | | |
| | |
Report() | | |
| | | |
| | |
| | | |
| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
|
| | | | |
|
| | | |
| |

Figure 6Sequence for generate report

36
manager loginform Update form Search form Account controller Update controller Search controller :account :updatetable :student

Request()

Username, password ,usertype

Authenticate()

Validate()
Success()

Validate()
Load()
Enterid()
Check(id)
Validate()
Search()

Success()
validate()
Loadupdate()
Filldata()
Check()

Validate()

Update()

Success()

Updated() Validate()

Figure 7Sequence diagram for update student

37
 login homepage authentication Viewcomment account comment

manager

Un, pass, usertype

Validate()
Validate()
Check()

Success()

Validate()

Load()
Fetchcomment()

Success()
Send()
Validate()

View comment()

Figure 8Sequence diagram for view comment

38
 manager :login :ServeStudent :StudentDetail:AuthenticationDoserveStudent DoDisplay :Account :Student :Service

1.request

username, password, usertype

validate()

Authenticate()

success()

validate()
loadsspage()
Showid()
ReadId()

validate()
Check()
Success()

SDloaded Create()

Checked()
DetailDisplayed()
Success()

Figure 9Sequence diagram for serve student

39
 homepage login News form authentication Dopost account

manager
Username, password and usertype

Validate()
Check()
Validate()
Success()
Validate()
Filldata()
Create()

Postnews()
Notify()

Figure 10Sequence diagram for post news

40
2.12 Activity diagrams

Activity diagram is another important diagram in UML to describe dynamic aspects of the
system. Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system. So the control flow
is drawn from one operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different elements like fork, join
etc.

The following activity diagrams are specified in the new system of Barcode enabled HU
cafeteria system.

Browse Website Fill Data

Click LoginButton
Start

Not valid

Verify Data

Valid

Display Userpage

End

Figure 11Login activity diagram

41
 yes Get RegisterationForm
Browse Website Display Homepage Logged In

Start
No
Fill Form

Click RegisterButton

invalid Verify Form

valid

Register Student

End

Figure 12Registration activity diagram

42
 yes
Display Login Page LogedIn
OpenUpdateForm Entrt Searching
Value
Start

no

incorrect
Check value

correct
correct
Update Student Fill Data Display Update
Form

incorrect

Figure 13Update student info activity diagram

43
 Browse Website Display Homepage Display LoginForm Logged In Yes Get ReportForm
Start
No

Fill ReportForm

Invalid
Click GenerateButton

Verify Form

End Valid
Generate Report

Figure 14Report generate activity diagram

44
 Browae Homepage DisplayLoginPage LogedIn Yes
OpenNews
PostForm
Start No

ENterNews

End
Post news

Figure 15Post news activity diagram

45
 Display Homepage DisplayLoginFrom LogedIn
Start

No

Yes
incorrect Open Ticking Page

Generate student
Information

correct
Student show id
Update db

matched

Scan id
End unmatched
Figure 16Serve student activity diagram

46
2.13 State Chart Diagrams

State-chart diagram is one of the five UML diagrams used to model dynamic nature of a
system. They define different states of an object during its lifetime. And these states are changed
by events. So State-chart diagrams are useful to model reactive systems. Reactive systems can be
defined as a system that responds to external or internal events.

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.

The main purposes of using State-chart diagrams are:

 To model dynamic aspect of a system

 To model life time of a reactive system
 To describe different states of an object during its life time
 Define a state machine to model states of an object

47
The state chart of our system is as followed:

Initail state IDLE activates LOGIN Normal exit verify

Not normal exit

check
fail

Successful completion
Confirm log in

Figure 17State-chart for login

48
 Initial state
User activate
Display home Enter(un and pass) Login Normal exit
Idle Verify
page form

Not normal exit

Click on register
reject link

Choose file
To register

Completion state Click on save

button

Figure 18 State chart for register student

49
 User actives Enter(un and pass) Normal exit
Initial state
Display home
Idle Login form verify
page

Click on generate
Not normal exit reject report

Fil the form

Completion of state
generate

Figure 19Generate report state chart

50
 initaite Manager activate Enter(un,pass)
Normal exit
DISPLAY LOGIN FORM VALIDATION
IDLE HOME PAGE
Not normal exit
check

Choose update
reject

display

Search form
Not match
Value match

Click on search

Display

Completion state
Update form

Fill data

Update
s

Figure 20 State chart for update student info

51
 Initial state activates Normal exits
IDLE Login form verfiy

Not normal exit

reject

Choose tick (
Scan) ID

Completion state
Log out

Figure 21 State chart for serve student

52
 2.14 Key Abstraction with CRC Analysis

Class Responsibility Collaborator (CRC) Modeling is a method to gather and define the user
requirements for an object-oriented application. The output of CRC Modeling is a CRC model
which is a collection of CRC cards that represent the whole or part of an application or problem
domain.

Figure 22 CRC diagram

53
 2.15 Conceptual: modeling class diagram
In object oriented system Analysis, Real world concepts are modeled into objects. Conceptual
modeling here by allows us to model these concepts which later involve in to a complete class
models. A class is a set of objects that share a common structure and a common behavior (the
same attributes, operations, relationships and semantics).A class is an abstraction of real world
items.

Figure 23Conceptual Class Diagram

54
2.16 User Interface Prototype

2.16.1 Essential User Interface Prototyping

An essential UI prototype is a low-fidelity model of the UI for our system. It represents the
general ideas behind the UI, but not the exact details. Essential UI prototypes represent UI
requirements in a technology-independent manner, just as essential use case models do for
behavioral requirements. An essential UI prototype is effectively the initial state—the beginning
point of the UI prototype for the system. So, now we don’t need to use technology-based
prototyping tool in order to understand and solve the problem.

Create Account User Interface Prototyping

User First Name Sex

User Last Name Check box

Input fields

Date of birth E-mail id

Drop Down List Password

Input fields

Figure 24 create account prototype

55
 Login UI Prototyping

E-mail id Password

Input field Input field

Figure 25 login prototype

Change password

E-mail id New password

Input field Input field

Confirm password

Input field

Figure 26 change password prototype

56
Figure 27 User interface of home page

57
Figure 28 Registration form user interface

58
 CHAPTER THREE: DESIGN

3. Purpose and Design Goals

3.1 Introduction
System design is the transformation of the analysis model into a system design model. System design
is the first part to get into the solution domain in a software development. This chapter focuses on
transforming the analysis model into the design model that takes into account the nonfunctional
requirements and constraints described in the problem statement and requirement analysis sections
discussed earlier.

3.2 Design Goals

Design goals describe the qualities of the system that the developers should consider. These goals can
be drawn from the non-functional requirements already discussed. The design goals can be generally
grouped into five categories. These are: Performance Criteria, Dependability Criteria, Cost Criteria,
Maintenance Criteria, and End User Criteria.

Performance: The system should respond fast with high throughput, i.e. It should perform searching
information, post news, and, registration processing and generating report in a time less than a minute.

Dependability: The office needs the system to be highly dependable. The system should be
robust (forceful) i.e. it should be able to carry on invalid user inputs, fault tolerant, reliable
and available. The system shouldn’t allow non-authorized users to access students’ personal data
or modify.

Cost: The system should be developed, deployed, administered and maintained with minimum
cost possible.

Maintenance: The code for the system should be easily readable, understandable and
should be easily mapped to specific requirements. Means it is platform.

End User Criteria: The system should have simple and understandable graphical user interface
such as forms and buttons which have descriptive names. It should give reliable response for
each user request at least before the session expires.

59
Usability: Usability is the extent to which a product can be used by specified users to achieve
specified goals with effectiveness, efficiency and satisfaction in a specified context of use.

3.3 Proposed Software Architecture

3.3.1. System decomposition

Figure 29 Subsystem decomposition diagram

60
3.3.2. Design Class Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their relationships. We
use class diagrams to model the static design view of a system. Class diagrams are also the
foundation for a couple of related diagrams: component diagrams and deployment diagrams.

Figure 30 Design Class Diagram

61
3.3.3. Inheritance Class Diagram
Inheritance class diagram is class diagram that is inherited from design class diagram that have
common properties with each other. It is used to show the relation of two or more classes that
have common properties that are inherited from each other.

Figure 31Inheritance Class Diagram

62
3.4 Collaboration Diagram

Collaboration diagram is another form of interaction diagram. It represents the structural

organization of a system and the messages sent/received. Structural organization consists of
objects and links. The purpose of collaboration diagram is similar to sequence diagram. But the
specific purpose of collaboration diagram is to visualize the organization of objects and their
interaction.

1 start up()
3. create new session()
2 initiaize page 5. enter username
And password
Session
4. create new cookies()controller
11. access success/denied
user Logon screen
6 onlogin click()
9. success/ failure
7. validate nuser(name Cookies controller
And password)
10. validate
8. check user detail()

Authentication
9. respond bool() account

Figure 32Collaboration diagram for login

63
 2.Enter (u name,pass,user 3. validate()
1. request() type)

Login form
7. Show id() Authentication
ticker 6.Load()
4. Authenticate()
5. successs()

8. read Id() account

18. see result 9. Validate()

10. check()
13. load ()
11. success()

12. craete()
15. validate()

Display page
13.checked
16. Detail display()
Do display
14. sucess

Figure 33Collaboration diagram for serve student

64
 2.Enter (u name,pass,user 3. validate()
1. request() type)

Login form
7. fill data() Authentication
ticker 8. click submit() 6.Load()
4. Authenticate()
5. successs()

10. Validate()
Report page 9. craete() account
17. see result

Report 11. generate()

controller
12. success()

15. click generae() 14. validate() 13. craete()

Display report page

16. Detail display()

Do generae report

Figure 34Collaboration diagram for report generate

65
3.5 Layering Class Diagram
A common architectural strategy, layering class model, is to layer the architecture of a system
into several layers. The various layers are represented by the rectangles and collaboration
between layers by the arrows. The primary name of a layer is indicated first, and other common
names in parenthesis.

User Interface Class

Authentication Form
Serve Student Form
Register Student Form
Report
Comment

Process Class
Domain class
Student Account controller
Ticker Registration controller
Serve student controller System Class
Cafeteria
Manager
storekeeper

Persistance Class

Database

Figure 35layering class diagram

66
3.6 Component Diagram
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. This in some extent shows which component or objects will be accessed by whom
and what type of security infrastructures it is using. The diagram is simulated below:

on
rypti
p ort E nc Security
s Re <<infrastructure>>
ces
a Ac ol
D at Report
o ntr
sC
ces
Ac
u nt
cco
Meal Service Management sA
ces Persistence
<<application>> a Ac Account
t <<infrastructure>>

e
a

nc
D

te
s
rsi
nt

pe
tu de
sS
ces
a Ac Student
D at

User Management
<<application>> or
ect
nn
Item l co
em Sq
s s it My
ce
Ac
D ata Mysql
<<database>>

ice
S erv
Store Management nt
de
<<application>> Stu
ss Student Service
Acce
D ata

Cost Share Management

<<application>>

Figure 36Component diagram

67
3.6 Deployment Diagram
Deployment modeling is used to show the hardware of the system, the software that is installed
in the hardware and also the middleware that is used to connect the disparate machines to one
and other. It also shows how the software and the hardware components work together.

Figure 37 Deployment Diagram

68
3.7 Persistence Modeling for Object Oriented Database
Persistence modeling is the diagram that shows the relationship between the tables that
interrelated with each other. It also shows self relation of the tables. It is only used for object
oriented database modeling; but for relational database modeling we use Entity Relationship
modeling instead of Persistence to show the relation of tables with each other.

Figure 38 Persistence modeling diagram

69
 3.8 Access Control and Security

Because of our system being multi-user environment, different actors have access to different
functionality and data. During analysis, we modeled this distinction by associating different use
cases to different actors. During system design, we model access by examining the object model,
by determining which objects are shared among actors, and by defining how actors can control
access. Depending on the security requirements on the system, we also define how actors are
authenticated to the system. The following access control matrix shows which user has access to
which function.

Actors Functionalities

Manage Info Register news Give Comment

service

manager Has authority to Register student Post news View comment given
create, update, student
delete account and
to generate report,

Ticker Has permission to View news Serve

login to his/her posted by the student
account manager

Store keeper Has permission to

login to his/her
account

Has authority to
delete, update and
add item and to
generate report.

70
student Access home page Has the authority to View news Has Write comment
be registered posted by authority
manager to get
service

Table 10 Actor Access control and security table

71
3.9. Appendixes

symbol Description
Actor

System boundary

Decision

Use case

Class

Component diagram

Destroy

Object life line

Deployment diagram

Note

Message line extends from the lifeline of one object to the

lifeline.
Return message extend from the lifeline of one object to the
lifeline

72
 Starting point of activity/state diagram

Ending point of activity/state diagram

MVC Model view controller

Xampp server

View of MVC

Controller of MVC

Model of MVC

BR Business rule

Interface
Note

Time Activation

73
Self deligation

Message call

Message return

Horizontal synchronization

Multiplicity many(zero)

Package

Mandatory

Object

Association role

74
 Transition

UC Use case
CRC Class Responsibility collaborator
HU Haramaya university
Integrated Development Tool
IDE

Cafeteria Management System

CMS

UML Unified Modeling Language

UI User Interface

Table 11 summery of Appendix table

75
 3.10. Relevant reference
 Mike O’Docherty, (30 JUNE 2002), Understanding System Development with UML
2.0, John Wiley & Sons Ltd, The Atrium, Southern Gate, Chichester,
West Sussex PO19 8SQ, England
 Object-Oriented Analysis and Design Using UML OO-226 Sun Microsystems, Inc.,
4150 Network Circle, Santa Clara, California, 95054, U.S.A.

Scott W. Ambler, The Object Primer, Third Edition, Trumpington Street, Cambridge,
United Kingdom.( http://www.cambridge.org/)
 MVC Tutorials given to us by Mr. Abebew Eshetu

76