ARSI UNIVERSITY

COLLEGE OF NATURAL AND COMPUTATIONAL SCIENCES

DEPARTMENT OF COMPUTER SCIENCE

DORMITORY MANAGEMENT SYSTEM

SUBMITTED TO DEPARTMENT OF COMPUTER SCIENCE

IN PARTIAL FULFILMENT OF THE REQUIREMENT FOR

THE DEGREE OF BACHELOR OF SCIENCE IN COMPUTER SCIENCE

BY

Name ID No.
1. Helen Tilahun CCS/UR7794/11
2. Milion Nugusie CCS/UR7747/11
3. Negasa Birhanu CCS/UR7751/11
4. Samuel Rabuma CCS/UR7759/11
5. Tahir Dekamo CCS/UR7761/11

ADVISOR: Mr. Duressa Deksiso (Msc.)

Arsi Asella, Ethiopia

March, 2022
 DECLARATION
This is to declare that this project work which is done under the supervision of Mr. Duressa Deksiso
(Msc.) and having the title “Dormitory Management System for ARU” is the sole contribution of
Milion Nugusie, Tahir Dekamo, Samuel Rabuma, Negasa Birhanu, and Helen Tilahun.

No part of the project work has been reproduced illegally (copy and paste) which can be considered
as Plagiarism. All referenced parts have been used to argue the idea and have been cited properly.
We will be responsible and liable for any consequence if violation of this declaration is proven.
Full Name Signature Date

1. Milion Nugusie _________________ ______________

2. Tahir Dekamo _________________ ______________

3. Samuel Rabuma _________________ ______________

4. Negasa Birhanu _________________ ______________

5. Helen Tilahun _________________ ______________

I
 APPROVAL FORM
This is to confirm that the project report entitled “Dormitory Management System for ARU”
submitted to Arsi University, College of Natural and Computational Sciences, Department of
Computer Science by: Milion Nugusie, Tahir Dekamo, Samuel Rabuma, Negasa Birhanu, and Helen
Tilahun are approved for submission.

Advisor Name Signature Date

------------------------------------------------- ------------------------------ ---------------------

Department Head Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 1 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 2 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

Examiner 3 Name Signature Date

------------------------------------------------- ------------------------------ -------------------

II
ACKNOWLEDGEMENT
First of all, we would like to Thanks God for giving us spiritual fulfillment and moral
strength to complete this documentation.

Next we would like to thanks our advisors Mr. Duressa Deksiso (MSc.) and Mr. Fayisa
Dekebi for their special contribution, support, directions assistance, guidance and helping
us throughout the preparation of this documentation.

We would like to thanks Dormitory management of Arsi university Dinsho campus staff,
special Mr. Fayisa (Proctor manager) for his willingness to give us sufficient information
during data collection.

Finally, we would like to thanks our classmate students who helped us in successful
completion of this documentation.

III
TABLE OF CONTENTS
DECLARATION ................................................................................................................................ I
APPROVAL FORM ......................................................................................................................... II
ACKNOWLEDGEMENT ............................................................................................................... III
TABLE OF CONTENTS ................................................................................................................. IV
LIST OF TABLE ........................................................................................................................... VII
LIST OF FIGURES ...................................................................................................................... VIII
LIST OF ABBREVATIONS ........................................................................................................... IX
ABSTRACT ...................................................................................................................................... X
Chapter one ........................................................................................................................................ 1
1. Introduction ................................................................................................................................. 1
1.1. Background of the Organization .......................................................................................... 1
1.2. Statement of problem ........................................................................................................... 2
1.3. Objectives of the Project ....................................................................................................... 3
1.3.1. General Objectives ...................................................................................................................... 3
1.3.2. Specific Objectives ..................................................................................................................... 3
1.4. Feasibility Study................................................................................................................... 3
1.4.1. Technical feasibility .................................................................................................................... 3
1.4.2. Operational feasibility ................................................................................................................. 4
1.4.3. Economic feasibility ................................................................................................................... 4
1.5. Significance and Beneficiary of the Project ......................................................................... 4
1.6. Scope and Limitation of Project ........................................................................................... 5
1.6.1. Scope of Project .......................................................................................................................... 5
1.6.2. Limitation of Project ................................................................................................................... 6
1.7. Methodologies of Project ..................................................................................................... 6
1.7.1. Methodologies for data collection............................................................................................... 6
1.7.2. System analysis and design techniques....................................................................................... 7
1.7.3. System Development Models ..................................................................................................... 7
1.7.4. System Testing Methodology ..................................................................................................... 8
1.8. System Development Tools and Techniques ....................................................................... 9
CHAPTER TWO ............................................................................................................................. 11
2. DESCRIPTION OF EXISTING SYSTEM .............................................................................. 11
2.1 Introduction to Existing System ......................................................................................... 11
2.2 Users of Existing System ................................................................................................... 11
IV
 2.3 Major Function of Existing Systems .................................................................................. 11
2.4 Forms and Other Documents of the Existing Systems....................................................... 12
2.5 Drawbacks of the Existing System .................................................................................... 15
2.6 Business rule of the existing system .................................................................................. 16
CHAPTER THREE ......................................................................................................................... 17
3. PROPOSED SYSTEM ............................................................................................................. 17
3.1. System Description ............................................................................................................ 17
3.2. Functional Requirement of Proposed System .................................................................... 17
3.3. Non-functional Requirements ............................................................................................ 18
3.3.1. User Interface and Human Factors............................................................................................ 18
3.3.2. Hardware Consideration ........................................................................................................... 18
3.3.3. Security Issues .......................................................................................................................... 19
3.3.4. Performance Consideration....................................................................................................... 19
3.3.5. Error Handling and Validation.................................................................................................. 19
3.3.6. Quality Issues ............................................................................................................................ 19
3.3.7. Backup and Recovery ............................................................................................................... 19
3.3.8. Physical Environment ............................................................................................................... 20
3.3.9. Resource Issues ......................................................................................................................... 20
CHAPTER FOUR ............................................................................................................................ 21
4. SYSTEM ANALYSIS .............................................................................................................. 21
4.1. System Model ..................................................................................................................... 21
4.1.1 Use Case Model ........................................................................................................................ 21
4.2. Object Model ...................................................................................................................... 33
4.2.1. Class Diagram ........................................................................................................................... 33
4.2.2. Data Dictionary ......................................................................................................................... 35
4.3. Dynamic Model .................................................................................................................. 37
4.3.1. Sequence Diagram .................................................................................................................... 37
4.3.2. Activity Diagram ...................................................................................................................... 48
4.3.3. State Chart Diagram.................................................................................................................. 56
CHAPTER FIVE ............................................................................................................................. 61
5. SYSTEM DESIGN ................................................................................................................... 61
5.1. Design Goals ...................................................................................................................... 61
5.2. Proposed System Architecture ........................................................................................... 62
5.2.1. Subsystem Decomposition and Description ............................................................................. 63
5.2.2. Hardware/Software Mapping .................................................................................................... 65
V
 5.2.3. Detailed Class Diagram ............................................................................................................ 66
