Mattu University

College of Engineering and Technology

Department of Computer Science
Title: Web Based Mattu University Dormitory System

May 15,2025

Mattu, Ethiopia
Page | i
 Approval Sheet
Title: Web Based Mattu University Dormitory System
Project Committee Members:

1st .Member Name And Signature [Link] .Member Name And Signature
____________________________________ __________________________________

[Link] Name And Signature 4th .Member Name And Signature

__________________________________ ____________________________________

5th .Member Name And Signature

__________________________________

Project Examiners Members:

1st .Member Name And Signature 2nd .Member Name And Signature

___________________________________ ____________________________________

3rd .Member Name And Signature 4th .Member Name And Signature

___________________________________ ____________________________________

Advisor Name Signature Advisor Name Signature

___________________________________ ____________________________________

Page | ii
 Acknowledgment
We would like to thanks first our God who helped us through the tough times while developing
this project. Next would like to express our deepest gratitude to our advisor, Mr. Tesfaye A , for
his invaluable guidance, support, and encouragement throughout this project proposal. His
expertise and insights have been instrumental in shaping the direction and success of this work.
And Mr. Tekalign B. who direct and give us best guideline for the compilation of the project We
also extend our heartfelt thanks to the Dormitory office (Tadele Tesfaye) for responding us
necessary data we ask them timely and Computer Science Department at Mattu University for
providing the resources/guide lines and support necessary to complete this work.

Page | iii
 Table of Contents
Approval Sheet................................................................................................................................ ii

Acknowledgment ........................................................................................................................... iii

Acronyms ....................................................................................................................................... ix

List of Tables ................................................................................................................................ xii

List of Figures .............................................................................................................................. xiii

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

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

1.2. Background of the Organization ...................................................................................... 1

1.3. Statement of the Problem ................................................................................................. 2

1.4. Objectives of the Project .................................................................................................. 3

1.4.1. General objective of the project ................................................................................ 3

1.4.2. Specific objective of the project ............................................................................... 3

1.5. Scope of the Project.......................................................................................................... 3

1.6. Limitation of the Project .................................................................................................. 4

1.7. Significance of the Project ............................................................................................... 4

1.8. Methodology .................................................................................................................... 4

1.8.1. Requirement Elicitation Methods ............................................................................. 4

1.8.2. Interview ................................................................................................................... 4

1.8.3. Observation ............................................................................................................... 5

1.8.4. Document Analysis ................................................................................................... 5

1.8.5. Methodology for Analysis and Modeling ................................................................. 5

1.9. System Implementation Method ...................................................................................... 5

1.10. Development and Programming Environment Requirements. ..................................... 6

1.10.1. Hardware tools and costs....................................................................................... 6

Page | iv
 1.10.2. Software tools. ....................................................................................................... 7

1.11. Feasibility Study ........................................................................................................... 7

1.11.1. Economic Feasibility ............................................................................................. 7

1.11.2. Tangible benefits: .................................................................................................. 7

1.11.3. Intangible benefits ................................................................................................. 8

1.11.4. Technical Feasibility ............................................................................................. 8

1.11.5. Operational Feasibility .......................................................................................... 9

1.11.6. Legal Feasibility .................................................................................................... 9

1.11.7. Schedule Feasibility .............................................................................................. 9

1.12. Beneficiaries of the Project........................................................................................... 9

1.13. Project schedule .......................................................................................................... 10

1.14. Project Organization ................................................................................................... 11

1.15. Team Organization ..................................................................................................... 12

1.15.1. Team Composition and Management ................................................................. 12

1.15.2. Communication Plan ........................................................................................... 13

1.16. Budget of the Project .................................................................................................. 13

1.16.1. Hardware Cost ..................................................................................................... 13

1.16.2. Software Cost ...................................................................................................... 14

CHAPTER TWO .......................................................................................................................... 15

EXISTING SYSTEM ................................................................................................................... 15

2.1. Description of Existing System ...................................................................................... 15

2.1.1. Drawback of the Existing System. .......................................................................... 15

2.1.2. Major Function of the Existing System .................................................................. 16

2.1.3. The Main Players of the Existing System ............................................................... 17

2.1.4. Report Generation in Existing System .................................................................... 17

Page | v
 2.1.5. Work Flow of Existing System ............................................................................... 18

2.1.6. Form and Documentation Used in Existing System ............................................... 19

2.1.7. Use Case Diagram for Existing System .................................................................. 20

2.1.8. Business Rules of the Existing System ................................................................... 21

CHAPTER THREE ...................................................................................................................... 22

3.1. Overview of the Proposed System ................................................................................. 22

3.1.1. Characteristics of the New System ......................................................................... 22

3.2. Requirement Analysis of the New System ..................................................................... 23

3.2.1. Functional requirements.......................................................................................... 23

3.2.2. Non-Functional requirements ................................................................................. 23

3.3. Hardware and Software Requirements ........................................................................... 24

3.3.1. Software Requirements. .......................................................................................... 24

3.1.1. Hardware Requirements.......................................................................................... 25

3.2. Actors and Use Case ...................................................................................................... 26

3.2.1. Identifying Actors ................................................................................................... 26

3.2.2. Use-case Identification............................................................................................ 26

3.3. Business Rule ................................................................................................................. 27

3.4. Assumption..................................................................................................................... 27

3.5. Access Control and Security .......................................................................................... 28

CHAPTER FOUR ......................................................................................................................... 29

4.1. System Modeling using Object Oriented Paradigm ....................................................... 29

4.2. Use Case Diagram for Proposed System........................................................................ 30

4.2.1. Use Case Description .............................................................................................. 31

4.3. System Class Diagram ................................................................................................... 38

4.4. Dynamic Modeling ......................................................................................................... 39

Page | vi
 4.4.1. Sequence Diagram .................................................................................................. 39

4.4.2. Activity Diagram .................................................................................................... 49

4.4.3. Component Diagram ............................................................................................... 54

4.4.4. Collaboration Diagram............................................................................................ 56

4.4.5. State Chart Diagram ................................................................................................ 64

4.4.6. Deployment Diagram .............................................................................................. 69

CHAPTER FIVE .......................................................................................................................... 71

5.1. Implementation and Testing .............................................................................................. 71

5.1.1. Implementation ........................................................................................................... 71

5.1.2. Algorithm Design ....................................................................................................... 72

Login Algorithm Design ........................................................................................................... 73

5.2. Final Testing of the system ............................................................................................ 75

5.2.1. Unit Testing ............................................................................................................ 75

5.2.2. Integration Testing .................................................................................................. 77

5.2.3. Functional Testing .................................................................................................. 78

5.3. Module Description and User Manual Preparation ........................................................ 80

5.4. Training and Installation ................................................................................................ 81

5.4.1. Training ................................................................................................................... 81

5.4.2. Installation Process ................................................................................................. 82

5.5. User interface and Sample code ..................................................................................... 83

5.5.1. User Interfaces ........................................................................................................ 83

5.5.2. Sample Code ........................................................................................................... 89

CHAPTER SIX ............................................................................................................................. 91

6. Conclusions and Recommendation ....................................................................................... 91

6.1. Conclusions .................................................................................................................... 91

Page | vii
 6.2. Recommendation ............................................................................................................ 92

References ..................................................................................................................................... 93

Page | viii
 Acronyms
Business Rule:…………………………………………………………………….. (BR)

Cascading Style Sheets: ……………………………………………………………(CSS)

Cross-Platform Apache MySQL PHP Perl: ………………………………………(XAMPP)

Cross-platform apache MariaDB PHP Perl:………………………………………. Xampp

Graphical User Interfaces: …………………………………………………………(GUI),

HyperText MarkUp Language:………………………………………………… . (HTML)

Hypertext Preprocessor: ………………………………………………………….…Php

Mattu University: ………………………………………………………………….(MaU)

Mattu university Online Dormitory Management System: ……………………….(MaUODMS)

My Structured Query Language……………………………………………………(MySQL)

Object-Oriented: …………………………………………………………………....(OO)

Object-Oriented Analysis and Design:……………………………………………..(OOAD)

Operating System…………………………………………………………………...OS

Unified Modeling Language:……………………………………………………... (UML)

ix | P a g e
 List of Tables
Table 1:Hardware tools and their costs ........................................................................................... 6
Table 2:Software tools .................................................................................................................... 7
Table 3:Project Schedule .............................................................................................................. 10
Table 4:Project Organization .................................................................................................... 11
Table 5:Team composition and management ............................................................................... 12
Table 6:Communication Plan ....................................................................................................... 13
Table 7:Hardware cost .................................................................................................................. 13
Table 8:Software cost ................................................................................................................. 14
Table 9: Software Requirements ................................................................................................... 24
Table 10:Hardware Requirements ............................................................................................ 25
Table 11:Technologies Used ....................................................................................................... 71

xii | P a g e
 List of Figures
