COLLEGES OF COMPUTING AND INFORMATICS

DEPARTMENTS OF INFORMATION SYSTEM

OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN
===============WELCOME TO==============
GROUP: FIVE
PROJECT TITLE:
WOLKITE UNIVERSITYDORMITORY MANAGEMENT
SYSTEM
SECTION: ‘A’
MEMBER ID
1. Nebyu Kelemu………………………………...CIR/139/10
2. Ermiyas Bogale……………………………….CIR/ 110 /10
3. Eyasu Ayinekulu……………………………..CIR/111/10
4. Biniam Shiferaw………………………….......CIR/096/10
5. Bayileyegne Alamir…………………………..CIR/089/10

SUBMITED TO: ESAYAS.W

SUBMITTED DATE: 22/09/2011

============================== ============================

i
Table of Contents
Acknowledgement......................................................................................................................................v
LIST OF FIGURE....................................................................................................................................vi
LIST OF TABLES..................................................................................................................................vii
LIST OF ABBREVATIONS.................................................................................................................viii
Abstract.....................................................................................................................................................ix
CHAPTER ONE........................................................................................................................................1
1. INTRODUCTION.................................................................................................................................1
1.1 Background of Dormitory management system in WKU..................................................................2
1.2Statement of the problem.....................................................................................................................3
1.3 Objective of the project.......................................................................................................................4
1.3.1General Objectives............................................................................................................................4
1.3.2 Specific Objectives............................................................................................................................4
1.4 Feasibility Study..................................................................................................................................5
1.4.1 Technical feasibility........................................................................................................................5
1.4.2 Operational feasibility....................................................................................................................5
1.4.3 Economic feasibility.......................................................................................................................5
1.4.4Schedule feasibility..........................................................................................................................5
1.4.5 Political feasibility..........................................................................................................................6
1.4.6 Legal and constraint feasibility.......................................................................................................6
1.5 Scope and limitation of the project.....................................................................................................6
1.5.1 Scope of the system........................................................................................................................6
1.5.2 Limitation of the system.................................................................................................................7
1.6.1 Benefits of the project.....................................................................................................................7
1.7 Methodology.........................................................................................................................................9
1.7.1 Data collection methodology..........................................................................................................9
1.7.2 System analyses and design methodology......................................................................................9
1.7.3 Programming development language and tool..............................................................................10
1.7.4 System development model..........................................................................................................10
1.7.4 .1 Software process model........................................................................................................10
1.8 Project plan........................................................................................................................................11
1.9 Work breakdown structure and deliverable....................................................................................11
1.10 Budget...............................................................................................................................................12

ii
CHAPTER TWO.....................................................................................................................................13
2 DESCRIPTION OF THE EXISTING SYSTEM...............................................................................13
Introduction.............................................................................................................................................13
2.1 Description of existing system...........................................................................................................13
2.2. Users of the existing system..............................................................................................................13
2.3 Major functions of existing system...................................................................................................13
2.4 Draw back of the existing system......................................................................................................14
2.5 Business Rules in the existing system...............................................................................................15
CHAPTER THREE.................................................................................................................................16
3 PROPOSED SYSTEM.........................................................................................................................16
Introduction.............................................................................................................................................16
3.1. Proposed system description............................................................................................................16
3.2 Functional requirement...............................................................................................................16
3.3 Non-functional requirement.............................................................................................................17
3.3.1 User Interface and human factors.................................................................................................17
3.3.2 Hardware consideration................................................................................................................17
3.3.3 Security Issues..............................................................................................................................17
3.3.4 Performance characteristics..........................................................................................................18
3.3.5Error Handling and validation........................................................................................................18
3.3.6 Quality Issues...............................................................................................................................18
3.3.7 Backup and recovery....................................................................................................................18
3.3.8 Physical environment....................................................................................................................18
3.3.9 Resource issues.............................................................................................................................18
3.3.10 Reliability...................................................................................................................................18
3.3.11 Accuracy.....................................................................................................................................18
3.3.12 Availability.................................................................................................................................19
3.3.13 Documentation............................................................................................................................19
4.1 System model.....................................................................................................................................20
4.1.1 Use case modeling........................................................................................................................20
4.1.1.1 Use case diagram...................................................................................................................20
Actor identification............................................................................................................................21
Use case identification.......................................................................................................................21
4.1.1.2 Use case Description..............................................................................................................22

iii
 4.1.1.3 USE CASE SCENARIO........................................................................................................25