5.2.4. Persistent Data Management..................................................................................................... 68
5.2.5. Access Control and Security ..................................................................................................... 69
5.3. Packages ............................................................................................................................. 71
5.4. User Interface Design ......................................................................................................... 72
References ........................................................................................................................................ 75
Appendix .......................................................................................................................................... 76

VI
 LIST OF TABLE
Table 1.1 Hardware tools -------------------------------------------------------------------------------------------------------- 9
Table 1.2 Software tools --------------------------------------------------------------------------------------------------------- 9
Table 1.3 Development languages --------------------------------------------------------------------------------------------10
Table 4.1 Use case identification----------------------------------------------------------------------------------------------23
Table 4.2 Data dictionary for Block ------------------------------------------------------------------------------------------35
Table 4.3 Data dictionary for user account ----------------------------------------------------------------------------------35
Table 4.4 Data dictionary for Allocated students --------------------------------------------------------------------------36
Table 4.5 Data dictionary for comments of different user ---------------------------------------------------------------36
Table 5.1 Access privileges for users ----------------------------------------------------------------------------------------70

VII
 LIST OF FIGURES
Figure 1-1 Iterative model ------------------------------------------------------------------------------------------------------- 8
Figure 2-1 Form for allocation-------------------------------------------------------------------------------------------------13
Figure 2-2 Document for comments ------------------------------------------------------------------------------------------14
Figure 4-1 Use case diagram ---------------------------------------------------------------------------------------------------24
Figure 4-2 Class diagram -------------------------------------------------------------------------------------------------------34
Figure 4-3 Data dictionary for room------------------------------------------------------------------------------------------37
Figure 4-4 sequence diagram for login---------------------------------------------------------------------------------------38
Figure 4-5 Sequence diagram for Delete user account--------------------------------------------------------------------39
Figure 4-6 Sequence diagram for Generating report ----------------------------------------------------------------------40
Figure 4-7 sequence diagram for create user account ---------------------------------------------------------------------41
Figure 4-8 Sequence diagram for update user account -------------------------------------------------------------------42
Figure 4-9 Sequence diagram for register block ---------------------------------------------------------------------------43
Figure 4-10 sequence diagram for allocate dorm --------------------------------------------------------------------------44
Figure 4-11 Sequence diagram for Student view dorm -------------------------------------------------------------------45
Figure 4-12 Sequence diagram for View student information-----------------------------------------------------------46
Figure 4-13 sequence diagram for change user password ----------------------------------------------------------------47
Figure 4-14 Activity diagram for login --------------------------------------------------------------------------------------49
Figure 4-15 Activity diagram for Create user account --------------------------------------------------------------------50
Figure 4-16 Activity diagram for registering block -----------------------------------------------------------------------51
Figure 4-17 Activity diagram for allocate dorm ---------------------------------------------------------------------------52
Figure 4-18 Activity diagram for view dorm -------------------------------------------------------------------------------53
Figure 4-19 Activity diagram for view student info -----------------------------------------------------------------------54
Figure 4-20 Activity diagram for forget password ------------------------------------------------------------------------55
Figure 4-21 state chart diagram for login ------------------------------------------------------------------------------------56
Figure 4-22 state diagram for view dorm info ------------------------------------------------------------------------------57
Figure 4-23 state chart diagram for register block -------------------------------------------------------------------------58
Figure 4-24 state chart diagram for generate report -----------------------------------------------------------------------59
Figure 4-25 state chart diagram for allocate dorm -------------------------------------------------------------------------60
Figure 5-1 Proposed system architecture ------------------------------------------------------------------------------------63
Figure 5-2 Subsystem decomposition ----------------------------------------------------------------------------------------64
Figure 5-3 component diagram ------------------------------------------------------------------------------------------------65
Figure 5-4 Deployment diagram ----------------------------------------------------------------------------------------------66
Figure 5-5 Detailed class diagram --------------------------------------------------------------------------------------------67
Figure 5-6 Persistent diagram --------------------------------------------------------------------------------------------------68
Figure 5-7 Package diagram ---------------------------------------------------------------------------------------------------72
Figure 5-8 Interface design of homepage ------------------------------------------------------------------------------------73
Figure 5-9 User Interface design for login ----------------------------------------------------------------------------------74

VIII
LIST OF ABBREVATIONS
ARU: - Arsi University
BR: - Business Rule
CPU: - Central Processing Unit
CSS: - Cascading Style Sheet
DMS: - Dormitory Management System.
DVD: Digital Versatile Disk
ETB: - Ethiopian Birr
GB: - Giga Byte
GHz: - Giga Hertz
HTTP: Hyper Text Transfer Protocol
HTML: - Hyper Text Markup Language
MS Word: - Microsoft Word
MS_ppt:- Microsoft Power Point
MySQL: - My Standard Query Language
OOA: Object Oriented Analysis
OOD: Object Oriented Design
PHP:-Preprocessor Hypertext Preprocessor
RAM: - Random Access Memory
UC: Use Case
USB: Universal Serial Bus
UML: Unified Modeling Languages
WAMP: - Window Apache MySQL PHP
XAMPP: - Xerox Apache MySQL Perl PHP

IX
 ABSTRACT
