Industrial project i12

i
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

ii
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

iii
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

iv
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

v
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

vi
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

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

viii
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

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.

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

3
1.3.1 Use Case of Existing System
Figure 1 Existing System Use Case Diagram

4
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

5
 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

6
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

7
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

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

9
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.
Table 2 team organization
No. Task Name
2014 2015
Dec15,2013 Dec24,2013 Jan3,2014 jan18,2014
Mar26, 2014 May 20,2014
1 Requirement
gathering
2 SRS
3 Design Document
4 Implementation
document
5 Operation testing
Team member Responsibility
Aliy Hussein Manager and Programmer
Sadik Abas Coordinator and Programmer
Mohammed Ahmed Assistant Designer
Miftaha Abadir Designer
Sherifa Shemsadin Analyst
i

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

11
 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

12
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

13
Figure 2 the Architecture of Cafeteria Management System
Head of cafeteria
Assistant chief
Guard
Boiler
operators
Laundry
operators
Store men
Shift leader
Injera house
leader
Bread store
controller
Tickers
(Ticking system)
Food
prepare
Dish
washer
Cook
Resource leaders Operator
leaders
Head tickerWorker leader
Junior shift
Dough
makers
Injera
prepare
Vegetable
store men
Consumable
store men
Fixed asset
store men

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

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

16
#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

17
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

18
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:

19
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

20
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:

21
manager
student
storekeeper
ticker
System
Generate
report
Update
item
Search item
Order item
Delete
item
Serve
student
View
news
Give
comment
Register
student
Update
student info
Post
news
View
comment
login
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
logout
<<Extend>>
Figure 3 use case diagram of the proposed system

22
2.10 Use Case Documentation
Table 3 login use case scenario
Use case name
Login
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.

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

24
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

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

26
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

27
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

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

29
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

30
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.
Alternative course of action A1. If not login to the system.
A5. If update controller validate error and display error
message.
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.

31
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
.
Alternative course of action A4) if the form is not filled.
A5) The use case continues at step 3.
A6) the use case end.

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

33
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:
8. The ticker scan the student Id
9. The system validate the scanned Id
10. The students get service.
Alternative course of action A4. Validate the information error and display error
message
B9, validate information is error, system display error
message.
B10. The student communicates with ticker.
Post-condition The student get food services

35
login
registerform
DoRegistration authentication Account model Student model
manger
Enter(un,pass)
Check user(un,pass)
Validate()
Do select(un,pass)
success
Do validation()
Load registration form
Display()
Fill form() Do register()
Do insert(in put value)
Success()View update()
Successful registered
Close()
Close()
Close()
Close()
Close()
Close()
Close()
Validate()
Figure 5Sequence diagram for register student

36
login reportpage authentication reportcontrollerdisplayreport doreportdisplay account cafeteria
request
Username, password, usertype
Validate()
Check()
Success()
Validate()
Load()
Create()
Validate()
Generate()
Success()
Validate()
Filldata()
Load()
displayreport
Report()
Success()
Submit()
manager
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 6Sequence for generate report

37
loginformmanager Updateform Searchform Accountcontroller Updatecontroller Searchcontroller :account :updatetable
Validate()
Success()
Authenticate()
Username,password,usertype
Request()
Validate()
Load()
Check(id)
:student
Search()
Success()
Validate()
validate()
Enterid()
Loadupdate()
Filldata()
Check()
Validate()
Update()
Success()
Validate()Updated()
Figure 7Sequence diagram for update student

38
login homepage authentication Viewcomment account comment
Un, pass, usertype
Validate()
Validate()
Check()
Success()
Validate()
Load()
Fetchcomment()
Success()
Send()
View comment()
Validate()
manager
Figure 8Sequence diagram for view comment

39
:ServeStudent :StudentDetail:login :AuthenticationDoserveStudent DoDisplay :Account :Student :Servicemanager
1.request
username, password, usertype
validate()
Authenticate()
success()
validate()
loadsspage()
Showid()
ReadId()
validate()
Check()
Success()
Create()
Checked()
SDloaded
DetailDisplayed()
Success()
Figure 9Sequence diagram for serve student

40
login Newsform authentication Dopost account
manager
homepage
Username,passwordandusertype
Validate()
Check()
Validate()
Success()
Validate()
Create()
Filldata()
Postnews()
Notify()
Figure 10Sequence diagram for post news

41
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 Click LoginButton
Fill Data
Display Userpage
Not valid
Valid
End
Start
Verify Data
Figure 11Login activity diagram

42
BrowseWebsite DisplayHomepage
GetRegisterationForm
FillForm
invalid
valid
RegisterStudent
yes
No
LoggedIn
Start
VerifyForm
ClickRegisterButton
End
Figure 12Registration activity diagram

43
DisplayLoginPage LogedIn
OpenUpdateForm EntrtSearching
Value
Checkvalue
DisplayUpdate
Form
FillData
correct
UpdateStudent
correct
incorrect
incorrect
Start
yes
no
Figure 13Update student info activity diagram

44
BrowseWebsite DisplayHomepage
LoggedIn
GetReportForm
FillReportForm
GenerateReport
Start
No
Yes
ClickGenerateButton
VerifyForm
Valid
Invalid
End
DisplayLoginForm
Figure 14Report generate activity diagram

