COLLEGES OF COMPUTING AND INFORMATICS

DEPARTMENTS OF INFORMATION SYSTEM

OBJECT ORIENTED SYSTEM ANALYSIS AND DESIGN
===============welcome to==============

GROUP: FIVE
WOLKITE UNIVERSITYDORMITORY MANAGEMENT SYSTEM
SECTION: A
MEMBER ID
1. Nebyu kelemu………………………………..cir/139/10
2. ermias bogale………………………………cir/ /10
3. eyasu ayinekulu………………………….cir/111/10
4. biniam shiferaw…………………………...cir/086/10
5. bayileyegne alamir…………………….cir/089/10

SUBMITED TO: ESAYAS.W

SUBMITTED DATE: 22/09/2011

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

Table of Contents
i
Acknowledgement........................................................................................................................................i
LIST OF FIGURE............................................................................................................................................ii
LIST OF TABLES............................................................................................................................................iii
LIST OF ABBREVATION................................................................................................................................iv
Abstract.......................................................................................................................................................v
CHAPTER ONE..............................................................................................................................................1
1. INTRODUCTION.......................................................................................................................................1
1.1 Background of Dormitory management system in WKU...................................................................2
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 Significance and Beneficiaries of the project.........................................................................................7
1.6.1 Benefits of the project....................................................................................................................7
1.7 Methodology.........................................................................................................................................8
1.7.1 Data collection methodology..........................................................................................................8
1.7.2 System analyses and design methodology.....................................................................................8
1.7.3 System development model...........................................................................................................9
CHAPTER TWO...........................................................................................................................................12
2 DESCRIPTION OF THE EXISTING SYSTEM.................................................................................................12
Introduction...............................................................................................................................................12
2.1 Description of existing system.............................................................................................................12
2.2. Users of the existing system...............................................................................................................12
2.3 Major functions of existing system......................................................................................................12
2.4 Draw back of the existing system.......................................................................................................13
2.5 Business Rules in the existing system.................................................................................................13
CHAPTER THREE........................................................................................................................................15
3 PROPOSED SYSTEM................................................................................................................................15
Introduction...............................................................................................................................................15
3.1. Proposed system description..............................................................................................................15
3.2 Functional requirement................................................................................................................15
3.3 Non-functional requirement...............................................................................................................16

ii
 3.3.1 User Interface and human factors................................................................................................16
3.3.2 Hardware consideration...............................................................................................................16
3.3.3 Security Issues..............................................................................................................................16
3.3.4 Performance characteristics.........................................................................................................17
3.3.5Error Handling and validation........................................................................................................17
3.3.6 Quality Issues................................................................................................................................17
3.3.7 Backup and recovery....................................................................................................................17
3.3.8 Physical environment...................................................................................................................17
3.3.9 Resource issues.............................................................................................................................17
3.3.10 Reliability....................................................................................................................................17
3.3.11 Accuracy.....................................................................................................................................17
3.3.12 Availability..................................................................................................................................17
3.3.13 Documentation...........................................................................................................................18
CHAPTER FOUR.........................................................................................................................................19
4 SYSTEM ANALYSIS..................................................................................................................................19
Introduction..............................................................................................................................................19
4.1 System model.....................................................................................................................................19
4.1.1 Use case modeling........................................................................................................................19
4.1.1.1 Use case diagram...................................................................................................................19
Actor identification............................................................................................................................20
Use case identification.......................................................................................................................20
4.1.1.2 Use case Description..............................................................................................................21
4.1.1.3 USE CASE SCENARIO..............................................................................................................24
4.2 Object Model......................................................................................................................................24
4.2.1 Class Diagram...............................................................................................................................24
4.2.2 Data dictionary.............................................................................................................................25
4.3 Dynamic model...................................................................................................................................26
4.3.1 Sequence diagram........................................................................................................................26
4.3.2 Activity diagram............................................................................................................................28
4.3.3 State chart diagram......................................................................................................................29
CHAPTER FIVE...........................................................................................................................................32
5 System Design........................................................................................................................................32