Figure 1:Waterfall model of SDLC ................................................................................................ 6
Figure 2:Schedule ........................................................................................................................... 9
Figure 3:Student dormitory allocation form ................................................................................. 19
Figure 4:Use Case Diagram for Existing System ..................................................................... 20
Figure 5:Use Case Diagram for Proposed System .................................................................. 30
Figure 6:System Class Diagram ................................................................................................ 38
Figure 7:Sequence Diagram For Login..................................................................................... 40
Figure 8:Sequence diagram for View DormInfo...................................................................... 41
Figure 9:Sequence diagram for Register block ........................................................................ 42
Figure 10:Sequence diagram for Create account .................................................................... 43
Figure 11:Sequence diagram for Remove account .................................................................. 44
Figure 12:Sequence diagram for Search Record ..................................................................... 45
Figure 13:Sequence diagram for Update Record .................................................................... 46
Figure 14:10 Sequence diagram for View student information.............................................. 47
Figure 15:Sequence diagram for Generate Report.................................................................. 48
Figure 16:Activity diagram for Login ....................................................................................... 49
Figure 17:Activity diagram for View DormInfo ...................................................................... 50
Figure 18:Activity diagram for Search Record........................................................................ 51
Figure 19:Activity diagram for Update Record ....................................................................... 52
Figure 20:Activity diagram for Generate Report .................................................................... 53
Figure 21:Component Diagram ................................................................................................. 55
Figure 22:Collaboration diagram for login .............................................................................. 56
Figure 23:Collaboration diagram for register block ............................................................... 57
Figure 24:Collaboration diagram for View DormInfo ............................................................ 58
Figure 25:Collaboration diagram for Create Account ............................................................ 59
Figure 26:Collaboration diagram for Remove Account.......................................................... 60
Figure 27:Collaboration diagram for Search Record ............................................................. 61
Figure 28:Collaboration diagram for Update Record ............................................................. 62
Figure 29:Collaboration diagram for Generate Report .......................................................... 63
Figure 30:state chart diagram for login .................................................................................... 64

xiii | P a g e
Figure 31:state chart diagram for View dormInfo .................................................................. 65
Figure 32:state chart diagram for Register Block ................................................................... 66
Figure 33:state chart diagram for Generate report................................................................. 67
Figure 34:state chart diagram for submit comment ................................................................ 68
Figure 35:Deployment Diagram ................................................................................................ 70
Figure 36:Home Dashboard .......................................................................................................... 83
Figure 37:Login Dashboard .......................................................................................................... 84
Figure 38:Dashboard to view Dormitory information .................................................................. 85
Figure 39:Admin Dashboard......................................................................................................... 86
Figure 40:Proctor Dashboard ........................................................................................................ 87
Figure 41:Proctor manager Dashboard ......................................................................................... 88

xiv | P a g e
 CHAPTER ONE

1.1. Introduction
Technology is spreading its wing in almost every walks of human life activities. Now a day it is
better if every activity is done using new technology in order to fulfill the need of human being,
Organization, Enterprise etc. As today’s world there are many organizations and each
organization need to be preferable, computable and work on fastest way in order to satisfy users
interest etc. i.e. they should have facilitated their activities in computerized way.

Many developing countries are in a good position to exploit the opportunity of technology
revolution and advance human development. The information and communication technology
provide new resource materials for expanding communication.

In fact the second half of 20th century has wittiness the global phenomena of an information
explosion. The development in communication technology has made it possible for millions of
people to have fast access to vast information presented in several forms.

Today computer and other electronic device increasingly communicate and interact directly with
other devices over a variety of network such as internet. The internet provides individuals and
small business centers for the ability to communicate inexpensively. [1]

Hence, developing the system using technology has a tremendous effect for organizations and
offices, which is in our case the Mattu University Online dormitory management system
(MaUODMS). Currently, the system is manual based; due to this the students and proctors faces
some problems Because of this, we are initiating to develop our project on dormitory system in
order to minimize the problem by using computerized system.

1.2. Background of the Organization

Mattu University (MaU) is third generation public university in Ethiopia, which was established
in 2011 GC in the ever-green vicinity endowed with untapped natural resources based on the
Regulation of House of Ministers No. 238/2011 to meet the demand of the country’s fast-
growing needs for high level of professionals. If one browses a Google Map, he/she can spot that

1|Page
MaU is located in southwestern part of Ethiopia, Oromia Regional State. It is situated in Mattu
town which is 600kms away from the capital, Addis Ababa. MaU which is a boarding university
in its very nature and its main campus lands over 350 hectares of land by fulfilling optimal
facilities and infrastructure required to enhance its multifaceted undertakings. Since the
establishment, the university made remarkable and multifarious progress in training, research
and community service provision and increasing the number of qualified manpower by training
at undergraduate and post graduate level

To give vivid historical account of its initial admission capacity, MaU has started its career by
enrolling 300 undergraduate regular students in 2011. In a very radical manner, by now, its
admission capacity has reached over 22,000. When comes to its program profile, the University
is currently running 56 undergraduate and 42 graduate programs through diversified modalities
in two campuses. These academic programs are run under eight colleges and three schools
namely: College of Engineering and Technology, College of Natural and Computational
Sciences, College of Public Health and Medical Sciences, Social Science and Humanities,
College of Business and Economics, College of Education and Behavioral Sciences, College of
Agriculture, College of Natural Resource Management and School of Law, School of Commerce
and School of Agriculture. Parallel with teaching-leaning, the university has been conducting
researches targeting to solve societal problems based on already identified thematic areas

In the University there are different management activities were performed. Among those the
main service which provides the university to the student is Students’ Dormitory Management
can be taken as an example. In this process there is a problem associated with the Dormitory
Management. So we the project team members were initiated for this project to identify and
analyze those problems and to put possible solutions [2]

1.3. Statement of the Problem

Currently, MaU dormitory management system uses manual approach. To process the operation
first the ministry of education sends all the information to the registrar bureau and gives to the
student affairs (dormitory) and to the dinning office. After taking the list, they assigned students
to each block and room. At that time they face different problems during operating their tasks.
Working by paper based i.e. manual system is not only affecting the management members,

2|Page
rather it also for student during viewing of their dormitory information. Some of those problems
are:-

❖ Data duplication and Time consuming.

❖ Require more human power to assign the students.
❖ Management inflexibility

1.4. Objectives of the Project

1.4.1. General objective of the project

The main objective of this project is to develop a new Web Based Dormitory Management
System which solves the above-mentioned problems with the existing system

1.4.2. Specific objective of the project

In order to achieve the main objective, we have the following specific objectives:

❖ Developing user friendly interface.

❖ To keep the overall records associated with the dormitory and student information in a
permanent database.
❖ To assign the dorm to the students without any fault.
❖ To enable students to view their dormitory information using their ID
❖ To enable students for commenting problem may occurred around their dorm
❖ To enable Admin to create new user account
❖ To enable Protector assign dorm and student
❖ To enable proctor manager to assign block

1.5. Scope of the Project

Since MaU dormitory management performs its basic tasks manually the scope of this project is
to develop and implement a new web based Dormitory Management system which will avoid the
problems associated with the manual processing. The proposed system includes: Assign the
dorm accordingly, enable students view their dormitory information easily and quickly, generate
report and Manage dormitory related information

3|Page
 1.6. Limitation of the Project
Since the project is web based, the php version must be up to date unless the system is
vulnerable.
The system is English based only.
Since the system has no sensor is not suitable for those who their eye is affected Limitation
of the Project

1.7. Significance of the Project

The new online dormitory management and allocation system is highly reliable, easy, fast and
consistent and will play a crucial role for reliable service for students, proctors, and for the
management. The significance of the system includes:
❖ To minimize time and efforts needed to perform tasks.
❖ To make tasks simple and efficient in every aspect.
❖ To manage the students and building information.
❖ Providing a well-organized and guaranteed record keeping system with minimum space and
effort need.
❖ To enable the university to get acceptance in the outside community.
❖ Developing students’ effective communication with the university.

1.8. Methodology

1.8.1. Requirement Elicitation Methods

Requirement elicitation is a crucial step in developing a web-based dormitory management
system for Mattu University. It helps gather clear, complete, and well-structured requirements
from stakeholders. Below are common requirement elicitation methods that can be applied:

1.8.2. Interview
to get the basic information and background information about the existing management system,
the team members has interviewed the proctors and some students about the services that are
given to them, and the problems associated with that environment.

4|Page
1.8.3. Observation
even though interview is very important to gather information, direct observation is simple and
we project team members physically observe information that cannot maintain from the
interview or others and also it is important if they are unable to communicate with others because
of the difficulties they have to the language

1.8.4. Document Analysis

To get more information about the project we use earlier documents that help us to develop the
project. During the analysis of documents, we give a special consideration to those documents
which can bring more features to the project.

1.8.5. Methodology for Analysis and Modeling

Here for the analysis of our project we have selected object-oriented system analysis and design
method specifically UML (Unified Modeling Language) model. We have selected this because
of the following advantages: -
❖ To simplify the design and implementation of complex program.
❖ To make it easier for teams of designers and programmers to work in a single software
project.
❖ To enable a high degree of reusability of designs and of software codes.
❖ To decrease the cost of software maintenance.
❖ Increase reusability.
❖ Reduce maintenance burden.
❖ Increased consistency among analysis, design and programming activities.
❖ Improved communication among users, analysis, design and programming.

1.9. System Implementation Method

For implementation technique we the team selected Waterfall Model because of the following
advantages:

❖ Process visibility: well known by non-software parties making it easier to communicate.

❖ Dependence on individuals: good model to use when requirements are well understood
and are quite stable
❖ Easy for Quality and cost control

5|Page
 Figure 1:Waterfall model of SDLC

1.10. Development and Programming Environment Requirements.

While developing the project starts from the documentation to the implementation we use the
following case tools:

1.10.1. Hardware tools and costs

Table 1:Hardware tools and their costs

No Material Amount Price per unit Total price