4.2 Object Model......................................................................................................................................25
4.2.1 Class Diagram...............................................................................................................................25
4.2.2 Data dictionary.............................................................................................................................26
4.3 Dynamic model..................................................................................................................................27
4.3.1 Sequence diagram.........................................................................................................................27
4.3.2 Activity diagram...........................................................................................................................29
4.3.3 State chart diagram.......................................................................................................................30
CHAPTER FIVE.....................................................................................................................................33
5 System Design.......................................................................................................................................33
Introduction.............................................................................................................................................33
5.1 Design goals........................................................................................................................................33
5.1.1 Performance..................................................................................................................................33
5.1.2 Maintenance.................................................................................................................................33
5.1.3 End User.......................................................................................................................................34
5.3 Architecture of the proposed system................................................................................................34
5.3.1 System Decomposition and description........................................................................................34
5.3.2 Hardware/Software mapping (Deployment design)......................................................................35
5.3.3 Detailed diagram...........................................................................................................................36
5.3.4 Persistent data management..........................................................................................................37
5.3.5 Access control and security..........................................................................................................38
5.4 UML Package Diagrams....................................................................................................................39
5.5 User Interface Design........................................................................................................................42
CHAPTER SIX........................................................................................................................................45
6 CONCLUSION AND RECCOMENDATION................................................................................45
6.1 CONCLUSION..................................................................................................................................45
6.2 Recommendation...............................................................................................................................45
References.................................................................................................................................................46

iv
 Acknowledgement
First we would like to thanks Mr. ISAYAS for giving this project and giving some advice to complete this
project.

Secondly we would like to thank dormitory workers specially proctors and proctor manager for their
willingness of interview and answer for our question about the current dormitory management system
working structure.

v
 LIST OF FIGURE
Fig 1: Symbol of actor

Fig 2: Symbol of use case

Fig 3: Symbol of system boundary

Fig 4: Use case diagram for the proposed system

Fig 5: analysis level class diagram

Fig 6: Sequence diagram for login

Fig 7: Sequence diagram for View dorm Information

Fig 8: activity diagram for proctor manager, proctor and student to login

Fig 9: Activity diagram for proctor, proctor manager and student view student information

Fig 10: Activity diagram proctor manager to allocate block and proctor

Fig 11: State chart diagram for student for block registration

Fig 12: State chart diagram for submit comment

Fig 13: Deployment design of the system

Fig 14: Detailed class diagram

Fig 15: Persistence data management

Fig 16: package diagram for login

Fig 17: package diagram for organize use case

Fig 18: graphical user interface for login

Fig 19: graphical user interface for home page

Fig 20: graphical user interface for create account

vi
 LIST OF TABLES
Table 1.1: Schedule feasibility of the system

Table 1.2: work breakdown structure and deliverable

Table 1.3 shows the cost of the project

Table 1.4: Time schedule of the project

Table 1.5: data dictionary for student

Table 1.6: Data dictionary for proctor

Table 1.7: Access control

vii
LIST OF ABBREVATIONS
ABBREVATION MEANING
WKU Wolkite University
OOA Object Oriented Analysis

OOD Object Oriented Design

BR Business Rules
WKUDMS Wolkite University Dormitory Management System
UC Use Case
GPA Average Grade Point
UML Unified Modeling Language

viii
Abstract
This project is concerned with the introduction and description of the existing system dormitory
management system and also the problems of the existing system, develop new system by
concerning system analysis and system design of employee management system of wku and
concerned different types of models used to model the new system under study. Web based
dormitory management system mainly provides effective and fast data processing and
controlling of personnel. The main goal of dormitory management system is to shorten data-
processing time, to reduce errors, to improve the accuracy of input and to provide data reliability
of the personnel.

ix
 CHAPTER ONE
1. INTRODUCTION
Traditionally dormitory management system uses physical paper for documentation and other
works. We want to make management system easier and comfortable for the user dormitory
system management.

The motivation of building the project has come from digitalization of dormitory management
system which has based on physical before and the system will be digitalized using on line web
based system.

The main objective of dormitory management system is to manage the detail information of old
and new students, distributing room’s to students and managing the dormitory programs using
web system.

1
1.1 Background of Dormitory management system in WKU
Wolkite University is one of the nine newly established as third generation university
Ethiopia and which is found in southern parts of Ethiopia that is located 165 km far from Addis
Ababa at the south west direction. It was started in 2003 etc. the university is located in the
southern nation nationalities regional state in gurage zone, at Gubrie site. The university
command post was stationed at wolkite town until September 2013 but moved to the main
campus at Gubrie site.