Arsi University Dormitory management system is the system that provides services for regular
undergraduate students in the campus. While providing this service there are different activities hold
by proctors and proctor managers like; arranging list of students, list of building block and rooms,
assigning students to dorm and deallocating when they leave campus, generating reports for
concerning body, commenting on status of dorm and etc. To do those and other tasks Arsi University
dormitory management system uses a manual system and need more human power. This causes them
different problems like; extravagancy of resources, losses of student’s data and information,
duplication and redundancy of data, improper allocation of dorms, and violation of business rule is
also an issue.
Due to this reason we have proposed to develop a computerized web based Dormitory Management
System that overcome problems encountered in manual operation of existing system. To develop a
proposed system we followed Iterative model of software development, because our system
decomposed into subsystems and each subsystems passes through each of the phases before
deployment. It involves requirement gathering and analysis, designing system, implementing, testing
(verification and evaluation), and finally deploying. In this document we have discussed the first three
phases and we will proceed the next steps on the next phase of this project. To collect data we have
used methods like interview, direct observation and existing documents analysis. To analyze and
design system we have used object oriented analysis and object oriented design methods. In the
implementation phase we started to use system development languages like PHP, CSS, HTML,
JavaScript, and MySQL. The system we are developing is analyzed using different model of analysis
like; Functional model by using Use case diagram, Object model by using class diagram and data
dictionary and finally dynamic model by using sequence diagram, activity diagram, and state chart
diagram.
Finally, the analyzed requirement are restructured and formalized to reduce complexity of system
using different system design like; subsystem decomposition, component and deployment diagram for
hardware and software mapping, persistent data management and packages.

X
 Chapter one
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 organizations
needs to be preferable, computable and work on fastest way in order to satisfy users interest etc. i.e.
they should have facilitate their activities in computerized way.
Hence, developing the system using technology has a tremendous effect for organizations and offices;
which is in our case the Arsi University dormitory management system. Currently, the system is
manual based; due to this the students and proctors faces some problems. Because of this, we are
initiated to develop our project on dormitory system in order to minimize the problem by using
computerized system.

1.1. Background of the Organization

Arsi University is one of the public institutions of higher learning in Ethiopia and found in central
part of Oromia Region in Arsi Zone. Arsi university established in 2014(2006 E.C) by decree
No.322/2014 of the Council of Ministers of the Federal Democratic Republic of Ethiopia. Arsi
University started with four Colleges and one School, namely; College of Agriculture and
Environmental Sciences, College of Health Sciences, College of Business and Economics, College of
Humanities and School of Law and now College of Natural and Computational science also founded
last year [1].
Mission
Arsi university have a mission of offering relevant and quality education and training, conducting
demand driven research and rendering accessible community services.
Vision
Arsi University aspires to be among leading east African universities and recognized university in the
world by 2023.
Values
 Customer focused
 Quality first
1
  Innovation
 Respect diversity environment friendly
 Efficiency and effectiveness
 Professional commitment
 Transparency

1.2. Statement of problem

The current system of Arsi University dormitory management system is manual. In order to arrange
and allocate students to dorms, they have to get list of record from Arsi University and allocate
Students depending on department and the lists of the students’ arrangement. After getting the list
from the university, 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.
In addition to the above problems, the manual searching system of a required information is very time
consuming and sometimes may lead to inability to find the information that already exists. This results
in storing the same information again and again. And also the data may disappear because of some
real world problems since it is stored on papers manually. Duplication of data of students can be
occurred.
Proctors manager and proctors faces problem to manage their activities and students, because of
improper and in consistent information of students. It’s difficult to communicate with the dormitory
when there is no assigned dorm for an individual student, because the existing system is not accessible
automatically. It is difficult to find which dorm (block) is allocated or de allocated. Data recording
system is not centralized or not in the modern system which is difficult to operate and in accurate
report generation.
Generally, for the above and other problems the existing dormitory management system is weak and
need to be changed in to partially automated system.

2
 1.3. Objectives of the Project
1.3.1. General Objectives
The general objective of this project is to develop Web Based Dormitory Management System for
Arsi University.
1.3.2. Specific Objectives
The aim of this project is to achieve general objective of project with the following specific objectives:
 Studying and analyzing the existing system.
 Identify the problems of the existing system.
 Perform requirement analysis.
 Design the analyzed requirements.
 Implement and test the system
 Demonstrate the potential of the system for further application and scalability.

1.4. Feasibility Study

Feasibility studies are an evaluation and analyzing of a project to determine if it is technically feasible,
is economically feasible and is operationally feasible or not.
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.4.1. Technical feasibility
In this project the team will uses languages such as HTML5, PHP, Java script, MySQL, and CSS3
to develop the new system. All these are the technology side. The technical persons who develop
the new system are all the members of the project. The project team, to develop the new system,
gathers the required information/data from the University as much as possible, make the analysis
and design phase and implementation and test phase within the schedule or as per schedule. The
next phase is the person who gives training (technical person) for the user of the system. Since all
the project team members are capable of the required technical skills, the team can conclude that
the project will be technically feasible.

3
 1.4.2. Operational feasibility
The system to be 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. That means compatible with window operating system and others
to use different notification for the purpose user’s simple access the system without any ambiguity.
1.4.3. 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 will be
developed, brought a number of tangible and intangible benefits.

1.5. Significance and Beneficiary of the Project

The significance can be estimated in terms of energy, time which means the advantage is real or actual
rather than imaginary or visionary. For instance, improving response time, producing error free out
put such as producing information.
The significance of this project:-
 The system make tasks simple and efficient in every aspects.
 The system manage the students and building information.
 It provides a well-organized and guaranteed record keeping system with minimum space and
effort need.
 Avoiding wastage of student’s time as well as management time.

 Avoiding improper dormitory allocation

 Avoiding improper resource consumption
Target beneficiary of proposed system
There are different bodies that will be benefited from this system. The main beneficiary of
this system is the Dormitory Management in which, first, the environment is changed to a
computerized environment, which improves the quality of internal operations as well as
services given to students. Secondly the problem associated with manual processing is
minimized and the quality of work and services became improved.
The beneficiaries of the system are University, proctor manager, proctors and students.

4
  Proctor and proctor manager: proctors and proctor managers are benefited from
the system in such a way that the quality and performance of their work is
improved, the time they spent for manual operation is significantly reduced and
their management and control of their job is improved. They will also be benefited
from the system. These benefits may be in saving time while arranging buildings,
Dorms and Students, minimizing errors while allocating students, and avoiding data
loss.
 Students: the students can view their dormitory information easily and timely. That is, once
the allocation report is generated by the system, the system provides an interface
which enables the students to know about their dormitory information.

 University: reduces extra cost for stationary materials and employee salary and succeeds its
way toward modern technology.

1.6. Scope and Limitation of Project

1.6.1. Scope of Project
Since ARU 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 project supposed to cover the following scope:-

 Securing and protecting data and information of system users from unauthorized access

 Allow proctor manager registering block information and assigning proctor properly to each
block

 Allow system administrator managing user information and system activity

 Allow proctors to register room, allocate and deallocate students in consideration of business
rules

 Enabling students to access their dorm placement timely and properly

 Allow Proctors to access student information

 Allow Proctors and students to deliver system based comment.

