Final Project

CHAPTER ONE
INTRODUCTION
Ambo University Dormitory management system is one of the great service systems
which found in our campus .This service system needs computerized and modernize to give
quality and brief service for users or students .so; it is redesigned and analyzed in this Dormitory
service management system. This project contains and solves problems in Dormitory service
management area step by step. In general problem is raised and the solution overcomes the
problem.
1.1 BACKGRUOND
Ambo university Dormitory management system is starting its service when Ambo
university is established in 1939 E.C at western Shewa .At the begging ,there were 2 blocks
(Cambodia and Holihude).It starts giving different service to student such as dorm, key ,
clearances services form and bed for regular students . This service is managed by dormitory
manager .Now a days the service gives access around 10,000 students, 20 blocks and 32
dormitories. Manual system creates complex & complicated system when entering and clearing
student to university. The problems that are identified are discussed on the next tittles.
1.2 Statement of the problem

This dormitory management service currently uses manual system which creates the
following major problems.
 It is difficult to find which dorm (block) is allocated or de allocated.

 Data recording system is not centralized or not in the modern system
which is difficult to search.
 It creates wastages of material &time
 Data redundancy &lose:-as mentioned above ,the manual searching
system of a required information is very time consuming and sometimes
may lead to inability to find the information that already exists . This
results in storing the same information again and again. And also the data
may disappear because of some real world problems since it is stored on
papers manually.
 Space reservation problems: - the manual system is using papers for
storing information. As the number of users is increasing and information
is stored redundantly, the space reserved for storing this information is
more than required.
 It’s difficult to communicate with the dormitory when there is no assigned
dorm for an individual student, because the existing system is not
accessible automatically.
1 Ambo University Online Dormitory Management System Industrial project I AmboU

2014
1.3 Objective of the Projects
1.3.1 General objectives

The main objective of this project is to convert or change the manual system to computerized
system to solve the above stated problems.
1.3.2 Specific objectives

The system should provide the following:
 Make the system automatic.
 Minimize human work effort.
 Improved performance to announce students to which Dorm they have been placed.
 Efficient use of time.
 Fast data processing.
 Less cost.
 Designing the system architecture of the system
 Designing friendly user interface
 Designing database to the system that can hold all the information
 To improve the communication between the student with the dormitory.
1.4 Scope and limitation of the project
1.4.1 Scope of the project
 The scope of our project is providing the access for information about the dormitory
management to students in AmboU. The scope of the project is that every student
will know client side user name and password to see their dorm where they are
assigned.
 Allowing the AmboU student to use the online system anywhere they are.
 Every Proctor will use an account number and password as the main security of the
DM system.
 Our system used for undergraduate students.
 The System contains all the recorded information that can be handled by the
manager and Proctors.
 For new students who access the system for the first time, the DMS allow privilege
to access by their Name and Registration number.
1.4.2 Limitation of the project
The project we are developing has limitation on fields like:
 Our system works when a server control services is available.

 It works for the one who understand English language (we have not used other language).

2014
 It serves only students who are Undergraduates in AmboU.
 Our system does not serve the students who are not regular students in Ambo University.
 Our system does not serve the students who are not able to see (blind people).
 Our system does not support to give a clearance to students.
1.4.3 Target groups and benefit of project

 The project focuses on the student how to access service from dormitory service and
also it enables the dormitory service manager.
 The project gives benefit to dormitory service manager to easily give service to
student and too easily, allocate dorm for the students when they entered to the campus
and also de allocate student dorm when student leaves the campus.
 The student can get fast access and service from the dormitory service management.
 The developers of this project Obtain knowledge and experience while they are doing
this project. They also achieve popularity, money and confidentiality.
 Generally the students of Ambo University and the Dormitory manager are more
beneficial of this system.
1.5 Methodology
Is the way or mechanism in which we gather information to develop the system.

We have used the following methods:
 By interviewing the dormitory manager of Ambo University directly.
 By observing how the system is performing its tasks using MS office excel 2007.
 By seeing the forms that the existing system uses how students enter and take out their
property from the dorm.
 Development life cycles, including specific models, tools, techniques and system
development life cycles.
 Tools the prototype of the system is developing based in a web-based environment. To