1 A4 size paper 1 Destin 500 Birr 500Birr
2 Pen 1 30 Birr 30Birr
3 Flash disk 1 32GB 600 Birr 600Birr
4. For Print 100 sheet 4Birr 400Birr
5 CD 1 15 Birr 15Birr
6 Dell computer 1 0 Birr 0 Birr
Total 1815

6|Page
1.10.2. Software tools.
Table 2:Software tools

No Material Price per unit

1 Microsoft office 2007 Free
2 Microsoft office 2010 Free
3 Rational rose Free
4 Apache Xamp server Free
5 Notepad, Notepad++ Free
Total 00.00 Birr

1.11. Feasibility Study

Feasibility study is essential to evaluate the cost and benefits of the new system. On the basis of
the feasibility study decision is taken on whether to proceed or to cancel the project.
Need of the feasibility study:
❖ It determines the potential of the existing system.
❖ It used to determine/finds out the problem of the existing system.
❖ To determine all goals of the new system.
❖ It finds all possible solutions of the problems of the existing system.

1.11.1. Economic Feasibility

The system to be developed is economically feasible and the benefit is outweighing the cost.
Since this project already computerizes the existing system, by now the reduction of cost for
materials used in manual operation becomes beneficiary to the organization.
Generally the system that we developed, MaUODMS brought a number of tangible and
intangible benefits.

1.11.2. Tangible benefits:

1. Cost Reduction
2. Error Reduction
3. Increase Speed of activity
The team member calculated the corresponding the tangible benefits with sample monetary:

7|Page
 1. Cost Reduction: - To calculate these following things will be considered.
Total Number of proctors in existing system= 56 male and 39 female total=95
Average Salary of each proctor per month = 6058.00Birr
Total money required for payment per year= 95*6058*12= 6,906,120Birr
Average Number of proctors needed when the new system is deployed= 35
Average salary of each of them per month = 6058.00Birr
Total money required for payment per year= 35*6058*12= 2,544,360Birr
Difference b/n before and after deployment money required for payment
Cost Reduction and Avoidance= 6,906,120Birr - 2,544,360Birr
= 4,361,760.00Birr

2. Increase Speed of activity: - Increased speed calculated as follows

Especially in allocation:-
Average Days required for allocation= 16 days
Average proctor salary per day=201.9birr
Average Days required for allocation in terms of money=95*201.9*16= 306,888Birr
Average days required for the system= 3 day
Average Days required for allocation in terms of money=35*201.9*3= 21,199.5Birr
Difference = 306,888Birr -21,199.5Birr =285,688.5 Birr

1.11.3. Intangible benefits

1. Reduce Resource Consumption
[Link] security
[Link] Management flexibility

1.11.4. Technical Feasibility

The system developed by using technologically system development techniques such as PHP,
Java script, css and Mysql database without any problems and the group members developed the
system project with enough capability. So the system will be technically feasible.

8|Page
 1.11.5. Operational Feasibility
The system developed will provide accurate, active, secured service and decreases labor of
workers and also it is not limited to particular groups or body. And also it is plat form
independent i.e. it run’s in all operating system.

1.11.6. Legal Feasibility

The system developed is not conflict with any government directives, because it gives services
for the people effectively and efficiently, all the stakeholders also can be agree with the system
developed since the system is not conflict with any government. So the government is profitable
and the system is politically feasible.

1.11.7. Schedule Feasibility

For the project we were scheduled as:

Figure 2:Schedule

Since every thing done in its time the system was also feasible in schedule.

1.12. Beneficiaries of the Project

The beneficiaries of the system are:
❖ Students: the students can view their dormitory information easily and timely.

9|Page
 ❖ Proctors and other administrative officials: they can access dormitory and related
information easily.
❖ University: the university gets better audience.

1.13. Project schedule

Table 3:Project Schedule

Activities Time

NOV. NOV - DEC– MAR- APR- JUNE

DEC FEB. APR MAY

Project
Proposal

Requirement Analysis

Design

Implementation &

Coding

Testing

project Defense

10 | P a g e
 1.14. Project Organization
Table 4:Project Organization

Role Required Skill Name/Position of Name/Position of

First Choice Alternate Choice
Proposal & Knowledge about Daniel Getachew
Documentation existing works and
Flow Chart
Requirement Connection to Gaddisa Chimdesa
Gathering Dormitory office,
Communication
skills, Statics analysis
System Analysis Analyzing Skills Fayine Tibebu
System Design Object oriented Katama Galeta
system design
System Proficient in web Daniel Getachew
Implementation development and
coding skill in
HTML, CSS,
JavaScript, php and
XAMPP
Testing Software project Kalab Worku
management

11 | P a g e
 1.15. Team Organization

1.15.1. Team Composition and Management

Table 5:Team composition and management

Mattu university Online Dormitory Management System

S/No Name ID NO. Email Address Responsibilities

1 dangech0922@[Link] -V/group Coordinator

Daniel Getachew Ru0779/14 -Implementation

-Documentation

Gadisa Chimdesa Ru1165/14 gadisachimdesa463@[Link] Requirement

Gathering
2

Ru1514/14

3 Kaleab Worku kaleab200217@[Link] Testing

4 Katama Galata Ru1574/14 katama123@[Link] System Design

Ru1111/14 fayinet1995@[Link]

5 Fayine Tibabu System Analysis

Project Advisor: Instructor Tesfaye A ([Link])

12 | P a g e
 1.15.2. Communication Plan
Table 6:Communication Plan

Stakeholder Communication Frequency Responsibility

Method
Project Team Daily Standup Daily Project Manager
Meetings
Dormitory Admins Face to face, phone As needed Gather Information
Advisor Face to face, 3 days per week Advisor
Telegram

1.16. Budget of the Project

1.16.1. Hardware Cost

Table 7:Hardware cost

No Material Amount Price per unit Total

price
1 A4 size paper 1 Destin 500 Birr 500Birr
2 Pen 5 30 Birr 150Birr
3 Flash disk(32GB) 2 600 Birr 1200Birr
4. For Print ≈100 sheet 3 Birr 300Birr
5 Ruler 1 15 Birr 15 Birr
6 Dell computer 1 free 0Birr
Total 2167

13 | P a g e
 1.16.2. Software Cost
Table 8:Software cost
No Material Price per unit
1 Microsoft office 2019 Free
2 Microsoft office 2016 Free
3 Rational rose Free
4 Apache Xamp server Free
5 Notepad, Notepad++, VS Free
6 Window OS free

14 | P a g e
 CHAPTER TWO

EXISTING SYSTEM

2.1. Description of Existing System

The current system of MaU dormitory management system is manual (partial). In order to
arrange and allocate students to dorms, they have to follow the record as it is arranged by MaU
Registrar office and allocate Students depending on department/colleges and the lists of the
students’ arrangement. After getting the list from the registrar office, the proctor allocates the
students to each block and dorm. Since there are so many students, the allocation method causes
problems like assigning female students to males’ dorm and vice versa and also assigning
students more than the capacity of the dorm. In addition to these problems, during assignation
there is no consideration of disable students.

2.1.1. Drawback of the Existing System.

The manual (partial) dormitory management system is disposed to various problems. These
problems can be seen from the following perspectives like performance, information, economic,
control, efficiency and services given by the existing system to the users.

The performance of any system is required to show to meet the needs of users of that system.
The current system’s performance is weak. This is due to the following reasons: - first the
acceptable quantity rate is relatively high i.e. the time required from initiation to completion of a
particular task is relatively high. For example during arrangement of buildings for the allocation
it may take a week or more due to its manual operation. Second is the acceptable response time
for a particular task is large.

Information- the main input for the current system is student record and records of different
dormitory materials which enable the system to rearrange students and buildings for the
allocation. Based on this the system rearranges and allocates dorms for students at the beginning
each academic year and generates the allocation report which may be viewed by the students as
well as the management. The other data that is stored is record of materials associated with the

15 | P a g e
dormitory. The system manipulates and manages all of these and other records manually on
papers.

Controlling- since all the records associated with the manual system are recorded and stored
manually the security that the system provide for the privacy of this records is not good. The
system shouldn’t provide sufficient protection for access and manipulation of the records
associated with the system.

Services- the main users of the current system are students and the management itself. The
services given to users are not flexible, reliable and expandable i.e. the users must there in the
campus to get the services given by the system. Those services given by the system are limited to
a particular area.

2.1.2. Major Function of the Existing System

Even if the existing system is performs its activities manually (partial), it has different major
functions.

Arranging buildings for the allocation: here the total number of building is determined with its
holding capacity

Arranging students for allocation: here total number of students and their academic
information such as department, sex, faculty, and class year is received from registrar. Students
are then arranged based on their sex, class year, and their department and faculty for dormitory
allocation.

Dormitory allocation: based on the arrangement of students dorms are allocated for students
along with associated dormitory resources, like lockers, tables, chairs, beds and the like.

Generating allocation report: based the dormitory allocation the allocation report is prepared
and posted for student when they arrive at the campus after annual break.

Managing and controlling dormitory materials: at the beginning and end of each year,
dormitory materials are recorded and controlled whether they are functioning properly or not,
then appropriate measure is taken.

16 | P a g e
Controlling student’s discipline: In addition to the above functionalities student’s discipline
measures are controlled and recorded, whether they use the dormitory materials properly or not,
and whether they act and perform things as per the dormitory rules and regulations.

2.1.3. The Main Players of the Existing System