5
  Allow proctors and proctor manager to generate latest report of general block assigned,
registered room and assigned students.

 Assign new and/or disabled students asper as business rule.

Generally, this project is supposed to provide the better services for students and dormitories over
existing system.
1.6.2. Limitation of Project

The project we are developing has limitation on fields like:

 Our system works when a server control services is available.

 It works for the one who understand English language (we have not planned to use other
language).
 It serves only students who are regular undergraduates in ARU.

1.7. Methodologies of Project

1.7.1. Methodologies for data collection
The data collection instruments is used to gather accurate information about the existing system and

the requirements for the new system. Interviews and questionnaires will be administered to

Stakeholders like proctors, and proctors manager to collect user requirements. Observation of the

current existing system holds in order to find out how the existing system functions, the problems

encountered and how they can be solved by the new computerized system.

To get a precise data, the team member used the following data collection techniques.

Those are: -

A. Interview: - to get the basic and background information about the existing system, the team

members made interview the students, proctor managers, and proctors about the services that

are given to them, and the problems associated with that environment.

B. Direct observation: even though interview is very important to gather information, direct
observation is simple and project team members have to physically observe information that

6
 cannot maintain from the interview or others and also it is important if they are unable to
communicate with stakeholder because of the language difficulties they have.
C. Existing document: To get more information about the project we will 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.7.2. System analysis and design techniques
Here for the analysis of our project we have selected object oriented system analysis and design
method specifically UML (Unified Modeling Language) model.
This has the following phases: -

 Object Oriented Analysis (OOA): During this phase the team used to Model the
functions of the system (use case modeling), Find and identify the business objects,
Organize the objects and identify the relationship between them and finally model the
behavior of the objects.

 Object Oriented Design (OOD): During this phase the team used to refine the use
case model to reflect the implementation environment, Model object interactions and
behaviors that support the use case scenario, and finally update object model to reflect
the implementation environment.
We have selected this techniques 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.7.3. System Development Models
Software development methodology we are going to use for our system development is iterative
software development methodology.

7
Iterative development is a rework scheduling strategy in which time is set aside to revise and improve
parts of the system. This model iterates requirements, design, build and test phases again and again
for each requirement and builds up a system iteratively till the system is completely build.

Figure 1-1 Iterative model

1.7.4. System Testing Methodology

Before directly deploying this system the team will perform different testing for its functionality and
meeting customers need. First the team tests each unit at each phase. So, if a problem is encountered
it will immediately fixed. Second the team will perform an integration testing to check whether the
system meets all the functional requirements.
In order to deliver this system as well operated system to test this project at implementation phase by
using different types of testing methodologies. Those testing methods are:

8
 I. Unit testing: - To test the independent module using this mechanism of testing.
II. Integration testing: - using this type of testing method to test the modules which are
independent and dependent to each other.
III. System Testing: -using this methods will test the functionality of all modules considering
as a single system. System will be tested using the following system testing procedures.
 Alpha testing:-In this testing method, the system will tested by giving the correct
input. It is tested by a customer at the developer Site .
 Beta testing: -In this testing method, team will force the system to be tested for
incorrect data input.

1.8. System Development Tools and Techniques

While developing the project starts from the documentation to the implementation we will use the
following case tools:
Hardware Tools
TOOLS ACTIVITIES
Flash disk with >=8 GB To transfer data from one computer to the other computer.
Used for recovery purpose.
Both desktop and laptop computer To input data, to display the output, to do the main programs and to insert input and
with >=4 GB RAM and 500 GB to store information.
(this specifications are a minimum
requirement)
Printer For print the documentation.
Ethernet cable Used for connection to access different information that helps our projects.
Table 1.1 Hardware tools

Software Tools
TOOLS ACTIVITIES
Notepad++, Sublime_Text_2.0.2 For code editing
Chrome, Internet explorer, Opera mini Browser
MS Word For write documentation part.
MS_ppt For presentation purpose.
Edraw Max To draw different diagrams.
Table 1.2 Software tools

9
Development languages
Languages used Purposes used for

HTML
JavaScript For Client side scripting or front end development
CSS
PHP For Server side scripting
MySQL Database for data storage and access
Table 1.3 Development languages

10
 CHAPTER TWO
2. DESCRIPTION OF EXISTING SYSTEM

2.1 Introduction to Existing System

This chapter describes the existing system, players in the existing system general work flow of ARU
dormitory management. In addition to this the business rule is identified, report generated in the
existing system, alternative solutions suggested to overcome existing system, finally the proposed
system (functional and non-functional requirement).

2.2 Users of 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 proctor manager. 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.3 Major Function of Existing Systems

Even if the existing system is performs its activities manually, 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 prepared by proctor manager.
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.
11
 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.
 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.4 Forms and Other Documents of the Existing Systems

In the existing system, they use different forms and reports to manipulate different records associated
with the different activities. Those reports include Student Dormitory allocation forms, 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 form contains the information related to student’s block number and
dorm number; as well as materials and resources given.
 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.
Among those Dormitory allocation form is one of the main paper document used in the existing
system.

12
Figure 2-1 Form for allocation

13
Figure 2-2 Document for comments

14
 2.5 Drawbacks of the Existing System
The manual dormitory management system have many drawbacks. These drawbacks 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 and measured by its throughput and response time.
o Response time:-the performance of the current system is weak because of its response
time is very high. For instance when proctor want to update or change the allocation
information of a student who assigned wrongly in the existing system, it takes too much
time to search the document and change it.
o Throughput: - due to every task is performed by manual way the throughput of the
existing system is very high. For instance when the proctor manager arranges blocks for
allocation it sakes too much time to arrange the buildings.
 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 dormitory. The system manipulates and manages all of these and other
records manually on papers.
 Economy
From view of material, there is high resources usage for unnecessary expanses, like paper,
pen and etc. For a number of students per dorms there is a number of paper. The same is true
for report purpose also. This cause the university to spend more money for regularly buying
of those stationary materials.
From view of man power, since there are a number of proctor managers and proctors for
allocation purpose only, the university has to pay salary for each employee. This factor also
lead university to spend extra money for employee salary.

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

15
  Efficiency
o Time wastage: - employees waste time due to manual: - data processing, data entry, report
generation and Preparation of different forms.
o Material wastage: - The organization wastes many materials especially concerning
stationery materials, and file cabinets.
 Services- The services given to users is not flexible i.e. the users (proctor manager, proctor and
student) must be in the university to access the system. For instance students must be in the
university to see their dormitory information stumped on the wall of buildings.
 Space reservation problems: - the manual system is using papers for storing information. As