Dormitory Management System is one of a system designed to enable the university to

manage all aspects of the dorm, efficiently, effectively and transparently. It is a system based on
the collection and analysis of basic information and the routine production of key performance
indicators that allow dormitory officers, administrators and all those who need to use dorm to
deliver services, to monitor dorm costs and performance, and to budget and plan for the future.
To perform activities, to monitor dorm systems, to deliver services to the student, the university
official mainly dormitory manager (proctor) use information. Currently the University gives
academic service, bedding, health care, dormitory and other services for the student’s .In the
University different management activities were performed. Among those the main service
which provides the university to the student is Students’ Dormitory Management can be taken as
an example. In this process there is a problem associated with the Dormitory Management. So
the project team members were initiated for this project to identify and analyze those problems
and to put possible solutions.

2
 1.2Statement of the problem
Currently, wolkite university dormitory management system uses manual approach. To process
the operation first the ministry of education sends all the information to the registrar office of
WKU and gives to the student affairs including dormitory director. After taking the list, they
assigned students to each block and room. At that time they face different problems during
performing their tasks. Working by manual system is not only affecting the management
members, but also affect student during gathering information about their system. Some of those
problems are:-
 Require more human power to assign the students:-this implies that when we assign
dorm to student more people are required but if it is computerized less man power is
needed.
 Management inflexibility:-when the proctor manages student, he/she used papers to call
student name, not used another method.
 Problems of searching free dorm: - the dormitory managers devote or consume much
amount of time by searching free dorm.
 Problem on managing the materials: - after student enters into the campus the proctor
give required material to student and record those materials manually on paper. Due to
these reason proctors consume much amount of time to check the material is either return
or not. These are too difficult to him.
 Problem of work load on workers/employees:- these problems are raised more
frequently when the student enter into the campus or leaving the campus, including
writing clearance to student, arranging student in their dorm properly, giving materials to
them and checking the material either return or not.
 Problems on generating report on student attendance:-the proctor should control
student by using attendance to know they are present in their own dorm or not during
these time the proctor go to each and every dorm to call the student and then report the
attendance to the higher manager or student dormitory manager. These way of collecting
go to every dorm is difficult to proctors.
 Problem on giving clearance:-when students return back to his/her family the proctor
write attendance for every student. The key proctors are faces problem on to deliver
command, and other issue. This way of giving clearance to the student is difficult.
 Data is stored repeatedly in different files formats – The same information is stored in
many copies repeatedly in different forms.
 Data is not secured. Due to this, some secret information is opened for unauthorized
users or agents.

3
 Economic problem: -Economic problem is mainly concerned with cost control and
profit issues. Manual handling of data is expensive as compared to automated system. In
general, cost in terms of time is very high. As the business entry increases, the existing
manual system will coasty to handle those requirements. As the number of employees to
handle the task of manual processing increases, the university will spend a lot of money
for its staff.

4
  Difficulties on arranging student for the first time: -if students are entered to the
campus their name is record on paper and put on information board, due to this much
amount of time is wasted to write their name, block and dorm.
 Problem of data redundant: -when student’s information are arranged or listed
manually, data can be recorded many times.
 Problem on response time: -when someone wants something and ask the proctor, the
proctor is delaying giving answer to the question.
 Delaying in producing different reports:-the proctor delay to report the information of
student to the higher official of dormitory management as a result of work over loading
or carelessness.
 Economic, political and other problems: -these are problems lack of materials that are
required to the student such as water, mat, bed etc. Economic problem is mainly
concerned with cost control and profit issues. When data are recorded on manually much
amount of paper are required, due to these it is very expensive compared to automated
system.

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

In order to achieve the main objective, we have the following specific objectives:
 Planning for the new system.
 Reviewing the current system.
 Studying and analyzing the current dormitory management system limitation and
business problems system.
 Suggest a solution to solve the system problem.
 Design the system
 Develop system that facilitate activity.
 Implementation of proposed system in efficiently.
 Understand functional and non-functional requirements of the system.
 Develop a system that facilitates fast report generation.

4
  Increase to the work efficiency of the office.

1.4 Feasibility Study

Feasibility study is essential to evaluate the cost and benefits of the new system. On the basis of
the feasibility study decision is taken on whether to proceed or to cancel the project.

1.4.1 Technical feasibility

This project will be developed by using c#, which is familiar with group members and the group
Members have the ability to develop this system. So the system will be technically feasible or
can be achieved easily from the perspective of technical need.