An existing system compromises different players to carry out its job. Among those different
actors (players), the most common are Proctor manager, this body provides the list of all
students who fulfilled every requirement for allocation to proctors, Students, they will be placed
in their dorm by proctors and assigned for the property they get from the proctor, Proctors, They
involved strongly in the existing system. Proctors collect students list from registrar. After they
get all these information’s from this body they will place those students according to their sex,
class year, department and faculty.

The major actors in the existing system are:

❖ Students
❖ Proctors and
❖ Proctor manager

2.1.4. Report Generation in Existing System

In an existing system there are different reports generated for different purposes. Those reports
include Student Dormitory allocation report, Student status report; Resource received
report, and clearance report in addition to conditional report such as discipline case report,
damaged resource report, and etc.

The dormitory allocation report contains the report related to student’s block number and
dorm number. Resource received report includes reports of materials that a student has taken
from a Proctor when he/she first assigned in to that dorm. The student status report is any
report that contains any up-to-date information about a student. Discipline measurement report
embraces reports such as does a student contains any discipline record in this campus and what
type of discipline measure were taken will be generated in the report. Clearance report is a
report which is generated when any student wants to leave a campus because of different
reasons. When he/she leave a campus the above reports will be checked by the proctor
collectively.

17 | P a g e
Those all reports were checked to clarify a student whether he/she returned all resources that
he/she used, is he/she free of discipline measures? After checking those reports a proctor will
clear the student that ensures that the student is free of any resources while he/she was in dorm.

2.1.5. Work Flow of Existing System

The proposed system operates in the following manner. Normally the student information is
taken from the registrar bureau. The registrar bureau have centralized database. Then the student
dormitory officers can access that database. After getting all the required information the system
will feed into our back end database based on their year (batch), department, faculty and sex.
After doing this the system will generate the allocation report which contains dormitory
information like student’s name, id number, dorm number, and block number. This report will be
released online for the student so that they can access this information by entering his/her
identification number or registration number on the webpage provided by the system just by
sitting where ever they are.

18 | P a g e
 2.1.6. Form and Documentation Used in Existing System
In the existing system, they use different forms and reports to manipulate different records
associated with the different activities. Among them Dormitory allocation form is one of the
main paper document used in the existing system. The form is look like this:

Figure 3:Student dormitory allocation form

19 | P a g e
2.1.7. Use Case Diagram for Existing System
Figure 4:Use Case Diagram for Existing System

20 | P a g e
 2.1.8. Business Rules of the Existing System
A business rule is effectively an operating principle or polices that must be fulfilled and
obligated in order the system will function properly and effectively. It often pertain to access
control issues, business calculations, or operating polices and principles of the organization [3]

BR1: Only one dorm is assigned for six students, and those students should live in the dorm
which belongs to him/her.
BR2: Students should not change their dorm without the permission of the proctor with
sufficient reason.
BR3: Students are allocated in such a way that male students are not allocated with female
students.
BR4: Proctors should not assign one student in more than one dorm.
BR5: Proctors should not use student’s personal information for other purposes.
BR6: Buildings should be arranged before the allocation.
BR7: After the allocation reports should be prepared by proctors for students’ i.e. for posting.
BR7: Freshman students allocated to their dorm based on their stream(natural/social) while
seniors allocated based on their faculty or Department.

21 | P a g e
 CHAPTER THREE

3.1. Overview of the Proposed System

The proposed system is designed to streamline and enhance the administration and usage of
dormitory facilities. It addresses the challenges faced by students and proctors and proctor
managers by providing an integrated platform that manages all aspects of dormitory life.

In the proposed system Students are registered in the block and room based on their faculty by
proctor, and the students can submit a comment for Administrator, proctor and proctor manager
to get any service related with dormitory. In the proposed system Admin creates a user for
proctor, proctor manager or other administrator. The proctor manager Assign block and allocate
proctor for the assigned blocks.

3.1.1. Characteristics of the New System

The proposed Mattu University Dormitory system will have several key characteristics that
provide an overview of its capabilities and functionalities. It will utilize a centralized database to
store and manage all Student, Proctor, Proctor Manager and Administrators data in a secure and
organized manner. The system incorporates Web based Dormitory systems modules that are
integrated within a single digital platform. It aims to computerize important Dormitory
workflows between Proctor, Proctor Manager and Students as well as automate common
administrative functions. The Mattu University Dormitory system is designed to be user-friendly,
offers role-based access controls and security measures to ensure data privacy and integrity in
compliance with relevant regulations.

22 | P a g e
3.2. Requirement Analysis of the New System

3.2.1. Functional requirements

The following are the functional requirements of the new system.
❖ The system accepts (read) the uploaded record.
✓ The system should arrange the buildings for the allocation.
✓ The system should arrange students for the allocation.
✓ The system should assign dorms for students.
❖ The system should generate timely report about the allocation.
❖ The system should store all the data related with all the tasks performed into a
database.

3.2.2. Non-Functional requirements

❖ User Interface
This works as an interface between the user and the system by properly guiding the user how to
use it and perform operations. Proctors can change the data in the DBUODMS based on their
privilege, whereas, students can only view their dorm information and they can give comment.
Any sort of training is not required for using the system. It is important that the system is easy to
learn. The input device is given to keyboard and the output is viewed on the monitor.

❖ Quality Issue
Information in database should be as much as possible correct and updated in each semester.

❖ Security Issue
This system provides an access to an authorized user by giving account for each and every
special function. Students can view their dorm information by using their identification card
number and/or registration number, and give comment without any validation.

❖ Error Handling
Our system handles the errors in a very efficient manner. It can tolerate to wrong inputs and
prompts the users to correct the inputs. It gives notifications as and when required, guiding the
users to properly utilize it.

23 | P a g e
❖ Performance characteristic
Performance requirements are concerned with quantifiable attributes of the system such as
System should quickly respond for user request that is system must immediately display the
needed service along with their allocation details after he/she insert needed information to view.

3.3. Hardware and Software Requirements

3.3.1. Software Requirements.

Table 9: Software Requirements

No Material

1 Microsoft office 2007

2 Microsoft office 2010

3 Rational rose

4 Apache Xampp server

5 Notepad, Notepad++

24 | P a g e
 3.1.1. Hardware Requirements
Table 10:Hardware Requirements

No Material Amount

1 A4 size paper 1 Destin

2 Pen 1

3 Flash disk 1

4. For Print 100 sheets

5 CD 1

6 Dell computer 1

25 | P a g e
3.2. Actors and Use Case

3.2.1. Identifying Actors

In the use cases an actor interacts with the system to perform a piece of meaningful work that
helps them to achieve a goal and has access to define their overall role in the system and the
scope of their action. Depending on the above explanation actors in this system are the
following:

❖ Student: The students view his/ her dormitory information online and submit comment.
❖ Proctor: The proctor can assign student and generate report.
❖ Proctor manager: search, generate report and change password.
❖ Administrator: The administrator manages the overall system.

3.2.2. Use-case Identification

Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case's functionality or extend another Use Case with its own behavior. The most
important and basic use cases of this system are the following:-

❖ Login
❖ Allocate Student
❖ Create account
❖ View dorm
❖ View Rules/Info
❖ Submit comment
❖ View comment
❖ Register block (Allocate Proctor)
❖ Register room
❖ View StudentInfo
❖ Generate report

26 | P a g e
3.3. Business Rule
❖ Eligibility: Only currently enrolled students of Mattu University are eligible to apply for
dormitory accommodation.
❖ Profile Completion: Students must complete their profiles with accurate personal
information before applying for a room.
❖ Actor must use correct their username and password
❖ At the time of student registration if proctor want to upload a file , then the file must be
csv format ex. [Link]
❖ The students must use Id to know their dormitory information

3.4. Assumption
The development and implementation of the proposed Mattu University Dormitory System is
based on the following assumptions:

Availability of Skilled Resources: It is assumed that the project will have access to skilled and
experienced personnel, including, database administrators, and Dormitory domain experts, to
ensure successful development and implementation of the system.

Stakeholder Cooperation and Support: It is assumed that all stakeholders, including

Dormitory administration, Proctors, and support staff, will actively cooperate and support the
project by providing relevant information, participating in requirements gathering, and
embracing the new system.

Adequate Infrastructure: It is assumed that the Dormitory will provide the necessary hardware
infrastructure, such as servers, client computers, and network infrastructure, to support the
deployment and operation of the proposed system.

Budget Availability: It is assumed that sufficient financial resources will be allocated for the
development, implementation, and ongoing maintenance of the Mattu University system.

Interoperability with External Systems: It is assumed that the proposed system will have the
capability to integrate with external systems, such as electronic medical record (EMR) systems,
insurance providers, or referral networks, if required in the future.

27 | P a g e
User Training and Adoption: It is assumed that adequate user training and change management
initiatives will be implemented to ensure successful adoption of the new system by
administrative staff, and other users.

Scalability and Extensibility: It is assumed that the proposed system will be designed with
scalability and extensibility in mind, allowing for future growth and the addition of new
functionalities or modules as needed.

Vendor Support and Maintenance: It is assumed that the software vendors or service providers
involved in the development and implementation of the system will provide ongoing support,
updates, and maintenance services as required.

3.5. Access Control and Security