the number of students is increasing and information is stored redundantly, the space reserved
for storing this information is more than required.

2.6 Business rule 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 [2] [3]. It often pertain to access control issues,
business calculations, or operating polices and principles of the organization.
BR1: one dorm is assigned only for eight students, and those students should live in the dorm which
belongs to him/her.
BR2: Students are allocated in such a way that male students are not allocated with female students.
BR3: Proctors should not assign one student in more than one dorm.
BR4: Buildings should be arranged before the allocation.
BR5: After the allocation reports should be prepared by proctors for students’ i.e. for posting.
BR6: Allocation should be arranged by faculty and batch.
BR7: During allocation disability status should be in consideration.
BR8: Fresh students should assigned to dorm based on their Registration number.

16
 CHAPTER THREE
3. PROPOSED SYSTEM

3.1. System Description

The proposed system is computerized web based system that can change the existing system currently
used by Arsi University dormitory service. The general overview of the proposed system is designed
to address the problems of the existing system of dormitory services. The proposed system will solve
those entire problems in the existing system in case the system supposed to be very integrated. It can
control all the data input and error which happen during data registration. The proposed system will
be able to access and retrieve different data effectively and efficiently. It will provides single (or
multiple) point of contact for user to gain assistance in troubleshooting, get answer to question and
solve known problems. This will brings operational efficiency by minimizing time wastage and cost
funded by the university to dormitory service and minimizes the burden of proctors by replacing paper
based system to computerized, replace stumping and pasting allocation paper.

3.2. Functional Requirement of Proposed System

Functional requirements explain what has to be done by identifying the necessary task, action or
activity that must be accomplished [4]. Functional requirements analysis will be used as the top level
functions for functional analysis. A function is described as a set of inputs, the behavior, and outputs.
Functional requirements may be calculations, technical details, data manipulation and processing and
other specific functionality that define what a system is supposed to accomplish. The functional
requirements that the DMS will provide:
Data entry: This is the functionality that data is entered to the database. The system serves different
interface that can manage data entry mechanisms in the system. The main data entries are the
following:

 Login

 Submission of report and comment

 Search information

 User registration (all actors)

 Block and room registration.

17
  Manage the student data.

 Assign the students in their dorm.

 Display student information.

 Manage the block and dorm information.

 Retrieve the students, blocks and dorm information.

 check the status of block and dorm

 accept comment
Data processing: The system on input data will provide the following data processing:

 Member’s validation

 Verify the requested information

 Search user request (view dorm placement, view report, view assigned students).

 Validate submission details (files like comment, and student ask basic service)
Generally, the functional requirements of our system is that it provides almost all functionalities of
existing system and provides advanced services for user/client of system over existing system.

3.3. Non-functional Requirements

3.3.1. User Interface and Human Factors
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 ARU DMS 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. Since the system is planned with
attractive and user-friendly interface; users expected to feel comfort and interested to use it.
3.3.2. Hardware Consideration
The system will use high memory capacity and high processing speed computers to help users in
getting instant responses.

18
 3.3.3. Security Issues
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.
3.3.4. Performance Consideration
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. Since the system
will be accessed by different users with different needs, it is capable of handling and processing their
queries quickly. Usually it is hard to tell exactly how many users will be using the system at a time.
However, if the system is being accessed by many, all the users must feel that they are the only one
using the system.
3.3.5. Error Handling and Validation
When the user makes some mistakes the system will responds that error is occurred using easily
understandable messages and allows the user to recover from the error. The system should handle
error and extreme condition during operation. The error could occur because of user of the system
itself. In the case of error occurred because of human error while login to the system or entering data,
the error should be handled by appropriate exception handling mechanism. Like displaying message
which tells user’s that user name or password or data entered is incorrect. Error due to system failure
will be handled by having a regular data back up during system operation.
3.3.6. Quality Issues
Information in database should be as much as possible correct and updated in each semester.
3.3.7. Backup and Recovery
A backup or the process of backing up refer to making copies of data so that these additional copies
may be used to restore the original after a data loss event. These additional copies are typically called
"backups." Backups are useful primarily for two purposes.
1. The first is to restore a state following a disaster (called disaster recovery).
2. The second is to restore small numbers of files after they have been accidentally
deleted or corrupted.
There are several realistic methods for backing up data. Some of them are Flash Memory, DVD
Backup, Tape Backup, and Hard Drives.

19
 For the system we are going to develop, we choose Hard Drives because copying and retrieving
data from separate hard drives is very easy and cheap compared to tape drive systems. All we have
to do is plug the hard drive into our computer’s USB port. And while hard drives do fail, their
failure rate is much lower than that of backup media such as CDs.
3.3.8. Physical Environment
Physical environment, mainly concerns with the environment in which system will perform better. So
those physical environment ranges from air condition under which server operates to ergonomics
arrangement of server-client computers. Since Arsi university is currently growing in technology
issues from time to time. Its main data center may afford server machine to deploy the system
effectively. The system is expected to withstand the following external factor.
 Less processor speed of personal computer that are caused by dust and other unnecessary
things happened in client computers for accessing the system.
 Less power that causes the system fail or stop functionality.
 The server and the other devices in which system installed should kept in a secured and air-
conditioned rooms.
3.3.9. Resource Issues
On the server side the resource required by the server will be a hung memory space, high speed
processor and good connection to serve many users. However on the client side, internet access and
connection speeds many become an issue.

20
 CHAPTER FOUR
4. SYSTEM ANALYSIS

4.1. System Model

To produce a model of the system which is correct, complete and consistent we need to construct the
analysis model which focuses on structuring and formalizing the requirements of the system. Analysis
model contains three models: functional, object and dynamic models. The system model can be
described by use case diagrams. Class diagrams describe the object model. Dynamic model can also
be described in terms of sequence, state chart and activity diagrams. For the purpose of this project
we have described the analysis model in terms of the functional model, object model and dynamic
models by using use case, class, activity and sequence diagrams [5] [6].
System modeling involves the evaluation of system components in relationship with one another to
determine their requirements and how to satisfy them. Some system modeling tools will be employed
during the course of this project that will support development tasks, from analysis to design, then to
implementation. This will be represented with the use of the sequence diagram, activity diagram, state
chart diagram, collaboration diagram and class diagram for the Dormitory Management System.

Here are the scopes of the system modeling phase.

 Functionality description of the system by using use case diagrams.

 Structural description of the system in class diagram.

 Communication of the objects of the system by using sequence diagrams.

 Flow of actions using activity diagram

