WOLDIA UNIVERSITY

FACULTY OF TECHNOLOGY
DEPARTMENT OF SOFTWARE ENGINEERING
Couse title:-FUNDAMENTAL SOFTWARE ENGINEERING
Project title:-Dormitory Allocation Management System
Course code:-eng2051
No. Name ID
1. YEABSIRA
ASSEGID………………………………………………………..1303042
2. BEMNET SOLOMON……………………………………………………………
1300507
3. GETAHUN
TAMRAT…………………………………………………………..1301373
4. ABENEZER Tariku………………………………………………………….1300134
5. Ashenafi minaye ………………………………………………………….1300403
6. Yohannes alemayehu…………………………………………………..1303096
7. aklilu mengesha……………………………………………………………
1300244
8. natinael asefa……………………………………………………………..1302348
9. hailegiorgies abate…………………………………………………….1306337
10. yosef zewdu……………………………………………………………………
1303146

WDU
 Submitted to Mezgebu
Submission date March/07/2023
Table contents

Contents page

CHAPTER 1
1. Introduction……………………………………………………………………………....4
1.1 organization background……………………………………………………………..5
1.2 statement of the problem……………………………………………………………..5
1.3 objective of the project……………………………………………………………….6
1.4 Significance of the project…………………………………………………………....6
1.5 Beneficiary of the new system……………………………………………………….7
1.6 Scope and limitation of the project…………………………………………………..7
1.7 Feasibility study of the new system………………………………………………….8
1.8 Methodology ……………………………………………………………………….10
1.9 Time and cost schedule…………………………………………………………......12
1.10 Project team organization………………………………………………………..14
1.11 Risk assumption …………………………………………………………………15

CHAPTER 2
2. description of the existing system……………………………………………………...15
2.1 Introduction…………………………………………………………………………15
2.2 description of the existing system……………………………………………….….15
2.3 major function of the existing system………………………………………………16
2.4 player of the existing system……………………………………………………….16
2.5 work flows in existing system………………………………………………………17
2.6 report gathering in existing system…………………………………………………17
2.7 Business rule in existing system ……………………………………………………18

2|Page
 2.8 Paper document in existing system…………………………………………………18
2.9 Problem in existing system………………………………………………………….19
2.10 Practice to be preserved from existing system…………………………………...20
2.11 Alternative solution………………………………………………………………20
2.12 The proposed system……………………………………………………………..20
CHAPTER 3
3. Analysis Deliverable Of The New System……………………………………………...22
3.1 introduction……………………………………………………………………..22
3.2 use case diagram………………………………………………………………...22
3.3 subsystem decomposition……………………………………………………….34
3.4 analysis level of class diagram……………………………………………….....33
3.5 sequence diagram……………………………………………………………….35
3.6 activity diagram……………………………………………………………..…..42
CHAPTER 4
4. Design Deliverable Of The New System……………………………………………….47
4.1 introduction…………………………………………………………………………47
4.2 design the class diagram………………………………………………………….....48
4.3 database design……………………………………………………………………...50
CHAPTER 5
5. Implementation Deliverable Of The New System ………………………..51

5.1introduction…………………………………………………………….51
5.2 Component diagram…………………………………………………....51

5.3 Deployment diagram…………………………………………………...53

5.4 User interface ………………………………………………………….55

CHAPTER 6
6.1Conclusion…………………………………………………………….56
6.2 Recommendation……………………………………………………..57
6.3Appendix……………………………………………………………...57

3|Page
 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.
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.
Hence, developing the system using technology has a tremendous effect for organizations
and offices; which is in our case the oldia University Online dormitory management system
(WDUOMS). 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.

4|Page
 1.1 Organizational background
Woldia university was established through the council of ministers Regulation No 223/2011
issued on may 26,2011.

Corner stone for construction activities of the university was laid on Oct ,26,2008 by his
Excellency Ato Ayalew Gobezy , former president of the Amhara Regional state , and his
excellency Dr. Adhana Haile , former deputy state minister of education

Currently, the total area of the university is 196 hectares of land. Woldia university has two
campuses, namely ,the main campus called Woldia university and the other one is mersa campus
of Agriculture. It is 25 kms far from the main campus.

The first batch of students, numbering 599, has been admitted to the university on Dec 10/2011
in fabulous reception ceremony involving invited guests city residents, representatives of
different zone & Woreda administrative offices and university’s community . students have been
placed in to four faculties and 12 departments.