1.4.2 Operational feasibility

The system will provide simple, accurate, active, secured service. To achieve these goals we will
try to use most available resource of the university that operates in good manner.

1.4.3 Economic feasibility

Our project takes some amount of costs that is for computers, papers, for printing materials,
for writing materials and so on. Finally when we compare the benefit that we got with our cost
our benefit is better so our project is economically feasible. Generally the system that we
developed, WKUDMS brought a number of tangible and intangible benefits.
Tangible benefits:
1. Cost Reduction
2. Error Reduction
3. Increase Speed of activity
Intangible benefits:
1. Reduce Resource Consumption
2. Increase security
3. Increase Management flexibility

1.4.4Schedule feasibility
Concern potential time frame and completion dates for all major activities within a project meet
organizational deadlines. So the time we take to develop this system is expressed as follows.

5
No Activity Date
Planning 1 week
1
Problem identification and requirement analysis 2 week
2
System designing 2 week
3
Implementation of code 2 week
4
Testing and validation 2 week
5
Table 1 Schedule feasibility of the system

1.4.5 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.4.6 Legal and constraint feasibility

Before start these project our project is announce to organization and also modify it by the
organization. Legality with current situation of the system is legal by comparing existing
situation.

1.5 Scope and limitation of the project

1.5.1 Scope of the system
 The scope of this project is to develop a new web based Dormitory Management system
which will avoid the problems associated with the manual processing. Including

 Enable students view their dormitory information easily and quickly

 Generate report efficiently.

 Manage dormitory related information.

 Online Registration: -The system registers all the information of the institution.
 Message: -the user like student, proctor and dormitory manager can communicate
with each other through this system.
 Placement process: the dormitory manager/director will place the student to their
respected block and dorm.

6
  Manage the student profile: the respected proctors will manage the new student as well as
the existing ones.

1.5.2 Limitation of the system

 The new system always need internet connection

 The system needs skilled people.

 Need of electricity.

 Cannot focus on another university dormitory management system.

 Lack of experience to develop the system.
 We cannot get enough information each office when we question about the working
structure.
1.6 Significance and Beneficiaries of the project

The benefits of our project are to develop online or web based system that is important for
dormitory management system.

Significance of the project

 The new web based dormitory management system is important 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 easily.
 Providing a well-organized record keeping system with minimum space.

1.6.1 Benefits of the project

For the Dormitories management or proctors

 They can easily manage or control students.

 Important to control resource.
 If they use web based system, can generate report easily for top manager.
 The key dorm manager can deliver command to else dormitories.
 To know which material is destroyed or not by student.

7
For the top manager of the dormitory system

 Can easily get reports at anytime and anywhere.

 Can get full information about students in the dormitory system.
 For security purpose

For students

 To know their placement at anytime and anywhere after and before coming to campus
 They can easily get clearance for a short period of time when they want to go out of the
campus.
 There is no disturbance between students because the proctor can easily control them.

1.7 Methodology
1.7.1 Data collection methodology
The main purpose of this project will be shift the dormitory management system from
traditional or manual to computerized .so to do this relevant data will be required and so the
relevant data were collected from different area by using different data collection methods.
There two types of data collection method. They are traditional and modern but for simplicity
our proposal information is collected by using traditional data collection methodology. There
are different types of traditional data collection methodology. Including

Direct observation

We will use these types of traditional data collection methodology to collect information about
our system by directly observing the organization. It helps us to get real information how the
organization performs its function and this helps to strength the data that gathered through
interview and document analysis.

Interviewing:-we use this method to get the basic information by interviewing person who have
information about dormitory management system of Wolkite University.

By reading documents

8
We apply this method to gather information by reading different books or documents that are
previously printed from Google or other sources.

1.7.2 System analyses and design methodology

To develop our project, our team should use object oriented system analysis and design (oosad)
development methodology for the design. We select this system development methodology
because we were familiar or we have knowledge in this development methodology.
This technique has several phases some of them are:
A. Object Oriented Analysis (OOA)
During this phase the team uses to model the function of the system (use case modelling),
find and identify the business objects, organize the objects and identify the relationship between
them and finally model the behavior of the objects in detail.

B. Object Oriented Design (OOD)

During this phase designing the sequence, activity diagrams and to model object
interactions and behavior.

1.7.3 Programming development language and tool

Programming development language

Oracle for connecting to database.

 Java,# language use to user interface.

Tool
There are hardware and software tool that are used to develop our project.