4.1.1 Use Case Model

The use case model describes the proposed functionality of the new system. A use case represents a
discrete (distinct) unit of interaction between users and the system. Use cases are tasks of the proposed
system [7]. Use case modelling involves the following activities:

 Identifying if there is any additional actors and use cases,

 Constructing a use case model, and
 Documenting the use case course of events.
21
Actor Identification
Actor: are external factors that interact with the system. This may include Proctor Manager, Proctors,
Students, and System Administrator. An actor initiates a use case and receives something of value
from the use case. Actors are always external to the system being modeled i.e. they are not parts of
the system.
One can use the following criteria to find actors: Who is using the system, who is affected by and
affects the system, what other system interact with this system, where does the system get information,
who install the system, who obtain information from this system and the like.
Based on these techniques the following actors have been identified:-

 Proctors manager: - register block and manage proctor.

 Proctor: The proctor can assign student and generate report.

 Students: The students view his/ her dormitory information online and submit comment.

 Administrator: The administrator manages the overall system.

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
 Deallocate student
 Create account
 Update account
o Activate
o Deactivate
o Delete
o Edit
 View room
 Submit comment
 View comment
 Delete comment
22
  Change password
 Register block (Assign Proctor)
 Register room
 View Student Information
 Generate report

 Logout

Use case name Use case Id Includes/Extends

Login UC01 /Logout

Create Account UC02 Login

Submit Comment UC03 Login

View dormInfo UC04 ….

view Comment UC05 Login

Manage record UC06 Login

Register block UC07 Login

Register Room UC08 Login

View student info UC09 Login

Generate Report UC10 Login

Allocate student UC11 Login

Table 4.1 Use case identification

23
Constructing Use case Diagrams

Figure 4-1 Use case diagram

24
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 i.e.to 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:
25
 Actor Action:

Step1: The administrator log to his/her page.

Step2: The administrator click on User Account link.

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:

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

27
  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 and admin.
Precondition: The actors must have a full privilege to read the comments.
Flow of action:
Actor action:

Step1: Actors log to his/her page.

Step2: Actors click on view comment link.

Step4: Actors starts to view the comments.

System response:

Step3: The system reorders the comments according to the time of delivery

Step5: Use case ends

Post condition: The Actor 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.
28
 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 i.e.to 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.
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.

29
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 i.e.to 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.

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 i.e.to fill the data again.
 Use case ends.

30
Use Case Name: View Student Info
Use case Id: UC09
Description: the user can view the detail information about the dorm as well as the student.
Actors: Proctor manager, proctor and students.
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:
Actor action:
Step1: The user must log to his/her page
Step2: The user select generate report link

31
 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

 Go to step4

32
 4.2. Object Model
An object model is a logical interface, software or system that is modeled through the use of object-
oriented techniques. It enables the creation of an architectural software or system model prior to
development or programming [8].
4.2.1. Class Diagram

A class diagram is the building block of the system that we are going to develop that shows the objects
the system is comprised of and how they are interrelated. It represents a detailed view of a single use
case and the classes that participate in the use case. Class diagram contains attributes and operations
[8]. The following are components that are useful to model a class diagram.

 Classes: has members and method that operates or performs the behavior of objects.
 Responsibilities: - A responsibility is anything that a class knows or does.
 Associations: -Associations are modeled as lines connecting use cases and actors to one

33
Figure 4-2 Class diagram

34
 4.2.2. Data Dictionary
A data dictionary is a collection of data definitions used by applications to describe and access a
database. As described in the system it comprises a number of tables which are stored in MYSQL
server [4].
Table name Block
Description Store Building Block information
Field name Data type Size Constraint Description of stored data
Block_id Varchar 20 Primary key Used to hold block id
Rooms Int 5 Not null Used to hold number of rooms on each
block
Proctor_ID Varchar 20 Foreign key Hold ID of proctor assigned to block
Phone_number Varchar 20 Not null Proctors contact number
Table 4.2 Data dictionary for Block

Table name User account

Description Store user account information
Field name Data type Size Constraint Description of stored data
FName Varchar 20 Not null User first name
MName Varchar 20 Not null User middle name
LName Varchar 20 Not null User last name
User_ID Varchar 20 Primary key User id
Sex Varchar 20 Not null Gender of users
Level Int 5 Not null Types of user(admin, or, proctor manager or
proctor)
Phone_no Varchar 20 Not null Contact number of user
Username Varchar 20 Not null Username for user
Password Varchar 20 Not null Password for security of users
Create_date Date 20 Not null Users account created date
Table 4.3 Data dictionary for user account

35
 Table name Student

Description Store allocated students information

Field name Data type Size Constraint Description of stored data

FName Varchar 20 Not null Holds student first name

MName Varchar 20 Not null Holds student middle name

LName Varchar 20 Not null Holds student last name

Student_ID Varchar 20 Primary key Holds student id number

Sex Varchar 20 Not null Holds students gender

Batch Varchar 30 Not null Holds student batch

Faculty Varchar 20 Not null Holds student faculty or department

Block_no Varchar 20 Foreign key Holds block number student assigned to
Room_no Varchar 20 Foreign key Holds room number student assigned to
Phone Varchar 20 Not null Holds phone number of student
Allocate_date Date 20 Not null Holds students assigned date
Table 4.4 Data dictionary for Allocated students

Table name Comment

Description Store comments from different users

Field name Data type Size Constraint Description of stored data
User_ID Varchar 20 Not null Holds users id that sends a comment

Subject Varchar 20 Not null Holds subjects of comment

E-mail Varchar 30 Not null Holds e-mail address of sender

Message Varchar 500 Not null Holds messages commented

Table 4.5 Data dictionary for comments of different user

36
 Table name Room

Description Store room information

Field name Data type Size Constraint Description of stored data

Block_no Varchar 30 Not null Holds block id, to which room belongs

Room_no varchar 30 Not null Holds room number

Faculty varchar 20 Not null Holds faculty of students to be assigned

Batch varchar 20 Not null Holds batch of students to be assigned

Capacity Int 5 Not null Holds maximum number of students allocated to

it
Figure 4-3 Data dictionary for room

4.3. Dynamic Model

4.3.1. Sequence Diagram
Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and
the messages they pass. The diagrams are read left to right and descending. Sequence diagram
describe the flow of messages, events, actions between objects, show concurrent processes and
activations, show time sequences that are not easily depicted in other diagrams, and typically used
during analysis and design to document and understand the logical flow of your system [6].