develop this project used the following software tools.
Software Used
 Internet Explorer: As a web browser to launch the prototype.
 SQL-server
 Frame work NET
 Microsoft word 2007 and 2010 to write all documents.
 Microsoft Visio 2007 we used it for drawing all UML.
 C# in ASP.NET programming language.
 Web servers (IIS).
 Window 2007(operating system).

2014
1.6 Feasibility of the project
 Feasibility of the our project the aim to objectively and really uncover the strength
and weakness of the existing business or proposed opportunities and threats as
presented by the environment resource required or materials and also any information
or experience to the management of Dormitory.
 As much as the university communicates by English language, this project will work
in English language only. So we don’t have to use Cross Natural language and Speech
Synthesizing (sound) machine. Therefore it is feasible.
Benefits after implementation:
Economic Feasibility
 The system to be developed is economically feasible and the benefit is outweighing the
cost. Since this project already computerizes the existing system, by now the reduction
of cost for materials used in manual operation becomes beneficiary to the organization.
 Generally the system we developed for Ambo University Online Dormitory
management and announcement system brought a number of Tangible and intangible
benefits.
Tangible benefits
Our system reduces any costs like on cost of paper for documentation, cost for different
writing materials.
Intangible benefits
The system we are developing has many in tangible benefits that revolve around mental
satisfaction of users. These where:
 Having information about the AmboUDM any time.
 Satisfies the AmboU students in the way that they trust the system is secure and accurate
on giving service.
 Knowledge gain by project developer.

 Increasing the competitiveness of the individual
 Improved productivity
 Improving the morale of our team.
 Facilitating information processing of our team
 Faster decision making on the team member.

2014
Technical Feasibility:
The system developers understand the scope, objectives including specific objectives and
limitations of the proposed system well and the users have technical capability to use this system.
As a result they develop the website for Ambo University successfully within proposed resources
(budget, time, etc.), so the project is technically feasible.
Schedule Feasibility:
 Our project to prepare or completed in a given time of period property using some