The system implements role-based access control to restrict system features and data access
based on user roles like Proctor, Students, etc. User authentication using valid credentials is
enforced, ensuring unauthorized access is prevented. Strong password encryption is important.
The system uses MD5 algorithm. MD5 produces a 128-bit hash value from input data of any
size, which is commonly used for message integrity verification, user passwords storage etc. It
works by compressing input into an irreversible signature. For passwords, the hashed value is
stored instead of plaintext. During login, entered password is hashed and matched with stored
hash to verify without revealing the actual password. This provides security without revealing
sensitive information. Audit logs and activity monitoring are also proposed for compliance.

28 | P a g e
 CHAPTER FOUR

4.1. System Modeling using Object Oriented Paradigm

The proposed Mattu University Dormitory System will be designed and modeled using the
Object-Oriented (OO) paradigm, which offers several advantages, including:

Modularity: The system can be divided into modular components (objects) that encapsulate data
and behavior, promoting code reusability and maintainability.

Abstraction: The OO approach allows for the creation of abstract representations of real-world
entities, making the system easier to understand and modify.

Inheritance: Objects can inherit properties and behaviors from parent classes, promoting code
reuse and facilitating the creation of new classes based on existing ones.

Encapsulation: Data and methods are combined into objects, ensuring data integrity and hiding
implementation details from other components of the system.

Polymorphism: Objects of different classes can be treated as objects of a common superclass,

allowing for flexibility and extensibility in the system design.

The Object-Oriented Analysis and Design (OOAD) approach will be employed in the system
modeling process, which involves the following steps:

Identifying Classes and Objects: Real-world entities, such as Proctors, Proctor Managers, and
Students, will be modeled as classes and objects.

Defining Relationships: Relationships between classes established

Assigning Responsibilities: Responsibilities and behaviors will be assigned to classes based on

their roles and requirements in the system

Designing Class Hierarchies: Class hierarchies designed to promote code reuse and facilitate
the addition of new features or modifications in the future.

Modeling Interactions: Sequence diagrams, activity diagrams, and state diagrams will be used
to model the interactions and workflows between objects in the system.

Designing User Interfaces: Graphical User Interfaces (GUIs) will be designed to facilitate user
interactions with the system, Taking into account usability principles and user experience.

29 | P a g e
4.2. Use Case Diagram for Proposed System
Figure 5:Use Case Diagram for Proposed System

30 | P a g e
 4.2.1. Use Case Description
Use case name: Login
Use case Id: UC01
Description: To authenticate the user
Actor: Administrator, proctor manager, proctor and student.
Precondition: The user must be registered on the system
Flow of action:
Actor action
Step1: User wants to login
Step2: Select the login link
Step4: Fill user name and password
System response
Step3: The system displays the login form
Step5: Validate user name and password.
Step6: The system displays the appropriate page.
Step7: Use case ends.
Alternative course of action (If the username and password or student identification number is
incorrect)
The system displays incorrect user name and password message.
❖ The system redirects to go step 4 [Link] enter the username and password
❖ Use case ends.
Post condition: The authenticated person gets the appropriate page.
Use Case Name: Create Account
Use case Id: UC02
Description: Administrator assigns privilege to the proctors and proctor manager.
Actors: Administrator
Precondition: The Administrator must log in to the system.
Flow of action:
Actor Action:
Step1: The administrator log to his/her page.
Step2: The administrator click on User Account link.

31 | P a g e
 Step4: The administrator click create account link.
Step6: The administrator fills the form and submits it.
System Response:
Step3: The system displays the option as create account and remove account.
Step5: The system displays the registration form.
Step5: The system displays succeed information as the account is created.
Step6: Use case ends.
Alternative course of action: (if the account is already exist)
❖ The system display error message that user is already exist.
❖ The system redirects to go to step 6.
❖ Use case ends.
Post condition: the account will be created.
Use Case Name: Submit Comment
Use case Id: UC03
Description: User can give comment.
Actors: Student, proctor.
Precondition: The Student and proctor must have valid Email address.
Flow of event:
Actor action:
Step1: The user initiates to give comment.
Step2: The user click on the comment link.
Step4: The user fills all the required fields.
System response:
Step3: The system displays the form.
Step5: The system validates the entered information.
Step6: The system display as your comments has been sent
Step7: Use case ends.
Alternative course of action: (if user fills wrong/incorrect information)
❖ The system display error message and give a chance to retype.
❖ Go to step 5
❖ Use case ends.

32 | P a g e
Post condition: The user sends comment to the system.
Use Case Name: View DormInfo
Use case Id: UC04
Description: The user can view his/her dormitory information.
Actors: Student.
Precondition: The Student must have valid Identification number.
Flow of action:
Actor action:
Step1: The student wants to see his/her dorm.
Step2: The student click on view dorm link.
Step4: the student fills his/her identification number.
System response
Step3: the system displays the login form.
Step5: the system validates the entered data.
Step6: the system displays the dormitory information.
Step7: Use case ends.
Alternative course of action: (if student identification number is not existing)
❖ The system display error messages that student identification is not exist.
❖ Go to step 4
Post condition: The system displays the detailed information.
Use Case Name: view Comment
Use case Id: UC05
Description: Proctor manager can see the comments that are submitted from the user (student,
proctor).
Actors: Proctor manager.
Precondition: The Proctor manager must have a full privilege to read the comments.
Flow of action:
Actor action:
Step1: Proctor manager log to his/her page.
Step2: Proctor manager click on view comment link.
Step4: Proctor manager starts to view the comments.

33 | P a g e
 System response:
Step3: The system reorders the comments according to the time of delivery
Step5: Use case ends
Post condition: The proctor manager views the submitted comments.
Use Case Name: Manage Record
Use case Id: UC06
Description: The Administrator can manage records.
Actors: Administrator.
Precondition: The administrator must log to his/her page.
Flow of action:
Actor action:
Step1: The administrator log to his/her page.
Step2: The administrator clicks on Manage Record link.
Step4: The administrator selects one at a time from the given options.
Step6: The administrator fills the form and click on buttons.
System response
Step3: The system will give the options like delete, update or search record.
Step5: The system displays the available form.
Step7: The system performs the task.
Step8: Use case ends.
Alternative course of action (The system validate the entered data is not correct)
The system displays incorrect entered data message.
❖ The system redirects to go step 6 [Link] fill the data again.
❖ Use case ends
Post condition: The administrator manages the record.
Use Case Name: Register Block
Use case Id: UC07
Description: The user can register blocks information (including proctors) into the data base

Actor: Proctor manager

Precondition: Proctor manager must have full privilege to do this task.

34 | P a g e
Flow of action:

Actor action:
Step1: The proctor manager log to his/her page.
Step2: The proctor manager selects the register block link.
Step4: The proctor manager fills the required fields.
System response
Step3: The system will display the registration form.
Step5: The system validates the input data.
Step6: The system displays the successful notification.
Step7: Use case ends.
Alternative course of action (the system validate the entered data if it is not correct)
The system displays incorrect entered data message.
❖ The system redirects to go step 4 [Link] fill the data again.
❖ Use case ends
Post condition: The block registered.
Use Case Name: Register Room
Use case Id: UC08
Description: The user can register room information into the data base

Actor: Proctor

Precondition: Proctor must have full privilege to do this task.

Flow of action:
Actor action:
Step1: The proctor log to his/her page.
Step2: The proctor selects the register room link.
Step4: The proctor fills the required fields.
System response
Step3: The system will display the registration form.
Step5: The system validates the input data.
Step6: The system displays the successful notification.

35 | P a g e
 Step7: Use case ends.
Post condition: The room registered.
Alternative course of action (the system validate the entered data is not correct)
The system displays incorrect entered data message.
❖ The system redirects to go step 4 [Link] fill the data again.
❖ Use case ends.
Use Case Name: View StudentInfo
Use case Id: UC09
Description: the user can view the detail information about the dorm as well as the student.
Actors: Proctor manager, proctor.
Precondition: The user must have a full privilege to access the information.
Flow of action:
Actor action
Step1: The user log to his/her page.
Step2: User click on view student Information link.
Step4: User selects and fills the required fields.
System response
Step3: The system displays the form to select and to enter the criteria’s.
Step5: The system displays the detail information about the student.
Step6: Use case end
Alternative course of action: (if input values are incorrect)
❖ The system display error messages that the input values are incorrect.
❖ Go to step 3
❖ Use case end
Post condition: The user gets the information.
Use Case Name: Generate Report
Use case Id: UC010
Description: generate timely report
Actor: proctor manager, proctor
Precondition: The actor must have full privilege.
Flow of action:

36 | P a g e
 Actor action:
Step1: The user must log to his/her page
Step2: The user select generate report link
Step4: The user selects the criteria from the given options and clicks on Display button.
System response:
Step3: the system displays the options (criteria)
Step5: The system displays the information to the user
Step6: Use case ends
Alternative course of action: (the system verify information is not correctly)
❖ The system displays error message as invalid selection
❖ Go to step4
❖ Use case ends
Post condition: the report will be generated.
Use Case Name: Allocate Student
Use case Id: UC011
Description: Assign students in their room.
Actor: Proctor
Precondition: The proctor must have full privilege to the task.
Flow of action:
Actor action:
Step1: The proctor must log to his/her page
Step2: The proctor select Allocate student link
Step4: The proctor selects and fills the required fields and clicks on save button.
System response:
Step3: The system displays the form with the options such as block no, room no.
Step5: The system validates the entered values.
Step6: Use case ends
Post condition: The Student will be assigned.
Alternative course of action: (the system verify information is not correctly)
❖ The system displays error message as invalid value