Hard ware tools include: -

Flash: - used to store and movement data.

Personal computer: - to write and store the collected information.
Keyboard
mouse

Software tools

Microsoft word 2013: - uses to write the collected data and information in word.
Microsoft PowerPoint-uses to present the project.

9
 1.7.4 System development model

1.7.4 .1 Software process model

The software process model that our team will use iterative model because of the following
reasons: -

o This model solve complex problem

o Requirements of the complete system are clearly defined and understood.

o Major requirements must be defined; however, some functionalities or requested
enhancements may evolve with time.
o There is a time to the market constraint.

o A new technology is being used and is being learnt by the development team while
working on the project.

1.8 Project plan

Planning to do the project identifies business problem.
Analyzing the requirement of the system.
The first month to start the project was February performed mainly for requirement
gathering. This took off course 2 weeks and at the begin April completed requirement
analysis and write the documentation so Through the last two weeks of April and
part of May, we were able to begin designing, after design we began implementation
on may. Around the same time, testing began and continued throughout the
remainder of the project. Finally submit the project. This total date will be
completed 8 weeks (56 date).

1.9 Work breakdown structure and deliverable

NO Member Responsibility

Biniam planning
1
Bayileyegne &eyasu Problem identification and requirement analysis
2
3 Nebyu System designing and implementation of code
4 Ermias Testing and validation

Table 1.1work breakdown structure and deliverable

Communication plan and project organization

Project schedule

10
This title shows the time for performing activity.

No.

Activities Submission date

02\07\2011

19\07\2011

03\08\2011

17\08\2011

01\09\2011

15\09\2011
1 Select title
2 Show proposal
3 System analysis
4 System design
5 Implementation
6 Testing and maintenance

Table1.2 Time schedule of the project

1.10 Budget
In order work our project the following budgets are required:-

Numbe Item Amount required Type Price

r
1 Paper 150 A4 75 birr
2 Printing purpose 70 Page 140 birr
3 Tea & coffee optional Tea->3 600 birr
2->coffee

11
 Total 815 birr

Table 1.3 shows the cost of the project

CHAPTER TWO

2 DESCRIPTION OF THE EXISTING SYSTEM

Introduction
This chapter describes the existing system, users in the existing system of WKU. In addition to
this the business rule is identified, report generated, major function of the existing system.

2.1 Description of existing system

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

2.2. Users of the existing system

An existing system compromises different players to carry out its job. Among those
different actors (players), the most common are Proctor manager, this body provides the list of
all students who fulfilled every requirement for allocation to proctors, Students, they will be
placed in their dorm by proctors and assigned for the property they get from the proctor,
Proctors, They involved strongly in the existing system. Proctors take students list from proctor

12
manager. After they get all these information’s from this body they will place those students
according to their sex, year, department and faculty.
The major actors in the existing system are:
 Students
 Proctors and
 Proctor manager

2.3 Major functions of existing system

The existing system performs its activity manually (partial), it has different major functions.
 Arranging buildings for the allocation: arrangement of building depending on holding
capacity of students
 Arranging students for allocation: Students are arranged based on their sex, year,
department and faculty for dormitory allocation.
 Dormitory allocation: room allocated to students along with associated dormitory
resources, like lockers, tables, chairs, beds and the like.
 Generating allocation report: based the dormitory allocation report is prepared and posted
on the board for students when they arrive at the campus.
 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 measure appropriately.
 Controlling student’s discipline: student’s discipline controlled and recorded whether they
use the dormitory materials properly or not.

2.4 Draw back of the existing system

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

 Performance- The current system’s performance is weak due to the following reasons: - the
acceptable quantity rate is relatively high i.e. the time required from initiation to completion
of a particular task is relatively high.

13
 Information- the current system record information manually duo to this reason redundant
information may occur and information lost occur.
 Controlling- since all the records on existing system stored manually so the system
shouldn’t provide sufficient protection for access and manipulation of the records associated
with the system.

 Services- The services given to users are not flexible, reliable and expandable. Those
services given by the system are limited to a particular area.

2.5 Business Rules in the existing system

 A business rule is effectively an operating principle or polices that must be fulfilled by the
system.
 BR1: Only one dorm is assigned for six students, and those students should live peacefully.
 BR2: Students should not change their dorm without the permission of the proctor with
sufficient reason.
 BR3: it Male students are not allocated with female students and vice versa.
 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.

14
 CHAPTER THREE

3 PROPOSED SYSTEM