In its second year of operation ,the university admitted over 1457 New students . The number of
faculties grew in to six ,the two newly added being the faculty of Agriculture and pedagogic al
and behavioral science faculty . Like wise , the number of departments doubled in to 24.
Currently, the university has a student population of over 10,000.

The university is anticipated to contain a student population of 15,000 over a period of five
years. More than 200 blocks are planned to be erected in different phases with in the specified
period.
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

5|Page
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.

1.2 Statement of the problem

Currently, WDU 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,
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.3 Objective of the project

1.3.1General Objectives
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. This is achieved
by designing a web based application program that will change the actual manual processing into
a computerized environment.

1.3.2Specific Objectives
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 minimize the work load of the employees (proctors).

6|Page
  To assign the dorm to the students without any fault.

1.4 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 aspects.
 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.5 Beneficiaries of the new system

The beneficiaries of the system are:
 Students: the students can view their dormitory information easily and timely.
 Proctors and other administrative officials: they can access dormitory and related
information easily.
 University: the university gets better audience.

1.6 Scope and limitations of the project

1.6.1 Scope of the project

Since WDU 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.

7|Page
  Manage dormitory related information.
1.6.2 Limitations of the project
 It’s difficult to know students information and give clearance while they are living the
campus.
 Failure of electric power and network connection

1.7. Feasibility Study of the new System

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

1.7.2 Technical Feasibility

The system to be developed by using technologically system development techniques such as
PHP, Java script, css and database without any problems and the group members have enough
capability to develop the project. So the system will be technically feasible.
1.7.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.

8|Page
 Generally the system that we developed, WDUODMS brought a number of tangible and
intangible benefits.
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:
1. Cost Reduction: - To calculate these following things will be considered.
Total Number of proctors in existing system= 35
Average Salary of each proctor per month = 1250.00Birr
Total money required for payment per year= 35*1250*12= 525,000Birr
Average Number of proctors needed when the new system is deployed= 30
Average salary of each of them per month = 1250.00Birr
Total money required for payment per year= 30*1250*12= 450,000.00Birr
Difference b/n before and after deployment money required for payment
Cost Reduction and Avoidance= 525,000Birr -450,000.00Birr
= 75,000.00Birr

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

Especially in allocation:-
Average Days required for allocation= 15 days
Average proctor salary per day=41.61birr
Average Days required for allocation in terms of money=35*41.61*15= 21,845.25Birr
Average days required for the system= 3 day
Average Days required for allocation in terms of money=30*41.61*3= 3744.90Birr
Difference = 21,845.25Birr-3744.90Birr=18,100.35 Birr
Intangible benefits:
1. Reduce Resource Consumption
2. Increase security
3. Increase Management flexibility

9|Page
 1.7.4 Political feasibility
The system to be developed is not conflict with any government directives, because it gives
services for the people effectively and efficiently, all the stakeholders also agreed before the
system developed. So the government is profitable and the system will be politically feasible.

1.8 Methodology
1.8.1 data gathering
The data collection instruments used to gather accurate information about the existing system
and the requirements for the new system. Interviews and questionnaires were administered to
Stakeholders like Students, Proctors and Dormitory management officer to collect user
requirements. Observation of the current existing system was done at the Dormitory management
office 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 has used the following data collection techniques.
Those are: -
A. 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.
B. Direct 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.
C. Questionnaires: since proctors as well as higher officials of proctors have work load they
cannot able to answer/give information what we ask. So we prepare some sample
questions to get précised information.

10 | P a g e
 D. Existing document: 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.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. 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.8.3 Tools used in the project

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

Documentation MS word 2007,2010

Design Rational Rose, Microsoft Visio 2007,Visual

paradigm for UML standard design

Editing Paint, Macro media flash

8,Adobe.Photoshop.CS4

11 | P a g e
 Script languages PHP, JavaScript, CSS, HTML

Web server Apache Xamp server

Data base Server Database

Table 1.1 Tools used in the project

1.9 Time and cost schedule

1.9.1 Time schedule
Time

Feb-10
Jan-23

Feb-11
Feb-20

Feb-21
Activities
Jan-10

Jan-11

Mar-6
Jan -3
Jan-1

Project Proposal

Requirement Analysis

Design

Implementation & Coding

Testing
project Defense

Table 1.2 Time schedule

1.9.2 Cost schedule

12 | P a g e
 1.9.2.1 Hardware cost

No Material Amount Price per unit Total price