37 | P a g e
 4.3. System Class Diagram
5. Class diagram is static model that shows the classes and the relationships among classes that
remain constant over the time. Class is the main building block of class diagram, which
stores and manages information in the system. In the phase of conceptual class modeling we
just create or classes ad their interrelationship.
Figure 6:System Class Diagram

38 | P a g e
 4.4. Dynamic Modeling

4.4.1. Sequence Diagram

The sequence diagram is used primarily to show the interactions between objects in the
sequential order that those interactions occur. However, an organization's business staff can find
sequence diagrams useful to communicate how the business currently works by showing how
various business objects interact. Besides documenting an organization's current affairs, a
business-level sequence diagram can be used as a requirements document to communicate
requirements for a future system implementation. During the requirements phase of a project,
analysts can take use cases to the next level by providing a more formal level of refinement.
When that occurs, use cases are often refined into one or more sequence diagrams.

The main purpose of a sequence diagram is to define event sequences that result in some desired
outcome. The focus is less on messages themselves and more on the order in which messages
occur; nevertheless, most sequence diagrams will communicate what messages are sent between
a system's objects as well as the order in which they occur

39 | P a g e
Figure 7:Sequence Diagram For Login

40 | P a g e
Figure 8:Sequence diagram for View DormInfo

41 | P a g e
Figure 9:Sequence diagram for Register block

42 | P a g e
Figure 10:Sequence diagram for Create account

43 | P a g e
Figure 11:Sequence diagram for Remove account

44 | P a g e
Figure 12:Sequence diagram for Search Record

45 | P a g e
Figure 13:Sequence diagram for Update Record

46 | P a g e
Figure 14:10 Sequence diagram for View student information

47 | P a g e
Figure 15:Sequence diagram for Generate Report

48 | P a g e
4.4.2. Activity Diagram
Figure 16:Activity diagram for Login

49 | P a g e
Figure 17:Activity diagram for View DormInfo

50 | P a g e
Figure 18:Activity diagram for Search Record

51 | P a g e
Figure 19:Activity diagram for Update Record

52 | P a g e
Figure 20:Activity diagram for Generate Report

53 | P a g e
 4.4.3. Component Diagram
Component diagram is a special kind of diagram in UML. The purpose is also different from all
other diagrams discussed so far. It does not describe the functionality of the system but it
describes the components used to make those functionalities.

So from that point component diagrams are used to visualize the physical components in a
system. These components are libraries, packages, files etc.

Component diagrams can also be described as a static implementation view of a system. Static
implementation represents the organization of the components at a particular moment.

A single component diagram cannot represent the entire system but a collection of diagrams are
used to represent the whole.

So the purpose of the component diagram can be summarized as:

❖ Visualize the components of a system.

❖ Construct executables by using forward and reverse engineering.

Describe the organization and relationships of the components

54 | P a g e
Figure 21:Component Diagram

55 | P a g e
 4.4.4. Collaboration Diagram
A collaboration diagram describes interactions among objects in terms of sequenced messages.
Collaboration diagrams represent a combination of information taken from class, sequence, and
use case diagrams describing both the static structure and dynamic behavior of a system.

The UML Collaboration diagram is used to model how objects involved in a scenario interact,
with each object instantiating a particular class in the system. Objects are connected by links,
each link representing an instance of an association between the respective classes involved. The
link shows messages sent between the objects, and the type of message passed

Figure 22:Collaboration diagram for login

56 | P a g e
Figure 23:Collaboration diagram for register block

57 | P a g e
Figure 24:Collaboration diagram for View DormInfo

58 | P a g e
Figure 25:Collaboration diagram for Create Account

59 | P a g e
Figure 26:Collaboration diagram for Remove Account

60 | P a g e
Figure 27:Collaboration diagram for Search Record

61 | P a g e
Figure 28:Collaboration diagram for Update Record

62 | P a g e
Figure 29:Collaboration diagram for Generate Report

63 | P a g e
4.4.5. State Chart Diagram
Figure 30:state chart diagram for login

64 | P a g e
Figure 31:state chart diagram for View dormInfo

65 | P a g e
Figure 32:state chart diagram for Register Block

66 | P a g e
Figure 33:state chart diagram for Generate report

67 | P a g e
Figure 34:state chart diagram for submit comment

68 | P a g e
 4.4.6. Deployment Diagram
The name Deployment itself describes the purpose of the diagram. Deployment diagrams are
used for describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related.

Component diagrams are used to describe the components and deployment diagrams shows how
they are deployed in hardware.

UML is mainly designed to focus on software artifacts of a system. But these two diagrams are
special diagrams used to focus on software components and hardware components.

So most of the UML diagrams are used to handle logical components but deployment diagrams
are made to focus on hardware topology of a system. Deployment diagrams are used by the
system engineers.

The purpose of deployment diagrams can be described as:

❖ Visualize hardware topology of a system.

❖ Describe the hardware components used to deploy software components.
❖ Describe runtime processing nodes.

69 | P a g e
Figure 35:Deployment Diagram

70 | P a g e
 CHAPTER FIVE

5.1. Implementation and Testing

5.1.1. Implementation
The implementation phase transforms the design of the system into a fully functional web-based
application. In this stage, all planned modules, interfaces, and database structures are developed
using suitable programming languages, tools, and technologies. This chapter outlines the
technologies used, key implementation components, and system functionalities realized in code.

Technologies Used

Table 11:Technologies Used

Component Technology
Front-end HTML, CSS, JavaScript
Back-end PHP
Database MySQL
Email Service PHPMailer (SMTP - Gmail)
Development Tool Visual Studio Code
Version Control Git and GitHub
Testing Tool Postman

System Architecture

The system follows a three-tier architecture:

Presentation Layer: Interfaces for students, proctors, and managers.

Logic Layer: PHP code handles authentication, validation.
Data Layer: MySQL database for storing user information, room data, and comments.

Major Implementation Modules

Student Module

71 | P a g e
 View Dorm Assignment: Students can see their assigned block and room number.
Comment Submission: Students can submit complaints or feedback to administrators.

Proctor Module

Room and Block Management: View, edit, and assign rooms to students.
Room Number Limiting: Each block is limited to a maximum of rooms. Proctors can
update room numbers dynamically

Proctor Manager Module

Dashboard Overview: view blocks, and room registration summary.

Block Registration:

Manual: Input block name and room number directly.

CSV Upload: Batch registration using CSV files. The system parses, validates, and inserts room
data.

Security Features

Passwords are hashed using strong algorithms (e.g., md5() in PHP).

Session management for user roles and access control.

Administration Module

User Management

Create
Edit
Activate
Deactivate
Delete

5.1.2. Algorithm Design

Algorithm design is the process of defining logical, step-by-step solutions to perform specific
tasks within a system.

72 | P a g e
Login Algorithm Design

Login is a fundamental component that authenticates users and grants access to the system based
on their roles (Student, Proctor, or Proctor Manager).

User Management Algorithm Design

Add New User

Input: user_type, full_name, username/ID, email, password, (if proctor)

1. Validate all required fields

2. Check if the user already exists in the database:

- SELECT * FROM users WHERE username = input_username

3. If user does not exist:

a. Hash password using md5()

b. INSERT new user into the appropriate table:

- If proctor → INSERT INTO users (role = 'proctor')

c. Return success message

4. Else:

- Return error: "User already exists"

Block Registration Algorithm Design

Input: college_name, block_name, number_of_rooms

1. Validate inputs:
a. college_name must not be empty
b. block_name must not be empty
c. number_of_rooms
2. Check if college exists:
- SELECT * FROM colleges WHERE name = college_name

73 | P a g e
 - If not exists:
Return error: "College does not exist"

3. Check if block_name already exists under this college:

- SELECT * FROM blocks WHERE block_name = block_name AND college_name =
college_name
- If exists:
Return error: "Block already registered for this college"
4. Insert new block:
- INSERT INTO blocks (block_name, college_name, total_rooms)
VALUES (block_name, college_name, number_of_rooms)
5. For i = 1 to number_of_rooms:
- INSERT INTO rooms (block_name, college_name, room_no)
VALUES (block_name, college_name, i)
6. Return success: "Block and rooms registered successfully under [college_name]"
Algorithm Design: Allocating Dorm

Input: block_name, number_of_rooms

1. Validate inputs:
a. block_name must not be empty
b. number_of_rooms must be between 1 and 30
2. Check if block exists:
- SELECT * FROM blocks WHERE block_name = input_block_name
- If not found → Return error: "Block not registered"
3. Check if rooms already exist for this block:
- SELECT * FROM rooms WHERE block_name = input_block_name
- If any rows found → Return error: "Rooms already allocated for this block"
4. For i = 1 to number_of_rooms:
- INSERT INTO rooms (block_name, room_no)
VALUES (block_name, i)
5. Return success: "Rooms 1 to N allocated for block [block_name]"

74 | P a g e
Algorithm Design: Assign Student

Input: student_id, block_name, room_no, dorm_name, college_name