Introduction
This chapter describes requirements of the system such as functional and nonfunctional
requirement. Also describes user interface and human factors, hardware consideration,
security issue, performance consideration, error handling, quality issue, backup and recovery
of nonfunctional requirement.

3.1. Proposed system description

Proposed system we want to develop is web based system that is designed to eliminate the
drawbacks of the existing dormitory management system. The system shall be responsible for
posting new information, allocating the new and current students .And also the system shall
incorporate leave management all the way from application to acceptance/rejection of leave
requests as well as all in generating reports. Generally, perform different task in computerized
way.

3.2 Functional requirement

Process requirements

 Edit profile- A user with employee role can edit his/her specific personal information by
entering their user name and password.
 Manage account- This feature can be used only by admin role type. Admin can update,
delete account, and also create account for newly register student or proctor.
 Placing student: the system is able to recorded the new employed applicants and able to
place to their respected position.
Input related requirements

 Register student online: The system registers applicants’ who wants to be hired in the
institution with appropriate information. Without coming to the office they can be able to
register online by using the system.

15
  The user login into the system.
 Manage user information: proctor manager can search and update proctor and student
information by entering user name and password.
 Login: The user can login to the WKUDMS system with his/her username and password.
 Logout: The user can log out from the WKUDMS system.
 View post information: users can view post information posted by posted by dormitory
manager.
Output related requirements

 Report generation- the head of department report generation about activities performed in
every week, month and year.
 Manage user information: The system is able to search, delete and update the user
information when it is needed. Give task: department give tasks to employee.
 View report: the proctor manager view report generated by proctor.

3.3 Non-functional requirement

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

3.3.2 Hardware consideration

 Hardware requirements
This system work on a computer with the following minimum hardware specifications:
 OS: Windows 8 and above
 CPU
 Memory: 128 MB and above
 Capacity: 4GB of hard drive and Network interface card, mouse, keyboard,
and monitor.
 Software requirements
Our system is a web-based application, due to these it requires internet connection must be established .

3.3.3 Security Issues

This system provides an access to an authorized actor by giving account for each and every
special function. Students can view their dorm information by using their identification card
16
number and/or registration number, and give comment without any validation. Proctor can add
information that are important for student and soon.

3.3.4 Performance characteristics

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

3.3.5Error Handling and validation

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.

3.3.6 Quality Issues

The quality of the system is measured through: -

 The proposed system doesn’t obligate the change request thoroughly

 The prosed System should simple or not complex.
 The rate of defect discovered per hour will be low when testing

3.3.7 Backup and recovery

Since we use oracle database server, the server have consistent backup mechanism. By using these server
we backup the data and recover from their failure.

3.3.8 Physical environment

 Operating System: -should be windows 10 or above.
 A server computer : The CPU should have 1.4 GHZ and 64-bite processor and RAM

3.3.9 Resource issues

The systems operates by consume small amount of human resource. And also it consumes less
material or resource and give produce large amount of output. The system throughput is high.

3.3.10 Reliability
The reliability of the proposed system will be better due to proper storage of information
when users access the application.

17
 3.3.11 Accuracy
Proposed system will be better due to reduction of error. All operation can be done
correctly and it ensures that whatever information is coming from the data base is
accurate.

3.3.12 Availability
This system should always be available for access at 24 hours, 7 days a week if internet
connection and electric power is exist, and the system should be available in all working
days, so that the process is not severely affected.

3.3.13 Documentation
Detailed information, in either manual or computerized form, about the system, including its
architecture, design, data flow, and programming logic. The documentation of these system
focuses on:

What is involves?

They key to good documentation is that it is clear and concise, so that anybody other than the
author can pick it up and understand it easily. In many cases, it is more beneficial for a technical
document to be prepared by a group of people in order to give awareness for user about the
system.

What is produced?

These tells about

 Hardware and Software of the system

 Technical Software Specifications.
 Network Documentation.
 User Marketing.
 Risk Management Procedure

18
 CHAPTER FOUR
4 SYSTEM ANALYSIS
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).

4.1 System model

4.1.1 Use case modeling

4.1.1.1 Use case diagram

Use Case represents interaction between a user (human or machine) and the system. Components
of the use case modeling are: _
 Actor: is a person, something or external system that plays a role in one or more
interaction with the system. And it can be represented as:

Fig 1 Symbol of actor

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

Fig 2 Symbol of use case

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

Fig 3 Symbol of system boundary

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.
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
 Submit comment
 View comment
 Register block (Allocate Proctor)
 Register room
 View Student Information
 Generate report