1 A4 size paper 2 Destin 100 Birr 200Birr

2 Pen 7 4 Birr 28Birr

3 Flash disk 2 240 Birr 480Birr

4. For Print 100 sheet 1 Birr 100Birr

5 CD 6 8 Birr 48 Birr

6 Dell computer 1 12,500 Birr 12,500 Birr

Total 13,356.00 birr

Table 1.3 Hardware cost in the project

1.9.2.2 Software cost

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

Table 1.4 Software cost in the project

13 | P a g e
 1.10 Project Team Organization
Woldia University Online Dormitory Management System

S.No Name ID NO. Email Address Responsibilities

-V/group Coordinator

1. Abenezer Tariku WDU1300134 [email protected] -Testing

Aklilu mengesha WDU1300244 - -Data gathering

2. Bennet Solomon WDU1300507 -

Getahun Tamirat WDU1301373 - -Data gathering

3. Yohannes alemyhu WDU1303096 [email protected] -Designer

4. Ashenafi minaye WDU130030 - -Designer

5. Nathnael asefa WDU1302348 - -Data gathering

Yosef zewdu WDU1303146 -Designer

Hilegiorgis abate WDU1306337 -Group coordinator

6. Yeabsra Assegid WDU1303042 [email protected] -Documentation

-Implementation

Project Advisor: Instructor Mezgebu

14 | P a g e
 Table 1.5 Project Team composition

1.11 Risk Assumption

During the development of the project there may be different problems that we may face. These
are:
 Time management problem: but we solve this problem by working cooperatively, divide
our time by schedule for each phase of the project and we try to use this schedule effectively
 The employees (proctors) of the student residence may not be voluntary to give detail
information about their operations. To solve this problem we try to ask any thing politely
and tell reason why we ask them.
 Failure of electric power and internet connectivity- we try to solve this by taking back up to
external storage devices.

CHAPTER TWO
DESCRIPTION OF THE EXISTING SYSTEM

2.1 Introduction
This chapter describes the existing system, players in the existing system general work flow of
WDU 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 Description of existing system

The current system of WDU 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
WDU Registrar office and allocate Students depending on department and the lists of the

15 | P a g e
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.3 Major functions of 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.
 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. Player 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,

16 | P a g e
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.5 Work flows in the existing system

To overcome or improve this manual (partial) operation the team comes up with a new
Dormitory Management System entitled WDUODMS. This new system is a Web based
application that enables the users to access the services given by the system through the Internet.
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.

2.6 Report generating in the 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

17 | P a g e
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.
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.7 Business Rules in 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
(Ambler, 2001).
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.

2.8 Paper document in the 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:

18 | P a g e
 2.9 Problems in 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 dormitory. The system manipulates and manages all of these and other
records manually on papers.

19 | P a g e
 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.10 Practices to be preserved from existing system

Even if the existing system is manual system as it has weakness it also has some strong side that
we need to be preserved are:

 Provide the required infrastructure to the students.

 Protecting dormitory resources.
 Posting dormitory information in each building.
 Generation timely report.
 Assessing discipline cases.

2.11 Alternative solutions

In order to overcome the current system problems that exist in the functioning of WDUDMS, our
project team members have put down alternative options. These are:
 Change manual system in to computerized system (online) without affecting the structure
of the existing system.
 Fetching records from excel sheet (.CSV)

2.12 The proposed system

20 | P a g e
 2.12.1. Functional requirement
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.

2.12.2 Non-functional requirement

i. 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 WDUODMS 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.
ii. Quality Issue
Information in database should be as much as possible correct and updated in each semester.
iii. 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.
iv. 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.

21 | P a g e
v. 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.

CHAPTER THREE
ANALYSIS DELIVERABLES OF THE NEW SYSTEM
3.1 Introduction
As we mentioned in the above section, in this project, the team members used an object
oriented system development methodology which incorporates two principal phases. In this
chapter, what the team will do is the object oriented analysis (OOA).

During Object Oriented Analysis the major activity is:

 Modeling the Functions of the system (Use Case Modeling)
The main activities that are performed in this part will be:
 Identifying if there is any additional actors and use cases,
 Constructing a use case model, and
 Documenting the use case course of events.
3.2 Use case diagram
Use Case represents interaction between a user (human or machine) and the system.
Use case components:

22 | P a g e
  Actor: is a person, or external system that plays a role in one or more interaction with the