45
BrowaeHomepage DisplayLoginPage LogedIn
OpenNews
PostForm
ENterNews
Postnews
Start
End
Yes
No
Figure 15Post news activity diagram

46
DisplayHomepage DisplayLoginFrom LogedIn
OpenTickingPage
Studentshowid
Scanid
Updatedb
incorrect
correct
unmatched
matched
Start
End
No
Yes
Generatestudent
Information
Figure 16Serve student activity diagram

47
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

48
The state chart of our system is as followed:
IDLE LOGIN verify
Confirmlogin
Initailstate activates Normalexit
Notnormalexit
fail
check
Successfulcompletion
Figure 17State-chart for login

49
Idle Login
form
Displayhome
page Verify
Initialstate
Useractivate
Enter(unandpass) Normalexit
Notnormalexit
reject
Clickonregister
link
Choosefile
Toregister
Clickonsave
button
Completionstate
Figure 18 State chart for register student

50
Idle
Displayhome
page
Loginform verify
Clickongenerate
report
Filltheform
Initialstate
Useractives Enter(unandpass) Normalexit
Notnormalexit reject
Completionofstate
generate
Figure 19Generate report state chart

51
IDLE
DISPLAY
HOME PAGE
LOGINFORM VALIDATION
Chooseupdate
Searchform
Clickonsearch
initaite Manageractivate Enter(un,pass)
Normalexit
check
Notnormalexit
reject
Updateform
Update
Completionstate
Filldata
Valuematch
Notmatch
Display
display
s
Figure 20 State chart for update student info

52
IDLE
Initialstate activates Normalexits
Loginform verfiy
Choosetick(
Scan)ID
Logout
Completionstate
reject
Notnormalexit
Figure 21 State chart for serve student

53
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

54
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

55
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
User Last Name
Input fields
Sex
Check box
Date of birth
Drop Down List
E-mail id
Password
Input fields
Figure 24 create account prototype

56
Login UI Prototyping
Change password
E-mail id
Input field
Password
Input field
E-mail id
Input field
New password
Input field
Confirm password
Input field
Figure 25 login prototype
Figure 26 change password prototype

57
Figure 27 User interface of home page

58
Figure 28 Registration form user interface

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

60
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

61
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

62
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

63
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.
user Logon screen
Authentication
account
6 onlogin click()
1 start up()
2 initiaize page 5. enter username
And password
7. validate nuser(name
And password)
8. check user detail()
10. validate
9. respond bool()
9. success/ failure
11. access success/denied
Session
controller
3. create new session()
4. create new cookies()
Cookies controller
Figure 32Collaboration diagram for login

64
ticker
1. request()
Login form
2.Enter (u name,pass,user
type)
3. validate()
Authentication
account
4. Authenticate()
5. successs()
6.Load()
7. Show id()
8. read Id()
9. Validate()
10. check()
11. success()
12. craete()
13. load ()
Display page
Do display
13.checked
14. sucess
16. Detail display()
15. validate()
18. see result
Figure 33Collaboration diagram for serve student

65
ticker
Report
controller
1. request()
Login form
2.Enter (u name,pass,user
type)
3.validate()
Authentication
account
4.Authenticate()
5. successs()
6.Load()
7.fill data()
9. craete()
10. Validate()
11. generate()
12. success()
13. craete()
Display report page
Do generae report
16. Detail display()
14. validate()
17.see result
Report page
8. click submit()
15. click generae()
Figure 34Collaboration diagram for report generate

66
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.
Process Class
Account controller
Registration controller
Serve student controller System Class
Domain class
Student
Ticker
Cafeteria
Manager
storekeeper
User Interface Class
Authentication Form
Serve Student Form
Register Student Form
Report
Comment
Persistance Class
Database
Figure 35layering class diagram

67
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:
Meal Service Management
<<application>>
User Management
<<application>>
Store Management
<<application>>
Report
Student
Item
Student Service
Account
Data Access Report
Data Access Account
Data Access Student
Data Access item
Data Access Student Service
Security
<<infrastructure>>
Encryption
Access Control
Persistence
<<infrastructure>>
persistence
Mysql
<<database>>
MySql connector
Cost Share Management
<<application>>
Figure 36Component diagram

68
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

69
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

70
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
service
Comment
manager Has authority to
create, update,
delete account and
to generate report,
Register student Post news View comment given
student
Ticker Has permission to
login to his/her
account
View news
posted by the
manager
Serve
student
Store keeper Has permission to
login to his/her
account
Has authority to
delete, update and
add item and to
generate report.

71
Table 10 Actor Access control and security table
student Access home page Has the authority to
be registered
View news
posted by
manager
Has
authority
to get
service
Write comment

72
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

73
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

74
Self deligation
Message call
Message return
Horizontal synchronization
Multiplicity many(zero)
Package
Mandatory
Object
Association role

75
Transition
UC Use case
CRC Class Responsibility collaborator
HU Haramaya university
IDE
Integrated Development Tool
CMS
Cafeteria Management System
UML Unified Modeling Language
UI User Interface
Table 11 summery of Appendix table

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

Industrial project i12

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to Industrial project i12

Similar to Industrial project i12 (20)

Recently uploaded

Recently uploaded (20)

Industrial project i12