20
 Fig 4: Use case diagram for the proposed system

4.1.1.2 Use case Description

Use case name: Login

Use case Id: UC1

Description: To authenticate the user

Actor: proctor manager, proctor and student.

Precondition: The user must be registered on the system

Basic course of action:

Actor action

Step1: User wants to login

21
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: Submit Comment

Use case Id: UC2

Description: User can give comment.

Actors: Student, proctor.

Precondition: The Student and proctor must have valid Email address.

Basic course of action:

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.

22
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: Create Account

Use case Id: UC3

Description: proctor manager assigns privilege to the proctors.

Actors: proctor manager

Precondition: The proctor manager must log in to the system.

Basic course of action:

Actor Action:

Step1: The proctor manager log to his/her account.

Step2: The proctor manager click on User Account link.

Step4: The proctor manager click create account link.

Step6: The proctor manager 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.

Step7: The system displays succeed information as the account is created.

Step8: Use case ends.

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

4.1.1.3 USE CASE SCENARIO

The following are describing scenario of how the user uses the systems.

Scenario name: login

Actor: proctor manager, student and proctor

Step 1: browse home page

Step 2: enter user name and password on the login form

Step 3: then click on login link

Step 4: the system check the user name and password

Step 5: if user name and password is valid user page is display next performing his authenticated
operation else display error message.

Step 6: logout

Example: if student, proctor or proctor manager want to login to the system first browse the
home page then the system display login form. After the system display the login form then fill
login form and click login button .If the data is invalid the system display error message else user
page is display next perform his authenticated operation and logout.

4.2 Object Model

In this title the system contains:

 Class diagram
 Data dictionary

4.2.1 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

24
stores and manages information in the system. In the phase of conceptual class modeling we just
create classes and their interrelationship.

Fig 5 Analysis level of Class Diagram

4.2.2 Data dictionary

 A set of information describing the contents, format and structure of a database and
the relationship between elements used to control access to other data.
Attribute Data type Size format validation
student ID Varchar 10 CIR/139/09 Primary key
First Name Varchar 15 wuletaw Not Null
Middle Name Varchar 15 Kelemu Not Null
Last Name Varchar 15 Nigatu Not Null
Phone no Varchar 12 +251915259135 Not Null
Gender Varchar 5 Male Not Null
Region Varchar 10 Amhara Not Null
GPA Number 3 3.4 Not Null
Department Varchar 40 Information system Not Null

Table 1.4 Data dictionary for student

Attribute Data type Size format validation

25
managerID Varchar 33 CIR/139/09 Primary key
firstName Varchar 44 Nebyu Not Null
Middle Name Varchar 55 Kelemu Not Null
lastName Varchar 15 Nigatu Not Null
PhoneNumber int 12 0915259135 Not Null
Gender Varchar 5 Male Not Null
Region Varchar 10 oromia Not Null
salary float --- 4455.8 Not null

Table 1.5 Data dictionary for proctor

4.3 Dynamic model

4.3.1 Sequence diagram
A sequence diagram is an interaction diagram. From the name it is clear that the diagram
deals with some sequences, which are the sequence of messages flowing from one object to
another. Interaction among the components of a system is very important from implementation
and execution perspective. So Sequence diagram is used to visualize the sequence of calls in a
system to perform a specific functionality

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.

26
Fig 6 sequence diagram for login

Fig 7 Sequence diagram for View dorm Information

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

27
  Describe the parallel, branched and concurrent flow of the system
 So, WKU student dormitory management system has the following activity diagrams

Fig 8 Activity diagram for proctor, proctor manager and student to Login

Fig 9 Activity diagram for proctor, proctor manager and student view student information

28
Fig 10 Activity diagram for proctor manager to allocate block and proctor

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.

The most common model elements that state chart diagrams contain are:

 States
• Initial State 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.

29
Fig 11: State chart diagram for student for block registration

30
 Fig 12: State chart diagram for submit comment

CHAPTER FIVE
5 System Design
Introduction
System design is the transformation of the analysis model into a system design model. In
system analysis level of modeling it focuses on the problem domain but in system design level it
the solution space software development.
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. The objectives of
design are to model the system with high quality. Implementing of high quality system depend

31
on the nature of design created by the designer. Facts that are considered in this chapter are:
design goals, system architecture, system decomposition etc.

5.1 Design goals

The goal of system design according to proposed system is to increase efficiency, security and
accessibility of the system. Design goals describe the qualities of the system that developers
should optimize. Such goals are normally derived from the non-functional requirements of the
system.