system. And represented with:

 Use case: describes a sequence of actions that provides something of measurable value to
an actor and is drawn as a horizontal ellipse.

 System boundary: indicates the scope of the system project. Anything within the box
represent functionalities in side in scope.
System

3.2.1 Actor identification

In the use cases an actor interact 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

23 | P a g e
 Submit comment
 View comment
 Register block (Allocate Proctor)
 Register room
 View Student Info
 Generate report

24 | P a g e
25 | P a g e
 Fig 3.1 Use case diagram for the proposed system
3.2.3 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.

26 | P a g e
Flow of action:
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:
Step3: The system displays the form.
Step5: The system validates the entered information.
Step6: The system display as your comments has been sent

27 | P a g e
 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 Dorm Info

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

28 | P a g e
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.
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 i.e.to fill the data again.

29 | P a g e
  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.
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.

30 | P a g e
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.

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

31 | P a g e
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
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
Descr iption: Assign students in their room.
Actor: Proctor

32 | P a g e
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

3.3 Subsystem Decomposition

To reduce the complexity of the solution domain, we decompose a system into simpler parts,
called subsystems, which are made of a number of solution domain classes. In the case of
complex subsystems, we recursively apply this principle and decompose a sub- system into
simpler subsystems. Decomposition Results large systems in to a set of loosely dependent parts
which make up the system. The main need of this portion is to design the external part of the
system. Sub-System Decomposition is the way that helps us to distinguish the part of the
operations that takes place under the organization.

In this project, there are five sub system decompositions. These are:

1. Assignation Subsystem
 Assign Student
2. Report Subsystem
 Assignation report
 Block and Room report
 Comment report
3. Comment and Information Subsystem
33 | P a g e
  Give comment and Message of current issues (may be for the system).
 View student dorm information
4. Fetch record
 Fetch record from centralized database
5. User Account Subsystem
 Create Account
 Remove Account

3.4 Analysis level of Class diagram

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.

34 | P a g e
 User
Fname
Mname
Lname
User_id
Sex
Role
Phone_no
Username
Password

Submit_Comment()
Generate_Report() Block
Allocate_Student() Block_No.
View_StudentInfo() Capacity
Register_Room() Proctor_Fullname
Student
Fname * Store()
Mname
Lname * 1
Stud_Id Comment
Faculty
Sex
* * Name
Email
Batch Comment
Block_No.
Room_No.

View_DormInfo()
Submit_Comment()
Room
* Block_No.
1 Room_No. *
Capacity

Store()

Fig 3.2 Analysis level of Class Diagram

35 | P a g e
 3.5 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.

36 | P a g e
Sequence
Diagram For
Login Use Case Home Page Login Link Login Form Validator Database
: User

1.User Visit home page ()

User Action:
(Admin,student,proct
2.Select Login Link()
or and proctor
Manager)
1.User initiate to login
2.Select the login link
4.Fill usename and 3.Display The Login Form()
password and submit
System Response: 4.Fill The Username and Password()
3.Display the login
form.
5.Validate username
and password. 5.Submit()
6.Display the 6.Validate()
appropriate page, if
not display the error 7.Try again()
message
8.Continue()
9.Check()

10.Display The Target Page()

Fig 3.3 Sequence diagram for login

37 | P a g e
Sequence
Diagram for View
Dorm Use case View DormInfo View DormInfo Validator Database
: Student
Link Form
User(Student)
Action: 1.Select View Dorm link()
1.Select view
Dorm link.
3.Fill his or her 2.Display the form()
identification
number or
registration 3.Fill Student Id or Registration number()
number.
System
Response: 4.Submit()
2.The system 5.Validate()
displays the
form.
4.The system
6.Retype()
validate the
entered data. 7.Continue()
5.If the 8.Check()
identification or
registration
number is exist
display the dorm
information, if
not display 9.Display dorm information()
as"The number
is not exist".

Fig 3.4 Sequence diagram for View Dorm Info

38 | P a g e
Fig 3.5 Sequence diagram for Register block

39 | P a g e
Sequence
Diagram For Administrator User Account Create Account Create Account Controller Database
: Administrator
Create Account Page Link Form Link
Use case
1.Login to admin page()
User
(Administrator)
Action: 2.Select link()
1.User Login to 3.Select the link()
admin page.
2.Select user
account link. 4.Display the account form()
3.select create
account link. 5.Fill the form()
5.Fill the account
form
System Response: 6.Create Account()
4.Display the 7.Validate()
account form.
6.Validate the
entered data.
7.Display response 8.Try again()