1. Validate inputs: all fields must be non-empty
2. Check if student exists in the database:
- SELECT * FROM students WHERE student_id = input_student_id
- If not found → Return: "Student not found"
3. Check if student is already assigned to a room:
- SELECT * FROM assignments WHERE student_id = input_student_id
- If found → Return: "Student already assigned"
4. Check if the room exists and is vacant:
- SELECT * FROM rooms WHERE block_name = input_block_name AND room_no
= input_room_no
- If not found → Return: "Room not found"
- If assigned_student_id is not NULL → Return: "Room already assigned"
5. Assign the student:
a. Update the `rooms` table:
- UPDATE rooms SET assigned_student_id = input_student_id
WHERE block_name = input_block_name AND room_no = input_room_no
b. Optionally insert into `assignments` table:
- INSERT INTO assignments (student_id, block_name, room_no, dorm_name,
college_name)
VALUES (...)
6. Return: "Student assigned successfully to Block X, Room Y, Dorm Z"

5.2. Final Testing of the system

5.2.1. Unit Testing

Unit Testing: Student Registration

Test Objective

The primary objective of testing the student registration functionality is to verify that the system
registers a student correctly, using valid details such as the student’s name, ID, and college
affiliation. It also ensures that the system handles errors when required data is missing.

Test Cases

The first test case is a valid student registration, where the student’s name is John Doe, the
student ID is STU12345, and the college is Computer Science. The expected outcome is that the
system should successfully create a new student record, assigning the student the unique ID

75 | P a g e
STU12345. If the registration is successful, the status should be ‘successes and the student ID
should match the provided ID. The second test case checks for missing student information. In
this case, the student’s name is left empty, and the rest of the information remains valid. The
expected outcome is that the system should return an error message indicating that the student’s
name is required.

Unit Testing: Room Allocation

Test Objective

The goal of testing room allocation is to ensure that the system correctly assigns a student to a
room within a specified block. It should also prevent allocation to rooms that are already
occupied.

Test Cases

The first test case verifies a valid room allocation. Here, a student with the ID STU12345 is
assigned to room 5 in Block A. The expected outcome is that the student should be successfully
assigned to that room, and the system should confirm the allocation by returning the student’s
ID.

The second test case involves trying to allocate a room that is already assigned. In this case,
room 5 in Block A has already been allocated to STU12345, and another student (STU67890)
attempts to be assigned to the same room. The expected outcome is that the system should reject
this allocation and return an error indicating that the room is already assigned.

Unit Testing: Block Registration

Test Objective

The block registration functionality is tested to ensure that blocks are correctly registered within
the system and that no duplicate blocks are allowed. Blocks are assigned to specific colleges, and
it is critical that no two blocks share the same name.

Test Cases

76 | P a g e
The first test case tests the successful registration of a block. The block Block A is registered
under the Computer Science college. The expected outcome is that the system registers the
block correctly and returns the status as ‘success’, associating the block with the specified
college.

The second test case checks for the scenario where a block with the same name already exists.
The system should reject the registration of a duplicate block and return an error message
indicating that the block already exists.

Password Reset via Email

Test Objective

The objective of this unit test is to ensure that the password reset functionality via email works
correctly. This includes verifying that the system sends a password reset email to the registered
user’s email address and handles cases where the email address is invalid or not registered.

Test Cases

In the first test case, a valid email address that exists in the system is used to initiate the
password reset process. The system should generate a unique token, store it in the database
associated with the user, and then send an email to the user. The expected outcome is that the
system confirms the email has been sent successfully.

The second test case checks for invalid email format. If the email provided does not follow the
correct email format (e.g., missing the “@” symbol or domain), the system should validate the
input and return an appropriate error message before attempting any further processing.

5.2.2. Integration Testing

Student Registration Integrated with Dorm Allocation

In this test scenario, a student is first registered through the student registration module. After
successful registration, the system immediately proceeds to assign the student to a room in a
specific block and dorm. Integration testing confirms that the data from the registration process
(student ID, name, and college) is correctly passed and utilized by the dorm allocation module.

77 | P a g e
The expected outcome is that the student details are successfully linked to a room, with correct
references in both the student and dorm tables.

Block Registration Integrated with Room Setup

This scenario tests the process where an proctor manger registers a block and then the proctor
defines rooms within that block. The integration test ensures that once a block is created and
associated with a college, the room registration module recognizes the new block and allows
room numbers to be added under it. The system should reject any attempt to add rooms to a non-
existent or unregistered block, ensuring data integrity between block and room entities.

Login System Integrated with User Roles

This integration test checks the connection between the login module and the user role
management system. When a user logs in, the system verifies credentials and then determines the
role of the user (admin, proctor, or proctor manager) to redirect them to the correct dashboard.
The expected outcome is that the system correctly identifies the user type based on session
information and grants the appropriate access level and page redirection.

Password Reset Integrated with Email System

Here, the password reset feature is tested along with the email notification system. When a user
initiates a password reset, the system must generate a secure token, save it in the database, and
use the PHPMailer library to send the email via Gmail SMTP. Integration testing ensures that the
system handles token generation, database storage, and email delivery as one continuous process.
The test confirms that the reset email reaches the correct email and that the token is valid when
the user enters the new generated password in their next login.

5.2.3. Functional Testing

Login Functionality

The login process was tested to ensure that users can access the system using valid credentials.
For each user type (admin, proctor, and proctor manager), the system was tested to confirm that
it correctly authenticates the user, starts a session, and redirects to the appropriate dashboard.

78 | P a g e
Invalid login attempts were also tested, and the system successfully blocked access while
displaying an error message indicating incorrect username or password.

Student Registration Functionality

This function was tested to verify that a student can be registered by providing valid details such
as name, ID number, and college. The system was able to store the student data in the database,
generate a unique student record, and validate that all required fields were filled. When invalid or
incomplete data was submitted, the system correctly displayed error messages and did not
proceed with registration.

Block and Room Registration Functionality

The system was tested to ensure that a proctor manager can register new blocks by specifying the
block name and associated college. After successful block registration, rooms were added by
providing the room number and total number of rooms. The system correctly linked rooms to
their respective blocks and prevented duplication. Any attempt to register a block without a name
or assign a room number beyond the allowed range was properly handled with validation
messages.

Password Reset via Email

The password reset functionality was tested by submitting a valid email address from the login
page. The system generated a unique reset token and sent an email containing a password using
the PHPMailer library with Gmail SMTP. The password redirected users to a secure password
reset form. The system ensured that the password was valid. and that users could reset their
password securely. Invalid or unregistered emails were correctly rejected with appropriate
messages.

Role-Based Access Control

Each role in the system—admin, proctor, and proctor manager—was tested for proper access
control. Proctor manager could manage blocks, proctor manages rooms, and view all student
data. Proctors were limited to block and student assignments relevant to their supervision.

79 | P a g e
Students could only view their own information, and submit comments. Unauthorized access
attempts to restricted pages were denied, ensuring data security and correct role enforcement.

5.3. Module Description and User Manual Preparation

Module Description

The Mattu University Dormitory Management System is composed of several well-defined

modules. Each module is responsible for a specific function within the system. These modules
are integrated to ensure a smooth and effective dormitory management process.

The Login Module is the gateway to the system. It handles user authentication by verifying
credentials. Based on user roles (admin, proctor, or proctor manager), it redirects users to their
respective dashboards.

The User Management Module is accessible only to the admin. It allows the admin to register
and manage user accounts. This includes adding new proctors and proctor manager or even other
admin, assigning roles, updating user information, and removing inactive users. This module
ensures that only authorized individuals can access the system.

The Block Registration Module is designed for proctor manager to register dormitory blocks.
This module is necessary before rooms can be added or allocated, and it enforces uniqueness and
structure in dorm organization.

The Room Registration Module allows the proctor to create and manage rooms within each
block. The proctor specifies the number of rooms and assigns room numbers.

The Student Dashboard Module displays personal dorm information to each student after
login. Students can view their assigned block, room number, and dorm. They also have the
ability to submit comments or feedback to the admin.

The Comment Management Module allows students to send messages to the admin. These
messages are stored and displayed in the admin dashboard. This module enhances
communication between students and dorm managers.

80 | P a g e
The Password Reset Module enables User to reset their forgotten passwords. The user enters
their registered email, and the system sends a new password via Gmail SMTP using PHPMailer.
This module includes secure token generation and expiration handling.

Each module is integrated to ensure data consistency and ease of navigation, while maintaining
proper role-based access control and system performance.

User Manual Preparation

This section provides a simplified guide for end users—admins, proctors, and student and
proctor manager on how to operate the system.

To begin, every user must log in using their provided credentials. Upon successful login, users
are redirected to their specific dashboards. If a user forgets their password, they may click the
“Forgot Password” link, enter their email, and follow the instructions sent via email to reset it.

For admins, the user management section is accessible through the dashboard. Here, the admin
can register new proctors and students, edit user details, and deactivate accounts.

Proctor manager must register blocks by selecting the college and entering the block name. Once
blocks are created, rooms can be added under each block with defined room numbers and counts.

Proctors, after logging in, can access the dorm allocation interface. They select students from a
list, choose the appropriate dorm, block, and room number, and assign students accordingly. The
system prevents over-allocation or invalid assignments.

Students are presented with their dorm information, including the college, block, dorm, and room
number. Students can also navigate to the comment section to submit issues or suggestions to
dorm administrators.

5.4. Training and Installation

5.4.1. Training
To ensure the successful adoption and effective use of the Mattu University Dormitory
Management System, basic training is provided to the different user groups: admin, proctor, and
student.

81 | P a g e
The admin training focuses on user management, block and room registration, and system
monitoring. Admins are guided on how to add new users and assign roles.. They are also shown
how to receive and respond to student comments, as well as how to oversee system activities.