Design goals describe the qualities of the system that the developers should consider
Performance. The system has a fast response time with maximum throughput and the system
should not be taking up too much space in memory.

5.1.1 Performance
The part of the system a fast response time (real time) with maximum throughput. Furthermore,
the system should not be taking up too much space in memory. The fast response time over
throughput and hence the system should try to be more interactive. In the case of the timetabling
subsystem, the system should be more reliable in order to satisfy the constraints than fast
response time.

5.1.2 Maintenance
These shows that the system is requires less cost for Maintenance to recover from failure.

5.1.3 End User

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.3 Architecture of the proposed system

The new system replaced the existing manual system by using the software architecture .This
architecture allows various users to access the data from center database server.

32
There are three layers of architecture that can be used in the proposed software are. The layers
are the following:

 The application layer

 Database layer
 Logic/ connector layer
 Application layer: Layer which provides graphical user interface and application
specific entry forms to the user of the system. Application layer interact with logical
layer through HTTPs protocol.
 Database layer: Used to assist resource sharing and allow the client to be configured
with the help of SQL server.
 Logic layer: Layer that used to implement business rules and data rules, which keep the
data structure consistent.

5.3.1 System 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:-
 Manage account subsystem: in this subsystem managing of information regard to account
and perform.
• Update account
• Activate account
• Resetting account
• Block account
 Placement subsystem
 Arrange new freshman student
 Login subsystem
o Password
o User name
o User Type
 View dorm subsystem
• View the block and the dorm number of the student.

33
 Allocate proctor subsystem
o Allocate proctors for each block.

 Generate report subsystem

 Proctor prepare students information and submit to proctor manager.
 The proctor manager also prepare proctor information and report to administrator.

5.3.2 Hardware/Software mapping (Deployment design)

 Hardware/Software mapping is used to show the hardware of the system, the software that is
installed in the hardware and also shows how the software and the hardware components
work together.

Fig 13: Deployment design of the system

5.3.3 Detailed diagram

 Describes the specific behavior of these components.
 It contains the data type, cardinality and validation of the attribute and operation.

34
Fig 14: detail diagram of the system

5.3.4 Persistent data management

Persistence modeling is used to communicate the design of the database, usually the database to
both the users and the developers. It is also used to describe the persistence data aspect of the
system. The following diagram indicates the persistence diagram of the system.

35
 Fig 15: Persistence Diagram

5.3.5 Access control and security

Defines the authorization and authentication mechanism of user. And also it shows that the types
of privileges that the user has.

The athenticated body to the given system

36
 student Proctor Proctor manager
Create account 
Login into account   
Allocate block for 
student
Submit comment   
Allocate proctor 
Generate report  
Delete account 

Update account 

Table 1.6 Access control

5.4 UML Package Diagrams

Packages are UML constructs that enable you to organize model elements into groups, making
your UML diagrams simpler and easier to understand. It is a structural diagram.

They are most common on use case diagrams and class diagrams because these models have a
tendency to grow. The three types UML packages are

Class Package Diagrams

 Classes in the same inheritance hierarchy typically belong in the same package.

 Classes related to one another via composition often belong in the same package.

 Classes that collaborate with each other.

 It shows several packages and the dependencies between two or more related class.

37
 Fig 16: package diagram for login

Data Package Diagrams

• In this packages data entities are organize into large-scale business domains.

• Data’s that are related to each other are organized in packages.

Use Case Package Diagrams

 Use cases organized into packages

 Actors also include in these packages.

 It included and extending use cases belong in the same package as the base/parent use
case.

38
Fig 17: Package diagram, which organizes use cases.

39
5.5 User Interface Design

Fig: Fig 18: graphical user interface for login

40
Fig 19: graphical user interface for home page

41
Fig 20: graphical user interface for create account

42
 CHAPTER SIX
6 CONCLUSION AND RECCOMENDATION
6.1 CONCLUSION
Wolkite 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.

43
References

[1] c. grannell, modern ,modular approach to standard compliant web design, 2004.

[2] D. B. a. G. W. Scragg, The Object Primer, Third Edition, 2004.

[3] D. Bell, [Online]. Available: https://www.fing.edu.uy/inco/cursos/ingsoft/iis/files/UMLClass

%20diagram.pdf., 19 December 2016,15 Sep 2004.

[4] f. g. f. mehammed, online auction management system, 19 april 2004,21 november 2016.

44