methods like payback period (I.e. is concerned method of analysis with serious
limitations and qualification for its use.
 Project team will develop the new system in the given period of time for the
industrial project.
Operational feasibility:
 The system is operational in way that we have decided to work by effort and in
collaboration with AmboU ICT office. This includes giving training to users.
1.7 Project plan activities

 To develop the system our team has followed project plan precisely in order to make
the concerned body get the system simple.
 To prevent the work delay and to avoid the hindering things in developing our
software system , we have structured tasks in order to do the task and what
resources (time, and human physical resource) are needed to do tasks.

2014
1.7.1 Work-Break down Structure, and coordination
Id Tasks Duration Predecessor Responsible

1 Project Initiation and planning 2 weak All
 Gathering Information
2 Description of the project 1.5 weak 1 Selamawit
Introduction:
W  Background Information
O  Statement of the Problem
R  Objective of the problem
K  Scope & Limitation of the project
B  Methodology
R  Feasibility study
E  Project Plan Activity
A
K 3 Current system 1 weak 1,2 Meseret
D  Description of current system
O  practices to be preserved from the
W existing system
N  Players in the existing system
S  Business Rules
T  Alternative Solution
R 4 Proposed System 2 weak 1,2,3 Melisew
U  Functional Requirements
C  Non Functional Requirements
T  User Interface
U  Hardware or Software Requirement
R  Security and Safety procedure
E 5 System Modeling 4 weak 4 Hailu
S  Use case diagram, and there
description
 Object Model
 Dynamic model
6 Implementation 13 weak 3,4 All
 Designing
 Coding
 Testing
Table-1 Work Break down Structure

2014
1. Resource plan
 We used computer lab and the computers, laptop, disks (CD, flash), paper for
layout and properly using them and protecting these resources from damage.
2. Communication plan
 First communicating with every team member and then communicate with our
advisors by respecting time of our appointment.
3. Time schedule
Time duration regarding our project is scheduled follows:
Gant Chart
Dec 2013 Jan 2014 Feb 2014 Mar 2014 Apr 2014 May 2014 Jun 2014
ID Task Name Start Finish Duration
12-1 12-8 12-15 12-22 12-29 1-5 1-12 1-19 1-26 2-2 2-9 2-16 2-23 3-2 3-9 3-16 3-23 3-30 4-6 4-13 4-20 4-27 5-4 5-11 5-18 5-25 6-1 6-8 6-15 6-22
Project Initiation and
1 planning 29-Nov-13 05-Dec-13 1w
2 Gathering Informatin 06-Dec-13 12-Dec-13 1w
Description of the project

Introduction:
Background Information
Statement of the Problem
Objective of the problem
3 Scope & Limitation of the project
13-Dec-13 24-Dec-13 1.5w
Methodology
Feasibility study
Project Plan Activity
Current System:
Description of current system
practices to be preserved from
4 the existing system 25-Dec-13 31-Dec-13 1w
Players in the existing system
Business Rules
Alternative Solution
Proposed System:
Functional Requirements
Non Functional Requirements
User Interface
5 Hardware or Software
02-Jan-14 15-Jan-14 2w
Requirement
Security and Safety procedure
System Modeling:
Use case diagram, and there
6 description 16-Jan-14 12-Feb-14 4w
Object Model
Dynamic model
Implementation:
Designing
7 05-Mar-14 03-Jun-14 13w
Coding
Testing
8 Final submitting Date 24-Jun-14 26-Jun-14 .5w
Fig-1.1 Gant chart

2014
1.8 Project Organization
Our project organized in two main phases.

The first phase of our project include chapter one of project up to chapter four which
includes introduction about the existing system, current system information, proposed
system information and Modeling using OO(Object Oriented)Paradigm for phase one and
Design OO (Object Oriented paradigm) and system implementation for second phases.
Team organization
We have organized our self (team member) in a decentralized way that every team
member communicates to each other and diagrammatically.
Fig-1.2 Decentralized Organization

2014
CHAPTER TWO
2 Current System
Introduction
This project emphasize on Dormitory service management system in Ambo University.

Therefore, we give an overview of the management system of student dorm service in Ambo
University.
 The dormitory management gives service for all regular students in ambo university
 Students does not pay money for dorm
 The dormitory can control the students in properly way
 Decreases the amount of budget wasted for students since the dorm is not far.
2.1 Description of current system

 Currently the AmboUDMS works in a traditional way that it’s impossible to say a
manual system (lack of necessary document) that is an organized to work and more
time consuming. Including the present of AmboUDM and other leaders connect to
each other by phone , letter ,report and every time concerning their works is paper
based that to cost for writing materials .
2.2 practices to be preserved from the existing system
2.2.1- Strength of the existing system

Even if the existing system is manual system as it has weakness it also has some strong side that
we need to be preserved are:
 Provide the required infrastructure to the students.

 Protecting dormitory resources.
 Posting dormitory information in each building.
 Generation timely report.
 Assessing discipline cases.
2.2.2- weakness of the existing system

 The existing system had many problems. For example, if the dormitory wants to clear
one student from the campus he/she first sees for the students name and file number.
 Then he/she also searches for another document depending on the file number of the
student. Because they keep the students record separately based on their file number.
Each student has their unique file number.

2014
 In generally current system is a system that needs intensive human labor resource
,consume time ,less security ,lack of awareness and accurate available information .
2.3 Players in the existing system

Dormitory manager
 He/she is responsible for control the overall activities.

 He/she is a person who administer for each block of the Proctors.
Proctor
 He/she is a person who manages for each block of the students.

 He/she Provides clearance for every student.
 He/she generate report and sends to the dormitory manager.
Student
 They are users who accesses service from AUDM system.
2.4 Business Rules

At this moment the dormitory management uses the new promotion policy of the dorm.
 The student must be agreeing with their members of the dorm.

 Students are allocated in such a way that male students are not allocated with female
students.
 Proctors should not assign one student in more than one dorm.
 Students should not change their dorm without the permission of the proctor with
sufficient reason.
 Buildings should be arranged before the allocation.
 The student must keep the dorm properly.
 Two or more students never sleep in one bed.
 One student should not steal others property.
 Students never smoke cigarettes and chewing chat in the dorm.
 If the students don’t agree with their dorm members the dormitory gives advices.
 If two or more students sleep in one bed for the first time the dormitory gives orally
warning.
 If two or more students sleep in one bed for the second time the dormitory gives
penalty.

2014
2.5 Alternative Solution
There are many solutions for the existing system problems.
These are:
 Making the system fully manual
 Making the system partially automated
 Making the system fully automated
From all the above alternatives solution, it is difficult to use the fully manual system, because it
require much cost, consume time, less accurate, prone to error and has other related problems.
Analyzing this problems our project team proposed the partially automated system to solve
and reduce this delaying problems in the existing system.

2014
CHAPTER THREE
3 Proposed System
3.1Overview of Proposed System

After observing the current manual system and identifying all the problems occurred during
every activity on the existing system, the project team has decided to design an automated online
application AmboUDMS for office and system that can be easily access and work at any time
and place.
The proposed system will use the major functionality of existing system and able to advance
with speed and response of the system by applying the knowledge of OOP techniques in order to
overcome the current problems of the system.
 More secure, because this system provides the users to have an account.
Fig-3.1 Architecture of the System

2014
3.2 Functional Requirements
The functional requirements that the DMS will provide:
 Allocate dorm and gives necessary materials for every student those who are join to
the University.
 De allocates dorm for students those who leaved the University.
 Views the block number, the dorm number and floor.
 Creating, Deleting, Updating user name and password for the Proctors and students.
 Generating report.
3.3 Non Functional Requirements
Speed and Performance
 The system should quickly display dorm number as soon as the students enter their
name and id number.
 The system should be applicable for reporting the dorm of many students as much as
possible.
Error Handling
When user makes some error:
 The system must have capacity for error handling.
 The system should display error message if the user input invalid character.
Response time
 The system connects to personal computer within minimum period of time.

 The users have to get services from the system rapidly.
 The system should meet what the user expects.
Robustness:
 The system should be tolerable of fault in case of SW and HW failure.
Availability:
 The system should available for further use while needed.

2014
3.4 User Interface
Specification
 The system GUI should be consistent with all other programs.

 The caption and text of GUI should be clear to understand and self-descriptive.
 The GUI should be accompanied with help files that describe the usage of each GUI.
 The GUI should be easily customizable.
Fig-3.2 User Interface
User Interface Description
Home Page:
Identifier UI: 1
Description: User interface part where DMS are viewed and link for related topics (websites).
 Where User interface we can add any idea we have regarding to DMS of Ambo
University.
Log in Page:
Identifier UI: 2

2014
Description:
 It is a core of user interface part.

 It is a way user of system log into system by entering their user name and password.
 User must enter valid user name and password here to get next service from this system.
Student Page:
Identifier UI: 3
Description:
 This page displays the students’ needed profile format.

 This page also enable students to see their Dorm No by entering valid solution\answer for
set of questions the system asked them.
View Page:
Identifier UI: 4
Description: This page enables students to view their dorm.
System Administrator Page
Identifier UI: 5
Description: The system Administrator Page is the page that enables the system Administrator
to delete, add, and change the user account for students and proctors to communicate with the
system.
Proctor page
Identifier UI: 6
Description: The proctor Page is the page that enables the proctor to allocate and DE allocate
dorm for the student.
Report page:
Identifier UI: 7
Description: Help the student report to the proctor and the proctor report to the administrator.
Add Account Page:
Identifier UI: 8

2014
Description: The page that enables the system administrator to add additional Account for user
when the new User comes.
Delete Account Page:
Identifier UI: 9
Description: The system that enables system Administrator to delete the account of user when
user completely or permanently leaves from the University.
Change Account Page:
Identifier UI: 10
Description: The Page that System Administrator use to change account of user when password
is hacked by other user or when changing account is obligate.
Help Page:
Identifier UI: 11
Description: The page that provide help information for users when they need help regarding to
this system.
Allocate Page:
Identifier UI: 12
Description: This page is useful for Proctor to assign the Dorm for the student.
De-Allocate Page:
Identifier UI: 13
Description: This page is useful for Proctor to remove the assigned Dorm which is free now.
3.5 Hardware or Software Requirement
3.5.1 Hardware requirements
One server computer with:-
 500MB of RAM,
 2.97GHZ of Intel Pentium processor speed about 50GB hard disk size
 Category 5 UTP cable. The length of the cable is flexible depends on the environment.
 Network Interface Card for each computer on the network
2014
 One 8-port switch.
 At least two client computers:- With 500MB of RAM 2.8 GHZ of processor speed and
48GB of hard disk size. For both servers and clients the size of the hard disk can be
increased with data increased.
 At least one printer for printing the report
 Output device:
 HP laser jet 4200 printer.
 Monitor –with highest resolution
 External storage device:
 Flash disc 1-16 GB
 Compactable CD-ROM 700 MB
 External hard disc 300 GB
3.5.2 Software requirements
 Windows server 2003 or later versions OS:-
This OS is installed on the server computer, by which can manage client computers on
the network.
 Windows 7 ultimate or later versions OS: - this operating system is installed on the client
computers enable to join the domain of the network.
 Microsoft SQL server 2005:- on which the records and all other data stored on.
 Driver software is also needed for the server, client and printer.
 UML 2.0 designer (Visio):-to design and modeling the system.
 Microsoft visual. Net 2008/Asp.net:-it used for develop web application written in asp.net
are fast, efficient, manageable, scalable, and flexible.
3.6 Security and Safety procedure
 The authentication process performed two times, first the user authenticate against the
domain of the network. After they join the network, the system authenticates the user to
determine the privilege the user can does on the system.
 The database also protected by username and password so the data event cannot be
changed at the database even if someone gets access to the database server.

2014
CHAPTER FOUR
System modeling using OO Paradigm
4.1 Use case diagram
Use case diagrams are diagrams used to capture functional requirements of DMS. The notation
of use case diagram is developed to build an external view of DMS. Each use case diagrams
describes a behaviorally related sequence of transaction in a dialogue between the system
Administrator, Procter (dormitory) and Student.
Ambo University Dormitory management System
student
View Dorm
<<Extend>>
«uses»
*
Procter
«extends»
Deallocated dorm
* Report
«extends»
Login
«uses»
* Allocated Dorm
**
Administrator
«extends»
«uses»
LogOut
«uses»
*
«uses»
Create account
Update Account
dellete account
Fig-4.1 use case diagram for Dormitory management system

2014
4.1.1 Actor Description
The actors that interact with the system are the dormitory; administrator and student are users of
the system. They are described here in brief:-
Name: Procter (Dormitory)
Description: A Procter (Dormitory) is a person who is responsible for allocating and de

allocating the dorm to the students.
Name: Administrator
Description: Administrator is a person who is responsible for creating and modifying accounts
for the Procter.
Name: Student
Description: Student is a person who is responsible for view the dorm.
4.1.2 Use Case Description

The use cases presented in Figure 5 above: - view dorm, allocate dorm, de allocate dorm, report,
log in, create account, update account and delete account are described in detail in this section.
UCI: UC1
Name: view dorm.
Description: A student views the dorm in which block they are assigned.
Actors: student
Precondition: he/she never see his/her Dorm.
Flow of Event:
1. The student wants to get dorm.
2. The system displays the dorm (block) Page.
3. The student enters all of the required information.[A]
5. The system checks that all of the required information was correct
6. The student will be assigned.[B]
Post condition: The student already gets their dorm.

2014
Alternative flow of events
Alternative flow A: Missed required field/s or incorrect information
A3. The system displays data entry error message
A4. The system resumes at step 3
B: The student not assigned.
B1: the system resume at step 6.
UCI: UC2
Name: allocate dorm
Description: The Procter allocate the dorm to student
Actors: Procter
Precondition: the dorm no is not allocated.
Flow of Event:
1. The Procter want to allocate the dorm.
2. The system displays the allocate Page.
3. The Procter enters all of the required information (block no, dorm no, student id). [A]
6. The Procter will be allocating the dorm for the student.
Post condition: the dorm no already allocated.
A2. The system resumes at step 3

2014
UCI: UC3
Name: De allocate dorm
Description: The Procter de allocates the dorm to student who is not present any more.
Actors: Procter
Precondition: the dorm is allocated the person who does not exist.
Flow of Event:
1. The Procter want to de allocate the dorm.
2. The system displays the de allocates Page.
3. The Procter enters all of the required information (block no, dorm no, student id). [A]
6. The Procter will be de allocating the dorm for the student.
Post condition: the dormitory already de allocated the dorm
A2. The system resumes at step 3.
UCI: UC4
Name: Report
Description: The Students and Procter reports issues about the existing system.
Actors: student, Proctor
Precondition: the student and Proctor do not send report.
Flow of Event:
1. The student or Proctor wants to report.
2. The system displays the report Page.

2014
3. The student enters all of the required information (stud Name, student id), and the Proctor
enters all the required information. [A]
6. The student will report the information to the Procter. And the proctor will send the report to
the Admin.
Post condition: the student and Proctor already sent report.
A2. The system resumes at step 3.
UCI: UC5
Use case name: -login
Actor:-Administer, Procter, student.
Description:-this use case allows to login into the system
Precondition:-those users should activate the system
Basic flow of event
1. Those users initiates login system

2. The user enters the name and password and click on login button
3. The system check the validity of the system
4. If the name and password are valid .the users will be logged to the system
5. Confirmation message will be display
Post condition:-those users should login successfully
Alternate course of action

1. Actors enter the name and pass word and click login button
2. System check the validity of the provided information
3. If the name and pass word are invalid
4. The system will display the ” error message “
5. The system asked to reenter the correct name and password

2014
UCI: UC6
Name: create account
Description: The Administrator creates the Procter username and password.
Actors: Administrator
Precondition: the Administrator doesn’t create user account.
Flow of Event:
1. The Administrator wants to create user account and password.
2. The system displays the create account Page.
3. The Administrator enters all of the required information. [A]
5. The Administrator will be de created the user account and password.
Post condition: the Administrator already created user account.
A1. The system displays data entry error messageA2. The system resumes at step 3.
4.2 Object Model
4.2.1 Class Diagram

 It represents the properties of entities, their operations and relationships. Also it
drives use case diagrams from use case.
 The class diagram is the main building block in our project modeling.
 It is used both for general conceptual modeling of the systematic of the application
and for detailed modeling translating the models into programming code.
 The classes in a class diagram represent both the main objects and or interactions in
the application and the objects to be programmed.
 Generally the project is including the following class in the class diagram the over
view of the class diagram is:-

2014
Block
Student BlockName : string
* 1 BlockNo : string
StdName : char Live
StdId : string Floor : int
Sex : char 1 View()
Allocate()
-Control De Allocate()
* -Assign
1
1 Proctor
ProName : string
ProId : string
ProAddress : string
CreateAccount()
DeletAccount()
1
UpdateAccount() * Administrator
register
Write -AdminName : string
-AdminId : long
Report * -AdminAddress : string
-Date 1 +CreateAccount()
+Write()
Fig4.2 Class diagram
4.3 Dynamic model
4.3.1 Sequence Diagrams
Sequence diagrams show the interaction between participating objects in a given

use case. They are helpful to identify the missing objects that are not identified in the
analysis object model.
To see the interaction between objects, the following describe the sequence diagram of
each Identified use cases.

2014
:PROCTOR
Allcation button :AllocatedPage :SearchDorm :AllocateDorm
clicks() display()
returnloginpage()
Enter( StuID&name,BlockNo,DormNo)
search(blockno,dormno)
ok()
returnValidation()
findfree(blockno,dormno)
allocationconfirmed()
ReturnAllocation(StuID&Name,Blockno,Dormno)
Fig-4.3 Sequence Diagram for Allocation

2014
Adminstrator :AccountButton :AccountPageForm AccountDB
:AccountControl
ClickButton()
Display()
ReturnForm()
Fill(Username,Password)
OK()
Validate()
ValidationOK()
StoreAccount()
AccountSaved()
AccountRegistered()
Fig-4.4 Sequence Diagram for Create Account

2014
:ViewButton :ViewPage :ViewControl DOrm DB
STUDENT
click()
Display()
this is View Page()
Fill(Student name,studID)
OK()
validatecheck()
validate OK()
search Record()
Display Record()
Display Dorm info(your dorm number is...)
Fig-4.5 Sequence Diagram for View Dorm

2014
:home page :login ctrl :login user list
users :login page
click button()
display()
enter un and pswd()
click ok button()
validate()
open()
login page success fully displayed()
Fig-4.6 Sequence Diagram for Login

2014
:s admin :home page :login page account ctrl form :acctpage :change acct form :DB
click login()
display()
enter UN and PSWD()
click ok() validate()
create()
click() display()
enter accunt name and psw to be changed()
click change button()
validate()
account successfully changed() account change()
Fig-4.7 Sequence diagram for Update Account

2014
:Home Page
:Login Page :DeleteAcctform :D Acct ctrl :DB
:Login control
Admin
click()
display()
Enter( UN& PW)
click login()
validate()
invalid()
open()
fill information()
delete ()
Check()
deleted()
User Account Deleted()
Fig-4.8 Sequence diagram Delete account
4. 3.2 Activity diagram

Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In activity diagrams can be used to
describe the business and operational step-by-step workflows of components in a system. An
activity diagram shows the overall flow of control.

2014
Generally the activity diagram of our project is look like this: -
Admin AUDMS
enter user name & psw
press login validate
loged in successfully invalid user name & psw try again
Fig-4.9 Login activity Diagram for Admin

2014
Proctor AUDMS
Login
ClickAllocationButon
DisplayAllocationPage
Fill(StuID&Name,BlockNo,DormNo)
IsEmpty?
Send
loged in successfully Allocate No
Fig-4.10 Allocation Activity Diagram

2014
Student:
Student Login
Check Student UN and PW

InValid
Valid
View Dorm
Fig-4.11 Student Activity Diagram

2014
Admnistrator:
Admnistrative Login
Check Admin UN and PW
Invalid
Valid
Select Task
Delete Account Change Account

Add Account
Fig-4.12 Administrator Activity Diagram

2014
Adminstrator Proctor Student
Login
CreatAccount
Login
ModifyAccount
DeletAccount
AllocatedDorm
Login
De AllocatedDorm
View
Fig-4.13 General Activity Diagram

2014
2014

Final Project

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Final Project

Загружено:

Авторское право:

Доступные форматы

CHAPTER ONE

1.2 Statement of the problem

 It is difficult to find which dorm (block) is allocated or de allocated.

1 Ambo University Online Dormitory Management System Industrial project I AmboU

1.3.1 General objectives

1.3.2 Specific objectives

1.4 Scope and limitation of the project

1.4.1 Scope of the project

1.4.2 Limitation of the project

The project we are developing has limitation on fields like:

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

2 Ambo University Online Dormitory Management System Industrial project I AmboU

1.4.3 Target groups and benefit of project

Is the way or mechanism in which we gather information to develop the system.

3 Ambo University Online Dormitory Management System Industrial project I AmboU

Benefits after implementation:

 Having information about the AmboUDM any time.

 Knowledge gain by project developer.

4 Ambo University Online Dormitory Management System Industrial project I AmboU

1.7 Project plan activities

5 Ambo University Online Dormitory Management System Industrial project I AmboU

Id Tasks Duration Predecessor Responsible

6 Ambo University Online Dormitory Management System Industrial project I AmboU

Description of the project

Fig-1.1 Gant chart

7 Ambo University Online Dormitory Management System Industrial project I AmboU

Our project organized in two main phases.

Fig-1.2 Decentralized Organization

8 Ambo University Online Dormitory Management System Industrial project I AmboU

This project emphasize on Dormitory service management system in Ambo University.

2.1 Description of current system

2.2 practices to be preserved from the existing system

2.2.1- Strength of the existing system

 Provide the required infrastructure to the students.

2.2.2- weakness of the existing system

9 Ambo University Online Dormitory Management System Industrial project I AmboU

2.3 Players in the existing system

 He/she is responsible for control the overall activities.

 He/she is a person who manages for each block of the students.

 They are users who accesses service from AUDM system.

2.4 Business Rules

 The student must be agreeing with their members of the dorm.

10 Ambo University Online Dormitory Management System Industrial project I AmboU

 Making the system fully manual

 Making the system partially automated

 Making the system fully automated

11 Ambo University Online Dormitory Management System Industrial project I AmboU

3.1Overview of Proposed System

Fig-3.1 Architecture of the System

12 Ambo University Online Dormitory Management System Industrial project I AmboU

3.3 Non Functional Requirements

Speed and Performance

When user makes some error:

 The system must have capacity for error handling.

 The system connects to personal computer within minimum period of time.

 The system should be tolerable of fault in case of SW and HW failure.

 The system should available for further use while needed.

13 Ambo University Online Dormitory Management System Industrial project I AmboU

 The system GUI should be consistent with all other programs.

Fig-3.2 User Interface

User Interface Description

14 Ambo University Online Dormitory Management System Industrial project I AmboU

 It is a core of user interface part.