iii
Introduction..............................................................................................................................................32
5.1 Design goals........................................................................................................................................32
5.1.1 Performance.................................................................................................................................32
5.1.2 Maintenance.................................................................................................................................32
5.1.3 End User.......................................................................................................................................32
5.3 Architecture of the proposed system.................................................................................................33
5.3.1 System Decomposition and description........................................................................................33
5.3.2 Hardware/Software mapping (Deployment design).....................................................................34
5.3.3 Detailed diagram..........................................................................................................................35
5.3.4 Persistent data management........................................................................................................35
5.3.5 Access control and security..........................................................................................................36
5.4 UML Package Diagrams......................................................................................................................37
CHAPTER SIX..............................................................................................................................................43
CONCLUSION AND RECCOMENDATION.....................................................................................................43
CONCLUSION.........................................................................................................................................43
7.2 Recommendation............................................................................................................................43
References.................................................................................................................................................44

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

iv
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 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 home page

Fig 19: graphical user interface for login

Fig 20: graphical user interface for create account

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

Table 2: work breakdown structure and deliverable

Table 3: Time schedule of the project

Table 4: data dictionary for student

Table 5: Data dictionary for proctor

Table 6: Access control

vii
 LIST OF ABBREVATION
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

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

3
  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.
 Increase to the work efficiency of the office.

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

No Activity Date
Planning 1 week
1
Problem identification and requirement analysis 2 week
2
System designing 2 week
3

5
 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. So our project fully
legal with any aspect of current situation of the organization. Because proposed system is not conflict
with legal requirements.

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.
 Placement process: the dormitory manager/director will place the student to their
respected block and dorm.
 Manage the student profile: the respected proctors will manage the new student as well
as the existing ones.
 Message: -the user like student, proctor and dormitory manager can communicate
with each other through this system.
 The student enables to get bed service.

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

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

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

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

8
 B. Object Oriented Design (OOD)

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

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.

1.7.3 System development model

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.

Project plan

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

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

This title shows the time for performing activity.

Activities Submission date

10
No.

02\07\2011

17\08\2011

15\09\2011
19\07\2011

03\08\2011

01\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

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

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

13
 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, 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.
 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.

15
  Login: The user can login to the HRMS system with his/her username and password.
 Logout: The user can log out from the HRMS 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 number and/or
registration number, and give comment without any validation. Proctor can add information that are
important for student and soon.

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

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.

17
 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

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

19
 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.
 Administrator: The administrator manages the overall system.
Use case identification
Each Use Case describes the functionality to be built in the proposed system, which can include
another Use Case's functionality or extend another Use Case with its own behavior. The most important
and basic use cases of this system are the following:-
 Login
 Allocate Student
 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

Step2: Select the login link

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

Step5: The system validates the entered information.

Step6: The system display as your comments has been sent

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

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.

23
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 stores and
manages information in the system. In the phase of conceptual class modeling we just create classes and
their interrelationship.

24
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 Nebyu 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.3 Data dictionary for student

Attribute Data type Size format validation

managerID Varchar 33 CIR/139/09 Primary key
firstName Varchar 44 Nebyu Not Null
Middle Name Varchar 55 Kelemu Not Null

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

Fig 6 sequence diagram for login

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

 Describe the parallel, branched and concurrent flow of the system

 So, WKU student dormitory management system has the following activity diagrams

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

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

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 module
 Arrange new freshman student
 Login page

32
 o Password
o User name
o User Type
 View dorm module
• View the block and the dorm number of the student.
 Allocate proctor module
o Allocate proctors for each block.

 Generate report
 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

33
5.3.3 Detailed diagram

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.

34
 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

35
 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.5Access 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.

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

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

38
Fig 18: graphical user interface for home page

39
Fig: Fig 19: graphical user interface for login

40
Fig 20: graphical user interface for create account

41
 CHAPTER SIX

CONCLUSION AND RECCOMENDATION

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.

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

References

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

43
44