9.Continue()
10.Check()

11.Display Response()

Fig 3.6 Sequence diagram for Create account

40 | P a g e
Sequence
Diagram for AdminPage Search Link Search Form Search Database
search record : Administrator
Validator
1.Log to the page()
User(Proctor
Manager) 2.Select the link()
Action:
1.Log to the
proctor 3.Display the Search Form()
manager.
2.Select the 4.Fill the form()
link.
4.Fill the search
form. 5.Submit()
System 6.Validate()
Response:
3.Display the
search form.
5.Validate the 7.Try again()
input data.
6.If the input 8.Continue()
data is exist in 9.Check()
the database
diplay the result
if not Display as
Doesn't exist
10.Display Response()

Fig 3.8 Sequence diagram for Search Record

41 | P a g e
Sequence
Diagram for Admin Update Update Update Database
: Administrator
Upda... Page Record Link Record Form Validator

User(Proctor 1.Log to the page()

Manager)
Action:
1.Log to the 2.Select the link()
proctor
manager.
2.Select the 3.Display update record form()
link.
4.Fill the 4.Fill the update record form()
Update form.
System
Response: 5.Submit()
3.Display the 6.Validate()
Update form.
5.Validate the
input data.
6.If the input 7.Try again()
data is correct 8.Continue()
check and 9.Check()
save it if not
display
message as
Try again
10.Try again()

11.Save Changes()

Fig 3.9 Sequence diagram for Update Record

42 | P a g e
 3.6 Activity diagram

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

The purposes of activity diagram can be described as:

 Draw the activity flow of a system.

 Describe the sequence from one activity to another.
 Describe the parallel, branched and concurrent flow of the system.

User(Administrator,Proctor Manager,Proctor)

Enter Username And

Password

Incorrect

Correct Display Available

Validate Page

Fig 3.12 Activity diagram for Login

43 | P a g e
Fig 3.13 Activity diagram for View Dorm Info

Fig 3.14 Activity diagram for Search Record

44 | P a g e
 Administrator

Log Admin Page

Select Update
Record Link

Fill the Update form

Invalid

Save Changes
Valid
Validate

Fig 3.15 Activity diagram for Update Record

45 | P a g e
 Proctor,Proctor Manager

Log to the
page

Select the
report link

Fill the report

fields

No

Yes Display
Found?
Response

Fig 3.16 Activity diagram for Generate Report

46 | P a g e
 CHAPTER FOUR

DESIGN DELIVERABLES OF THE NEW SYSTEM

4.1 Introduction

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. 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. The objectives of design are to model the
system with high quality. Implementing of high quality system depend on the nature of design
created by the designer. If one wants to change to the system after it has been put in to operation
depends on the quality of the system design. So if the system is design effetely, it will be easy to
make changes to it.

4.1.1 Design goals and objectives

The objectives of design are to model the system with high quality. 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.

Design goals describe the qualities of the system that the developers should consider.

 Reliability: WDUODMS system should be reliable.

 Fault Tolerance: WDUODMS system should be fault tolerant to loss of connectivity with
the service.
 Security: WDUODMS system should be secured, i.e., not allow other users or unauthorized
users to access data that has no the right to access it.

47 | P a g e
 Modifiability: WDUODMS system should be modifiable for further modification and
enhancement of the application.
 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.
 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.
4.2 Design the class diagram

The class diagram is a static diagram. It represents the static view of an application. Class
diagram is not only used for visualizing, describing and documenting different aspects of a
system but also for constructing executable code of the software application.

The class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. The classes diagrams are widely used in the modeling of object oriented
systems because they are the only UML diagrams which can be mapped directly with object
oriented languages.

The class diagram shows a collection of classes, interfaces, associations, collaborations and
constraints. It is also known as a structure

48 | P a g e
 User