37
Figure 4-4 sequence diagram for login

38
Figure 4-5 Sequence diagram for Delete user account

39
Figure 4-6 Sequence diagram for Generating report

40
Figure 4-7 sequence diagram for create user account

41
Figure 4-8 Sequence diagram for update user account

42
Figure 4-9 Sequence diagram for register block

43
Figure 4-10 sequence diagram for allocate dorm

44
Figure 4-11 Sequence diagram for Student view dorm

45
Figure 4-12 Sequence diagram for View student information

46
Figure 4-13 sequence diagram for change user password

47
 4.3.2. Activity Diagram
Activity diagrams are used to Document the logic of a single operation /methods, a single use case,
or the flow of logic of a business operation. In many ways, Activity Diagrams are the object_ oriented
Equivalent of flow charts and Data Flow Diagrams (DFD) from Structure [6]. Activity diagrams are
used to show how different work flows in the system are constructed, how they start and the possibly
many decision paths that can be taken from start to finish. They may also illustrate the where parallel
processing may occur in the execution of some activities.

48
Figure 4-14 Activity diagram for login

49
Figure 4-15 Activity diagram for Create user account

50
Figure 4-16 Activity diagram for registering block

51
Figure 4-17 Activity diagram for allocate dorm

52
Figure 4-18 Activity diagram for view dorm

53
Figure 4-19 Activity diagram for view student info

54
Figure 4-20 Activity diagram for forget password

55
 4.3.3. State Chart Diagram
A state chart diagram is a view of a state machine that models the changing behavior of a state. State
chart diagrams show the various states that an object goes through, as well as the events that cause a
transition from one state to another [6] [6].
The common model elements that state chart diagrams contain are:

 States

 Start and end states

 Transitions
A state represents a condition during the life of an object during which it satisfies some condition or
waits for some event. Start and end states represent the beginning or ending of a process.

Figure 4-21 state chart diagram for login

56
Figure 4-22 state diagram for view dorm info

57
Figure 4-23 state chart diagram for register block

58
Figure 4-24 state chart diagram for generate report

59
Figure 4-25 state chart diagram for allocate dorm

60
 CHAPTER FIVE
5. SYSTEM DESIGN
System design is the transformation of the analysis model into a system design model. Up to now we
were in the problem domain. System design is the first part to get into the solution domain in a
software development [9] [10]. This chapter focuses on transforming the analysis model into the
design model that takes into account the non-functional requirements and constraints described in the
problem statement and requirement analysis sections discussed earlier.
The purpose of designing is to show the direction how the system is built and to obtain clear and
enough information needed to drive the actual implementation of the system. It is based on
understanding of the model the software built on.

5.1. Design Goals

The purpose of designing is to show the direction how the web page is built and to obtain clear and
enough information needed to drive the actual implementation of web page. It is based on
understanding of the model the web page built on system design also focuses on decomposing the
system in to manageable parts [8] [11]. The design goals are derived from non-functional requirements
that means non-functional requirement is the description of the feature characteristics and attribute of
the system as well as any constraints that may limit the boundary of the proposed solution [10].
The goal of the system design is to manage complexity by dividing the system in to manageable
pieces. Some of the goals are listed below:

 Performance: The system should respond fast with high throughput, i.e. it should perform
the task quickly possible as possible such as allocating students and proctors, viewing
student and dormitory information etc. Furthermore, the system should not be taking up too
much space in memory.
 Reliability: system should be reliable.
 Fault Tolerance: system should be fault tolerant to loss of connectivity with the service.
 Maintenance: The system should be easily extensible to add new functionalities at a later
stage. It should also be easily modifiable to make changes to the features and functionalities.
 Usability: From the end users’ perspective the system should be designed in such a way
that it is easy to learn and use, efficient and having few errors if any.
 Efficiency: The system must do what it is supposed to do efficiently without the problem.

61
  Security: The system should be secured from unauthorized user.
 Cost: The system should be developed with minimum cost possible. In reality there is
always trade-offs or disadvantages and therefore from its previous experience the
University prefers to invest more on development cost than maintenance cost to minimize
bugs which may appear at the later stage.
 End User Criteria: - The system should have simple and understandable graphical user
Interface such as forms and buttons, which have descriptive names. It should give reliable
response for each user request at least before the session expires. All the interfaces, forms
and buttons are written or designed in a simple language or common language so that the
user can access it without any difficult.

5.2. Proposed System Architecture

Proposed system uses the following client server or three tier architecture which comprise of:

 Browser: These include Mozilla Firefox, Google Chrome, Opera Mini, Internet Explorer, and
some others browsers. These are used to run the system in the computer system.
 Web server: It is the heart of system. It has a lot of responsibilities to perform like to
communicate with clients and database. Since the system is network-connected, it uses HTTPs
to send and receive data. HTTPs Protocol used for communication between two
devices/machines over the network to interact with each other.
 MYSQL Database: Is the database software deals with the storing and managing the data
based on the request from the web server. It will write new records to the storage and will
retrieve and deliver to the web server when needed. MySQL is one of the most popular
database technologies in the world. Known for being secure and scalable, it is the go-to
solution for businesses of all sizes.

62
Figure 5-1 Proposed system architecture

5.2.1. Subsystem Decomposition and Description

Subsystem decompositions will help reduce the complexity of the system. The sub systems that we
take the classes that our systems contain and the operation performed in the class. The following are
sub systems based on functional requirements of our system:
I. User Account Sub-system
 Create account
 Update account
 Activate account
 Deactivate account
 Delete account
II. Report Sub-system
 Generate report
 Print report

63
 III. Register sub-system
 Register block
 Register room
 Allocate room
 Deallocate room
 Assign proctor
IV. Comment and information sub-system
 Send comment
 View Comment
 View dorm
 View student information

Figure 5-2 Subsystem decomposition

64
 5.2.2. Hardware/Software Mapping
Component Diagram
In the unified modeling language, a component diagram depicts how components are wired
together to form large components or software systems. They are used to illustrate the structure of
arbitrarily complex systems [6].

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.

Figure 5-3 component diagram

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.

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

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.

Figure 5-4 Deployment diagram

5.2.3. Detailed Class Diagram

Detailed Class Diagram A class diagram gives an over view of a system by shows its class and the
relationship among them. Class diagram are static they display what they do interact. In class
Diagram class is represented as a rectangle, where three compartments, the first compartment
depicts the class name, the second depict its attribute of class and the third represent its operations
[6] [4]. The Form Diagram allows you to generate diagram automatically with user-defined scope.