The proctor training involves instructions on how to log in, view student data, and allocate
students to dorms, blocks, and rooms. Proctors are also trained to maintain data accuracy during
dorm assignments and to use the system responsibly, ensuring compliance with dorm capacity
and college-specific allocations.

The student training is minimal due to the simplicity of their interface. Students are shown how
to view their dorm assignment details, submit comments to the administration.

All training sessions are conducted using live demonstrations supported by a user manual. These
sessions ensure that every user understands their role and can use the system efficiently without
technical difficulty.

5.4.2. Installation Process

The installation of the system involves deploying the web application on a local or cloud-based
server. The system requires a web server such as Apache, PHP (version 7.4 or higher), and
MySQL as the database server. PHPMailer is configured with Gmail SMTP for the email-based
password reset functionality.

The installation process begins by setting up the server environment. The project files are
uploaded to the web server’s root directory. The database is then created, and the provided SQL
script is imported to initialize the necessary tables and relationships. Configuration files such as
[Link] are updated with the correct database credentials and email server settings.

Once the setup is complete, the application is accessed via a web browser. Initial admin
credentials are used to log in and begin registering blocks, rooms, users, and other system data.

Installation guidelines and documentation are provided to the university’s IT staff to assist with
future updates, backups, and troubleshooting.

82 | P a g e
 5.5. User interface and Sample code

5.5.1. User Interfaces

For home page
Figure 36:Home Dashboard

83 | P a g e
 Figure 37:Login Dashboard
Login Page

84 | P a g e
Dashboard to view Dormitory information

Figure 38:Dashboard to view Dormitory information

85 | P a g e
Admin Dashboard

Figure 39:Admin Dashboard

86 | P a g e
Proctor Dashboard

Figure 40:Proctor Dashboard

87 | P a g e
Proctor manager Dashboard

Figure 41:Proctor manager Dashboard

88 | P a g e
5.5.2. Sample Code
For Home page

<?php
include("[Link]");
session_start();
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"[Link]
[Link]"><htmlxmlns="[Link] http-
equiv="Content-Type" content="text/html; charset=utf-8" /><title>MaU Dormitory managent
system</title><link rel="icon" type="image/png" href="img/[Link]"/><link
href="[Link]" rel="stylesheet" type="text/css" media="screen" /><link
href="slideshow/[Link]" rel="stylesheet" type="text/css" /><script
src="slideshow/[Link]" type="text/javascript"></script><link href="[Link]"
el="stylesheet" type="text/css" media="screen" /<link href="[Link]" rel="stylesheet"
type="text/css" media="screen" /><link href="src/[Link]" media="screen" rel="stylesheet"
type="text/css" /<script src="lib/[Link]" type="text/javascript"></script><script
src="src/[Link]" type="text/javascript"></script><script type="text/javascript">
jQuery(document).ready(function($) {$('a[rel*=facebox]').facebox({ loadingImage :
'src/[Link]', closeImage : 'src/[Link] } </script</head<body><table border="0"
align="center" width="750px"><!--Header--><<tr><td width="150%"></td><td id="loginlink"
align="right"> <a href="[Link]" id="log"> <img src="img/[Link]"
alt="Login"style="height:24px; width:auto;"> </a></td></tr><tr> <td width="500px"
colspan="3" height="120px" style="background-color: green; padding: 20px; borderradius:px;">
<p <a href="[Link]" <img src="img/[Link]" align="left" width="150px" height="120px">
</a> <img style="border-radius:55px; box-shadow:1px 1px 12px black;" src="img/[Link]"
align="center" width="470px" height="120px"> </ </td</tr><-End Of Header--<!--Main menus-
-<tr><td colspan="3" width="750px"><div id="sse2 <div id="sses2" > <ul <li><a
href="[Link]">Home</a></li<li><a href="[Link]">About Us</a></li <li><a
href="[Link]">Contact Us</a></ <li><a href="[Link]">View Dorm</a></li<li><a
href="[Link]">Admin Login</a></<li><a href="[Link]">readrule</a></li </ul>
</di </div></td</tr><!--End of main menus--><!--Slide shows--><tr ><td colspan="2"
valign="top" height="200px"><div id="sliderFrame" <div id="slider"> <img
src="slideshow/images/[Link]" alt="Building One" /><img
src="slideshow/images/[Link]" alt="Photo Two" /> <img
src="slideshow/images/[Link]" alt="Photo Three" <img
src="slideshow/images/[Link]" alt="Photo Four" <img
src="slideshow/images/[Link]" alt="Photo Five" </div</div</t</tr>
<!--End of Slide shows--<table align="center" id="insides" width="850px"><tr><!--Sub menus-
-><td width="25%" height="500px" valign="top" id="insides"><table ><tr>
<th align="center" width="250px" height="25px" bgcolor="#339966"><font face="arial"
color="white" size="2">MaU-DMS</font></th>

89 | P a g e
For login

<?phpinclude("[Link]"); session_start();?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"[Link]
[Link]"><htmlxmlns="[Link] http-
equiv="Content-Type" content="text/html; charset=utf-8" /><title>MaU Dormitory
managent system</title><link rel="icon" type="image/png"
href="img/[Link]"/>link href="[Link]" rel="stylesheet" type="text/css"
media="screen" /><link href="slideshow/[Link]" rel="stylesheet" type="text/css"
/><script src="slideshow/[Link]" type="text/javascript"></script>
<link href="[Link]" rel="stylesheet" type="text/css" media="screen" /><link
href="[Link]" rel="stylesheet" type="text/css" media="screen" /><link
href="src/[Link]" media="screen" rel="stylesheet" type="text/css" /><script
src="lib/[Link]" type="text/javascript"></script><script src="src/[Link]"
type="text/javascript"></script><script type="text/javascript">
jQuery(document).ready(function($) $('a[rel*=facebox]').facebox({ loadingImage :
'src/[Link]' closeImage : 'src/[Link]'} }</script></head><body>
<table border="0" align="center" width="750px"><!--Header--><<tr><td
width="150%"></td><td id="loginlink" align="right"> <a href="[Link]" id="log">
<img src="img/[Link]" alt="Login" style="height:24px; width:auto;" </a></td></tr<tr
<td width="500px" colspan="3" height="120px" style="background-color: green;
padding: 20px; border-radius: px;"<p <a href="[Link]"<img src="img/[Link]"
align="left" width="150px" height="120px"></a <img style="border-radius:55px; box-
shadow:1px 1px 12px black;" src="img/[Link]" align="center" width="470px"
height="120px" </p</t</t<!--End Of Header-<!--Main menus--<tr<td colspan="3"
width="750px"<div id="sse2 <div id="sses2" <ul <li><a
href="[Link]">Home</a></li <li><a href="[Link]">About Us</a></li> <li><a
href="[Link]">Contact Us</a></li><li><a href="[Link]">View
Dorm</a></li> <li><a href="[Link]">Admin Login</a></li>
<li><a href="[Link]">readrule</a></li </ul </di </di</td>
</tr<!--End of main menus--><!--Slide shows-<tr<td colspan="2" valign="top"
height="200px"><div id="sliderFrame"><div id="slider">
<img src="slideshow/images/[Link]" alt="Building One" />
<img src="slideshow/images/[Link]" alt="Photo Two" />
<img src="slideshow/images/[Link]" alt="Photo Three" />
<img src="slideshow/images/[Link]" alt="Photo Four" />
<img src="slideshow/images/[Link]" alt="Photo Five" />

90 | P a g e
 CHAPTER SIX

6. Conclusions and Recommendation

6.1. Conclusions
The Web-Based Dormitory Management System for Mattu University (MaUODMS) is designed
to modernize and streamline dormitory management by replacing the current manual system.
Mattu University, with over more students, faces challenges in dormitory allocation, including
data duplication, inefficiencies, and accessibility issues. The proposed system aims to automate
student dorm assignments, provide online access to dormitory information, and enhance
administrative efficiency. Key features include a user-friendly interface, a centralized database
for student and dormitory records, automated dorm assignments, and an online portal for
students to view dorm details and submit complaints. The system follows an object-oriented
approach using PHP, MySQL, JavaScript, and CSS and is developed based on the Waterfall
Model of software development. A feasibility study confirms that the system is economically,
technically, and operationally viable, with significant cost savings by reducing administrative
workload. The project also ensures data security using MD5 encryption, improving record
accuracy and reducing human errors. The expected benefits include faster dorm allocation,
enhanced student experience, better resource management, and improved reporting capabilities.
While the system has some limitations, such as English-only support and partial offline
interactions, it significantly enhances efficiency compared to the manual system. Overall,
MaUODMS offers a scalable, secure, and reliable dormitory management solution that
modernizes university housing services and improves the student experience.

91 | P a g e
 6.2. Recommendation
Add room change request functionality.
Enable email and SMS notifications.
Optimize the system for mobile responsiveness
Develop a dedicated mobile app (optional).
Add AI-based room assignment suggestions.

92 | P a g e
 References

[1] J. Wolff, " How Is Technology Changing the World, and How Should the World Change
Technology?," University of California, 24 August 2021. [Online]. Available:
[Link]
World-and-How. [Accessed 18 December 2024].

[2] A. Us, " About Us," Mattu University, 2011. [Online]. Available:
[Link] [Accessed 18 December 2024].

[3] S. W. Ambler, The Object Primer, Cambridge: Cambridge University Press, 2001.

93 | P a g e