Fname : Varchar(30)
Mname : Varchar(30)
Lname : Varchar(30)
User_id : Varchar(30)
Sex : Varchar(8)
Role : Varchar(15)
Phone_no : Varchar(13)
1 Controlls
Username : Varchar(20)
Password : Varchar(20) Block
*
Block_No. : Varchar(3)
Submit_Comment()
Reserved : Varchar(8)
Generate_Report()
Capacity : Varchar(2)
Allocate_Student()
User_Id : Varchar(15)
View_StudentInfo()
Sex_Category : Varchar(8)
Register_Room() inherits
Student Proctor_name : Varchar(30)
Fname : Varchar(30) *submit Sex : Varchar(8)
Phone : Varchar(13)
Mname : Varchar(30)
Lname : Varchar(30) * Store()
1
Stud_id : Varchar(12) Comment
inherits
Sex : Varchar(8) * *
Name : Varchar(25) *
Batch : Varchar(10) * submit
Email : Varchar(30)
Faculty : Varchar(30)
Block_No : Varchar(3)
* Comment : Varchar(200)
*
Room_No : Varchar(3)
* contains

View_DormInfo()
Submit_Comment()
Room
* Block_No. : Varchar(3)
views 1 Room_No. : Varchar(2) *
nobed : Varchar(2)
1
Store()

Fig 4.1 Class Diagram Design

49 | P a g e
 4.3 Database Design

Database design is the process of producing a detailed data model of a database. This logical
data model contains all the needed logical and physical design choices and physical storage
parameters needed to generate a design in a Data Definition Language, which can then be used
to create a database. A fully attributed data model contains detailed attributes for each entity.
The term database design can be used to describe many different parts of the design of an
overall database system. Principally, and most correctly, it can be thought of as the logical
design of the base data structures used to store the data.

Fig 4.1 Data base design

50 | P a g e
 CHAPTER FIVE

IMPLEMENTATION DELIVERABLE OF THE NEW SYSTEM

5.1 Introduction

In this phase the overall procedures, activities and methods of execution during the
implementation phase of the project are included. This step takes much time when compared
with other steps of the project competence. The following subtopics are discussed in this phase.
These are component diagram, deployment diagram, and persistence diagram and user interface
prototype of the project. The source code or script of the project is included in the next part of
the project.

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

51 | P a g e
Fig 5.1 Component Diagram

52 | P a g e
 5.3 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.

53 | P a g e
Fig 5.2 Deployment Diagram

54 | P a g e
 5.4 User Interface
In this system users will communicate with it through the following user interfaces.

I. Home Page: This form contains some links which lead it to the concerned page, and if the
user has an account he/she will directly go to concerned page by entering their username and
password. In case for the students the system requires ID no.

II. Log In form:-this form found immediately following the home page. Home page appears as
the site on which the system is deployed is opened. Only proctor and proctor manager will
have their own password. Those forms appeared using password and user name will not
accessible by other persons except for those who have privilege.

III. View Dorm: This is view dorm page in this page the student he/she can view their dorm by
entering their Identification card or their registration number

IV. Create Account: this is creating account page in this page the administrator create accounts
for the user (proctor, proctor manager).

V. Assign Dorm: This is student assign page in this page after the proctor login into the login
page then after the proctor assign students accordingly assign the dorm.

55 | P a g e
 CHAPTER SIX

6.1 Conclusion

Woldia University Dormitory management System is one of the main Management system found
in the Universities Management. This system is a web based application to serve students as well
as the working group of the system in different direction. Specially:-
1) Students now made possible to know their dorm online which overcomes extra expenditure of
student’s time and resource
2) saving proctors time lost for assigning dorm for students, preparing report while student leave
from campus, etc
Through various challenging, now the team members are coming to the end of this project.
Those different challenges made possible by the cooperation of all the group members. In
developing this project all group members contributed their full capability with maximum
interest and all group members get ways toward developing a project.

6.2 Recommendation
While doing this system the team members has faced different challenges. But by the
cooperation of all the group members and the advisor the team is now able to reach to the final
result. I.e. all the group members strongly fight these challenge and take the turn to the front.

So now all the group members strongly recommend the department that for the coming students,
it has to provide them with better service than the present in better hard ware, guaranteed
software’s, giving orientations how to proceed, offering guest to provide them with more
experienced work, support morally, manually, forming good relation with students, giving
students description of each phases and so on. So that it will get what it expects from its students
and satisfy with them.

56 | P a g e
 6.3 Appendix
References
To do the system starting from the requirement analysis to the implementation the team members
were used the following materials:

Books
 Essentials of System analysis and design(in analysis and design phase)
 System analysis and Design methods(in analysis and design phase)
 A modern, modular approach to standards-compliant web design Craig Grannell Foreword
by Jon Hicks, Hicksdesign

Websites
 www.tutorialspoint.com/index.html
 www.w3schools.com/index.php
 http://www.ibm.com/developerworks/rational/library/3101.html

57 | P a g e