66
Figure 5-5 Detailed class diagram
67
 5.2.4. Persistent Data Management
Persistence modeling is used to communicate the design of the database, usually the data base to both
the users and the developers. It is also used to describe the persistence data aspect of the system. The
Persistent data is a data that must be stored in the database for future use with their data type and their
domain [6] [13].

Figure 5-6 Persistent diagram

68
 5.2.5. Access Control and Security

Access control and security describes the user model of the system in terms of an access matrix. This
section also describes security issues, such as the selection of an authentication mechanism, the use
of encryption, and the management of keys [6].
In the systems, different actors have access to different functionality and data. Define the access
controls for your system.
Access control rules

 Privilege: every user of the system is privileged for some specific tasks. A user privileged to
access some data is allowed only to access the data that he/she have privileged to access. When
a user try to access the data that he/she haven’t allowed to access the system must ignore that
unauthorized user. Generally privilege is the assignment of the right authority to the right
person. The privilege is given based on the user type.

 Authentication: identifying an individual who is trying to access the accounts secure data
and relevant information. The authentication process is based on username and password of
the user. When a user tries to login to the system the system asks for his username and
password. Then match the username and password he/she enter to login with the username
and password of his/her own account. If it doesn’t match the system reject the user to login to
the system. If it matches then the user is allowed to login.

69
 Function User/Actor

Access Administrator Proctor Manager Proctor Student

Login Yes Yes Yes Yes

Logout Yes Yes Yes Yes
Create User Account Yes No No No
Activate account Yes No No No
Deactivate account Yes No No No
Update account Yes No No No
Delete account Yes No No No
Register room No No Yes No
Allocate dorm No No Yes No

Deallocate dorm No No Yes No

Send Comment No No Yes Yes

View comment No Yes No No
Register Block No Yes No No
View student info Yes Yes Yes Yes
View dorm No Yes Yes Yes
Reset password Yes Yes Yes Yes
Generate report No Yes Yes No
Table 5.1 Access privileges for users

70
 5.3. Packages
Package is a grouping mechanism for organizing elements into groups to increase their readability. In
other words, it is a grouping of model elements, such as use cases, or activities, defining scopes of
understanding. Packages are used to deal with complexity in the same way a user organizes files and
subdirectories into directories [6] [8].
Our DMS comprises one main package DMS which in turn has three sub packages. Each subsystem
is depicted as a package.
1. User interface package
User interface package includes the following subsystem:
 User management subsystem
 Report subsystem
 Register Subsystem
 Comment and information subsystem
2. Database Package

This package mainly provides persistent data storage and management facilities to
store, modify and extract information from the database. Request for information
from this database are made in the form of a query.

3. Webserver package

 Connection Management: Responsible for creating a connection and allow to

communicate clients with the server.
 Request Management: Responsible for categorizing clients request accordingly
and send to processing
 Function Processing Management: Receives a request from request
management and processes it depending on the kind of the request and respond.

71
Figure 5-7 Package diagram

5.4. User Interface Design

The goal of user interface design is to make the user's interaction as simple and efficient as possible
in terms of accomplishing user goals [8]. Good user interface design facilitates finishing the task at
hand without drawing unnecessary attention to it. Our Systems main user interfaces includes the
following features:

72
Figure 5-8 Interface design of homepage

73
Figure 5-9 User Interface design for login

74
 References

[1] A. university, "Arsi university official website," [Online]. Available: https://www.arsiun.edu.et/about

Arsi university. [Accessed 03 march 2022].
[2] W.-K. &. Loucopoulos, Business Rules and Information Systems:Aligning IT with Business Goals,
2004.
[3] M. L. P. &. T. A. Saunders, Research methods for business studies., UK: Pearson Education Limited,
2003.
[4] Tutorialspoint, "Tutorialspoint," 2006. [Online]. Available:
https://www.tutorialspoint.com/object_oriented_analysis_design/ooad_object_oriented_paradigm.htm.
[Accessed 03 03 2022].
[5] Z. Huijin, in Management system requirement design of college student Dormitory, (2015).
[6] J. Keyes, Software Engineering hand book, Washington DC: A CRC Press company, 2006.
[7] C. J. .. Shu Pan, "Design and implementation of dormitory in digital campus construction [J].," in
Journal of Wuhan Institute of Technology, , (2008), pp. no. 4, pp.108-11.
[8] "Information and Software Technology," in A framework for analysis and design of software reference
architectures, 2012, pp. 54(4):417-431.
[9] "researchget," 05 feb 2010. [Online]. Available:
https://www.researchgate.net/post/What_is_difference_between_analysis_and_design_of_software.
[Accessed 02 03 2022].
[10] "Goals and Objectives of Systems Analysis and Design," Computer science, vol. III, pp. 55-30, 11th
Aug 2017.
[11] E. Dijkstra, "The structure of the T.H.E Multiprogramming system,," 2016, pp. 18(8), pp. 453-457,.
[12] Tutorialspoint, "Tutorialspoint," 2006. [Online]. Available:
https://www.tutorialspoint.com/uml/uml_deployment_diagramvscomponent_diagram.htm. [Accessed
05 03 2022].
[13] S. W. Ambler, "Object/Component Architecture & Modeling," canada, 2015.
[14] "Tutorialspoint," tutorialspoit, 2006. [Online]. Available:
https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm. [Accessed 05 03 2022].
[15] "Tutorialspoint," 05 03 2006. [Online]. Available:
https://www.tutorialspoint.com/software_engineering/software_analysis_design_tools.htm. [Accessed
03 02 2022].
[16] "Geeks for geek," GeeksForGeeks, 12 10 2010. [Online]. Available:
https://www.geeksforgeeks.org/algorithms-design-techniques/. [Accessed 05 03 2022].

75
 Appendix
Sample interview questions

1. How is current dormitory system of Arsi University flow section works?

2. What activities held in the current system?

3. How can you assign students to dorm?

4. What business rules are available in current system?

5. Have you apply your business rule while doing you tasks?

6. How can you assign or consider students that have disability?

7. How can you store and manage information and data’s of students?

8. Do you think you have benefitted from services of current dormitory system?

9. What documents are available in current system and for what purpose you used it?

10. Have you faced problems during your activities? If yes, what problems have you faced and
how you overcame it?

11. Whom are involved and what role they have in the current system?

12. Have you ever heard about web based computerized system? If so, what information do you
have about it?

13. What do you think if current system changed to computerized?

76