Professional Documents
Culture Documents
UNIVERSITY-AFRICA
COURSE TITLE
WEB APPLICATIONS
DEVELOPMENT
COURSE CODE
: APP4050
SEMESTER/YEAR
: FALL/2013
TASK
GROUP PROJECT
TOPIC
PRESENTED TO
SUBMITED ON
BY
GROUP
NAME
ID NO
631448
RUSH KIRUBI
629964
631088
ABSTRACT
Manual management of hostels is challenging since it involves a lot of work load and time consumption.
The system we have developed can easily manage the hostel details which include: Student records, room
details, and an easy way of allocating the rooms. Main feature of this application is to enable users to
login and update their profile, while choosing the rooms of their choice online. The main tools used to
develop the application are MySQL database and Php scripting language.
2|Page
Table of Contents
1.
2.
INTRODUCTION ................................................................................................................................ 6
1.1.
1.2.
1.3.
1.4.
2.2.
2.3.
2.3.1.
3.
System Implementation......................................................................................................................... 9
3.1.
DATABASE IMPLEMENTATION............................................................................................. 9
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.2.
3.3.
Scripting ...................................................................................................................................... 10
3.3.1.
3.4.
5.
Introduction ................................................................................................................................. 12
4.2.
Purpose........................................................................................................................................ 12
4.3.
Scope ........................................................................................................................................... 12
4.4.
4.5.
References ................................................................................................................................... 13
4.6.
Overview ..................................................................................................................................... 13
5.1.1.
3|Page
System Interface.................................................................................................................. 13
5.1.2.
5.1.3.
5.1.4.
5.1.5.
5.1.6.
5.1.7.
Operations ........................................................................................................................... 15
5.1.8.
5.2.
5.2.1.
5.2.2.
Student Functions.................................................................................................................... 15
5.2.3.
5.3.
5.4.
6.
6.1.
6.2.
6.2.1.
6.2.1.1.
6.2.1.2.
View Applicants.............................................................................................................. 16
6.2.1.3.
6.2.1.4.
6.2.2.
Student Functions.................................................................................................................... 17
Profile.................................................................................................................................. 17
6.2.2.1.
6.3.
6.2.2.2.
6.2.2.3.
Status of Application....................................................................................................... 18
6.2.2.4.
6.2.2.5.
6.3.1.
6.3.1.1.
Login ............................................................................................................................... 19
6.3.1.2.
6.3.1.3.
4|Page
6.4.
6.4.1.
6.4.2.
6.4.3.
Standards Compliance......................................................................................................... 22
6.4.4.
Reliability ............................................................................................................................ 22
6.4.5.
Availability ......................................................................................................................... 22
6.4.6.
Security ............................................................................................................................... 22
6.4.7.
Maintainability .................................................................................................................... 22
6.4.8.
Portability ............................................................................................................................ 22
APPENDIXES ............................................................................................................................................ 23
Appendix A: (i) Project Task Schedule .................................................................................................. 23
Appendix A: (ii) Project Gantt Chart ...................................................................................................... 23
Appendix B: Database Relations ............................................................................................................ 23
Screen Shot of the users table ............................................................................................................. 23
Screen Shot of the students table ........................................................................................................ 23
Screen Shot of the rooms table ........................................................................................................... 24
Screen shot of the applicants table ...................................................................................................... 24
Appendix C: Web Interface .................................................................................................................... 24
Appendix D: Php Scripts ........................................................................................................................ 26
session.php .......................................................................................................................................... 26
functions.php....................................................................................................................................... 27
applyRoom.php ................................................................................................................................... 28
processProfile.php ............................................................................................................................... 31
profile.php ........................................................................................................................................... 32
Appendix E: Database Connection ......................................................................................................... 35
5|Page
1. INTRODUCTION
1.1. Scope Definition
The Hostel Management System is an online application which will capture all the management activities
involved with the hostels. The administrator module is concerned with all administration details, while
the student module is concerned with management of student details in regards to the hostel. Students are
allocated rooms based on their availability. The students module enables them to apply for a room, and
manage their details. They then check their application status to check whether a room has been allocated
to them. The systems database will capture both the administrator details, and the students details.
1.2. Existing System
The current system offers a manual method of application; in which students fill in a form and submit to
the hostel administrator, who then keys in the students details into the system. Rooms are manually
allocated by the hostel administrator. It has been noted that the allocation system is biased in the sense
that the hostel administrator allocates rooms to those he personally know. This manual system has shown
to be slow, time consuming, and inconveniencing to the students.
1.3. Proposed System
The proposed system tries to solve the problems highlighted in the problems of the manual system. The
students module will enable a student to login into the system, and apply for a preferred room, after
which they wait for online room allotment. The admin module enables the administrator to allocate rooms
to students. The system will ensure that any hostel property will be accounted for by the occupants of the
room, this way, when an item is damaged or lost, the occupants of the room will be held responsible. The
system is online based, hence accessible from anywhere, and enables bias to be eliminated. Hence
students get the opportunity to get accommodation in the hostel on time. Labor costs are minimized, since
the system is automated
1.4. Project Management strategy
Refer to appendix A (i) and (ii): Project task schedule, and Project Gantt chart respectively.
6|Page
Application
STUDENT
Application
Allocated/Rejected
HOSTEL MANAGEMENT
SYSTEM
Allocate/Rejected
HOSTEL
USERS
PK
USER_ID
STUDENTS
USERNAME
HASHED_PASSWORD
ADMIN
PK
PK,FK1
FNAME
LNAME
GENDER
PLACEOFRESIDENCE
PHONENUMBER
ADDRESS
PERSONALIMAGE
ROOMS
PK
ASSIGNED_ROOM_ID
LOCATION
CONDITION
APPLICATIONS
PK
PK,FK1
PK,FK2
APP_ID
STUD_ID
ASSIGNED_ROOM_ID
PREFERREDROOM
SEMESTER
YEAR
STATUS
7|Page
STUD_ID
USER_ID
Student can apply only up to one room, and rooms can have many applicants. Applications can have
many rooms and students.
2.3. Data Flow Diagram
2.3.1.
User Details
Verify User
User Details
User
Check
Application
Status
Applied User
Applied Room
Valid User
Apply Room
Room Application
Allocate Room
Applied Room
Receipt Payment
Bill Room
Payment
Finance
8|Page
3. System Implementation
The system is implemented using Apache web server, MySQL, and PHP. The administrator can access
the backend through PhpMyAdmin console provided by the Apache server.
3.1. DATABASE IMPLEMENTATION
The database is designed using MySQL database running on apache server. Each of the tables on the
database is identified by a unique primary key. Entities have been entered into their respective relations.
See appendix B: Database relations.
3.1.1.
TABLE: APPLICATIONS
COLUMN
PRIMARY DATA
NAME
KEY
TYPE
app_id
Yes
int(10)
stud_id
No
int(10)
preferredRoom
No
semester
No
year
No
year(4)
assigned_room_id No
Int(10)
status
3.1.2.
No
COMMENT
TABLE: ROOMS
COLUMN
PRIMARY
DATA
NAME
KEY
TYPE
room_id
Yes
int(11)
location
No
condition
No
type
No
3.1.3.
COMMENT
TABLE: STUDENTS
COLUMN
PRIMA
DATA
COMMENT
NAME
RY KEY
TYPE
stud_id
Yes
int(10)
fName
No
varchar2(3
0)
lName
9|Page
No
varchar2(3
0)
gender
No
varchar2(6)
placeOfResi
No
varchar2(4
dence
5)
phoneNumb
No
varchar2(2
er
0)
user_id
No
int(10)
address
No
varchar2(2
5)
personalIma
No
varchar(50)
ge
3.1.4.
TABLE: USERS
COLUMN
PRIMARY
DATA TYPE
COMMENT
NAME
KEY
user_id
Yes
int(10)
username
No
varchar2(20)
The username.
hashed_password No
varchar2(50)
admin
No
tinyint(1)
INDEX
STUDENT HOME
ADMIN HOME
PROFILE
ADD USER
APPLY ROOM
VIEW APPLICANTS
STATUS OF
APPLICATION
VIEW STUDENTS
VIEW
HISTORY
CHANGE
PASSWORD
11 | P a g e
12 | P a g e
4.6. Overview
This document is prepared in accordance with the IEEE Standards 830-1998, IEEE Recommended
Practice for Software Requirements Specifications.
Section 5.0 of this document gives a general description of HMS. It also provides product perspectives,
product functions, user characteristics, general constraints, and assumptions and dependencies of the
system.
Section 6.0 contains additional design details. It will contain functional and performance requirements,
design constraints, attributes and external interface requirements for the HMS.
5. General Description
This section describes the general factors that affect the HMS and its requirements. This part of SRS
provides a background for the requirements for ease of comprehension.
5.1. Product Perspective
5.1.1.
System Interface
The HMS is a complete web enabled system which can be accessed through web browser.
5.1.2.
User Interface
Description
Login
13 | P a g e
5.1.3.
Hardware Interface
Client Side
Any Personal computer, which can support any X-window or Windows environment with a mouse
support, is acceptable.
Server Side
HMS will be run on a web server, which is installed into the school server.
5.1.4.
Software Interface
Server Side
Apache Web server is installed and will enable HMS to interact with its users. PHP is a server-side
scripting language, which will be used to code the HMS.
Client Side
On the client side the required software product is Internet Explorer/Google Chrome/Mozilla Firefox
supporting at least HTML version 3.2, java enabled, and any operating system that can run the browsers.
5.1.5.
Communication Interface
The default communication protocol for data transmission between server and the client is Transmission
Control Protocol/ Internet Protocol (TCP/IP). At the upper level Hyper Text Transfer Protocol (HTTP)
will be used for communication between the web server and client.
14 | P a g e
5.1.6.
Memory Constraints
The client computer, which runs the web browser, should have enough physical memory to run this
program.
5.1.7.
Operations
Administrator of the system creates and defines the status of users by (Add User). The user will be
given a unique username and password. The Admin may change their passwords by (Change
Password). The Admin can view applicants and also view the students details.
The student accesses the system by logging in. They can view their profiles and update it (Profile),
Apply room, View Status of Application, View history and change their passwords.
5.1.8.
The school servers have requirements to operate PHP scripts (Apache Web server 1.3.2 with PHP 4.0
modules).
User Functions
The administrator of HMS shall add new users to the system who is basically the student. After
entering the information about the user, the system gives a unique username and password to the
user.
The administrator shall view applicants and students, and change password.
5.2.2.
Student Functions
The student shall view their history and change their password.
5.2.3.
User Characteristics
The Administrator
This user has to have at least Window 7/Linux OS and Internet browsing skills for administrating HMS
user profiles.
15 | P a g e
The Student
This user has to have at least Window 7/Linux OS and Internet browsing skills to use the system.
5.3. General Constraints
Academic rules and IEEE standards have to be observed throughout the entire requirements process.
5.4. Assumptions and Dependencies
The system will not store any payment information; rather all payments will be handled by the
finance department of the university.
Credit card payment or any other form of payment other than through the finance department is
not allowed on the system.
6. Specific Requirements
6.1. External Interface Requirements
The HMS uses the standard input/output devices for a personal computer. This includes the following:
Keyboard, Mouse, Monitor and Printer.
6.2. Functional Requirements
6.2.1.
Administrator Functions
Process: The administrator selects the semester and year. The function queries the database for the
students who have applied for rooms.
Output: All applicants with their respective details (user id, preferred room, and assigned room id) will
be displayed.
6.2.1.3. View Students
Introduction: HMS shall display all the students in the system.
Input: none
Process: When the administrator logon the system, automatically, all student list is displayed. The
function queries the database for all the students.
Output: List of all students with their respective details (student id, first name, and last name, and
gender, place of residence, phone number, and address) will be displayed.
6.2.1.4. Change Password
Introduction: HMS shall enable administrator to change the password.
Input: old password, new password, confirm password
Process: Administrator activates the function to change the password. The new password and confirm
password fields are entered. If they match, the old password will be updated with the new one.
Output: Error or confirmation message will be displayed.
6.2.2.
Student Functions
6.2.2.1. Profile
Introduction: HMS shall enable student to view and update their profile.
Input: none
Process: By this function, the database is queried for all the personal information of the student.
Output: All students personal information is displayed.
6.2.2.2. Apply Room
Introduction: HMS shall enable a student to apply a room.
Input: preferred room, semester, and year.
17 | P a g e
Process: By this function, the selected information is stored into the database.
Output: All students application information is stored into the database
6.2.2.3. Status of Application
Introduction: HMS shall enable the student to view the status of their room application.
Input: student id
Process: By this function, the database is queried for all the room application information of the student.
Output: All application status is displayed.
6.2.2.4. View History
Introduction: HMS shall enable the student to view their previous application history.
Input: student id
Process: By this function, the database is queried for all the previous room application information of the
student.
Output: All room application history is displayed.
6.2.2.5. Change Password
Introduction: HMS shall enable student to change the password.
Input: old password, new password, confirm password
Process: student activates the function to change the password. The new password and confirm password
fields are entered. If they match, the old password will be updated with the new one.
Output: Error or confirmation message will be displayed.
18 | P a g e
6.3.1.1. Login
Use Case
Login
Name
Introduction
This use case describes how a user logs into the HMS.
Actors
Pre-
None
Conditions
Basic Flow
This use case starts when the actor wishes to login to the HMS which requests that the
actor enter his/her username and password. The actor enters his/her username &
19 | P a g e
password. System validates username and password, and if finds correct allow the
actor to log into the system.
Alternate Flow
Invalid name and password. If in the basic flow, the actor enters an invalid name and/or
password, the system displays an error message.
The actor can choose to either return to the beginning of the basic flow or cancel the
login, at that point, the use case ends.
Post-Condition If the use case is successful, the actor is logged into the system. If not, the system state
is unchanged.
Introduction
This use case allows the administrator to maintain user account. This includes
adding, viewing applicants, view students and changing passwords.
Actors
Administrator
Pre-Conditions
The administrator must be logged on to the system before the use case begins.
Post-Condition
If the use case was successful, the user is added, applicant information is viewed,
view student details, and admin can change his/her password. Otherwise, the system
state is unchanged.
Basic Flow
This use case starts when the Administrator wishes to add a user, view applicant,
view student, and change his /her password.
The system requests that the Administrator specify the function he/she would like to
perform (Add User, View Applicant, View Student, or Change Password).
Once the Administrator provides the requested information, one of the sub-flows is
executed
If the Administrator selected Add User, the Add User sub flow is executed.
If the Administrator selected View Applicant, the
20 | P a g e
User Not Found: If a user account with the specified details does not exist, the
system displays an error message. The Administrator can then enter a different User
name or cancel the operation, at which point the use case ends.
Post-Condition
The system shall add, view applicant, view student, and change password.
Introduction
Allows the student to manage their various activities. This includes View Profile,
Apply Room, View Status of Application, View History, and Change Password.
Actors
Student.
Pre-Conditions
Post-Condition
If use case is successful, the student can view their profiles, apply room, view status
of application, view history and change password. Otherwise the system state is
unchanged.
Starts when student wishes to view Profile, Apply Room, view Status of Application,
Basic Flow
and Change Password. The system requests the Student to specify the function;
he/she would like to perform.
Alternate Flow
Post-Condition
The system shall view Profile, Apply Room, view Status of Application, and Change
Password for the student.
Performance Requirements
Performance requirements define acceptable response times for system functionality. Depending on the
user internet connection speed;
21 | P a g e
The load time for user interface screens should take no longer than two seconds.
6.4.2.
Design Constraints
The system is an online web application which runs on any operating system platform. It is developed
using PHP, HTML5 and MYSQL database.
6.4.3.
Standards Compliance
There is consistency in variable names within the system. The graphical user interfaces have a consistent
look and feel.
6.4.4.
Reliability
The system database connectivity has been designed with a persistent connection to ensure system
reliability. The system runs on a dedicated server to ensure that it is reliable at all times.
6.4.5.
Availability
The system is available at all times, but a room application is open at the beginning of every semester to
ensure that rooms are available.
6.4.6.
Security
The system has an authorization mechanism for users to identify their personal profiles. Therefore,
different users will have different authorization levels to access the data. The system should utilize certain
cryptographic techniques for instance SHA1 algorithm, encrypting passwords.
6.4.7.
Maintainability
The system is developed using PHP, and PHP is a cross platform programming language which is easy to
maintain. Most of the PHP variables are global variables.
6.4.8.
Portability
22 | P a g e
APPENDIXES
23 | P a g e
24 | P a g e
25 | P a g e
<?php
26 | P a g e
include("includes/functions.php");
session_start();
function confirmLogIn(){
if(!logged_in()){
redirect_to("index.php");
}
}
function logged_in(){
return isset($_SESSION['user_id']);
}
?>
functions.php
<?php
$mainPage=false;
function mysql_prep( $value ) {
$magic_quotes_active = get_magic_quotes_gpc();
$new_enough_php = function_exists( "mysql_real_escape_string" ); // i.e. PHP >= v4.3.0
if( $new_enough_php ) { // PHP v4.3.0 or higher
// undo any magic quote effects so mysql_real_escape_string can do the work
if( $magic_quotes_active ) { $value = stripslashes( $value ); }
$value = mysql_real_escape_string( $value );
} else { // before PHP v4.3.0
// if magic quotes aren't already on then add slashes manually
if( !$magic_quotes_active ) { $value = addslashes( $value ); }
// if magic quotes are active, then the slashes already exist
}
return $value;
}
function redirect_to( $location = NULL ) {
27 | P a g e
if ($location != NULL) {
header("Location: {$location}");
exit;
}
}
function confirm_query($result_set) {
if (!$result_set) {
die("Database query failed: " . mysql_error());
}}?>
applyRoom.php
<?php
$title="HMS | Admin - Apply Room";
require_once("includes/session.php");
confirmLogIn();
include("includes/header.php");
include("includes/connectDb.php");
//save details in applications table
if(isset($_POST['submit'])){
extract($_POST);
$query="INSERT INTO applications(stud_id, preferredRoom,semester,year,status)
VALUES('{$_SESSION['stud_id']}',
'{$pRoom}','{$sem}','{$year}','NOT ASSIGNED')";
$result=mysql_query($query,$connection);
confirm_query($result);
mysql_close($connection);
echo "<h3>Application successful!</h3>";
echo "<table class='pull-center'><tr><th>Preferred
Room</th><th>Semester</th><th>Year</th><th>Status</th><tr>";
28 | P a g e
echo "<tr><td>{$pRoom}</td><td>{$sem}</td><td>{$year}</td><td>NOT
ASSIGNED</td></tr></table>";
}
?>
<form class="applyRoom" action="applyRoom.php" method="post">
<label>Preferred Room</label><select name="pRoom">
<option>------</option>
<option>Single</option>
<option>Double</option>
</select>
<label>Semester</label><select name="sem">
<option>------</option>
<option>Spring</option>
<option>Fall</option>
<option>Summer</option>
</select>
<label>Year</label><select name="year">
<option>------</option>
<option>2013</option>
<option>2014</option>
<input class="btn btn-success" type="submit" name="submit" value="Apply Room" />
</select>
</form>
<?php include("includes/footer.php");?>
processRooms.php
<?php
include("includes/session.php");
29 | P a g e
include("includes/connectDb.php");
$counter=0;
$names=array('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z');
if(isset($_POST['confirmRooms'])){
// extract($_POST);
//
echo $_POST['app'];
30 | P a g e
confirm_query($result);
$counter++;
}
}
redirect_to("viewApplicants.php");
}
processProfile.php
<?php
include("includes/session.php");
require_once("includes/connectDb.php");
$target=NULL;
if(isset($_FILES['fUpload'])){
if($_FILES['fUpload']['type']=='image/png'||$_FILES['fUpload']['type']=='image/jpeg'){
$source=$_FILES['fUpload']['tmp_name'];
$target="images/profile/".basename($_FILES['fUpload']['name']);
$targetName=basename($_FILES['fUpload']['name']);
if(move_uploaded_file($source, $target)){
saveOtherDetails($targetName,$connection);
print("File uploaded successfully");
}
else{
if($_FILES['fUpload']['error']==UPLOAD_ERR_NO_FILE){
saveOtherDetails($targetName);
}
echo $_FILES['fUpload']['error']."<br />";
}
//$size=getImageSize($target);
// $imgstr="<p> <img width=\"size[0]\" height=\"size[1]\" ";
31 | P a g e
confirmLogIn();
require_once("includes/connectDb.php");
include_once("includes/functions.php");
include("includes/header.php");
$user_id=$_SESSION['user_id'];
$query="SELECT * FROM students WHERE user_id={$user_id} LIMIT 1";
$result=mysql_query($query);
confirm_query($result);
if(mysql_num_rows($result)==1){
$found_student=mysql_fetch_array($result);
}
?>
<div class="span3 offset9">
<?php
echo "<legend>Student Profile</legend>";
$html="<form method=\"post\" action=\"processProfile.php\" enctype=\"multipart/form-data\">";
$html.="<label>Upload profile picture</label><input type='hidden' name='MAX_FILE_SIZE'
value='2000000' /> <input type='file' name='fUpload' value='' size='60'/><br />";
$html.="<label>First Name</label><input type=\"text\" name=\"fname\"
value=\"{$found_student['fName']}\" />";
$html.="<label>Last Name</label><input type=\"text\" name=\"lname\"
value=\"{$found_student['lName']}\" />";
$html.="<label>Address</label><input type=\"text\" name=\"address\"
value=\"{$found_student['address']}\" />";
$html.="<label>Gender</label>";
$html.="<select name='gender'>";
if($found_student['gender']=='Male'){
$html.="<option selected='selected'>Male</option>";
$html.="<option>Female</option>";
}
33 | P a g e
else if($found_student['gender']=='Female'){
$html.="<option selected='selected'>Female</option>";
$html.="<option>Male</option>";
}
else {
$html.="<option>Male</option>";
$html.="<option>Female</option>";
}
$html.="</select><br />";
$html.="<label>Place of Residence</label><input type=\"text\" name=\"pOfRes\"
value=\"{$found_student['placeOfResidence']}\" />";
$html.="<label>Phone Number</label><input type=\"text\" name=\"pnumber\"
value=\"{$found_student['phoneNumber']}\"/>";
$html.="<input type=\"submit\" name=\"submit\" value='Save' class=\"btn btn-success\"/>";
$html.="<input type=\"reset\" name=\"reset\" value='Clear' class=\"btn btn-info\"/>";
$html.="</form>";
if(isset($_POST['submit'])){
echo $html;
}
if(!isset($_POST['submit'])){
if($found_student['personalImage']==NULL){
$html="<img class='pull-left' src='images/doe.png' />";
}
else if($found_student['personalImage']!=NULL){
$html="<img class='pull-left' height='250' width='250'
src='images/profile/"."{$found_student['personalImage']}' />";
}
$html.="<table class='profile'>";
$html.="<tr><td><strong>First
Name</strong></td><td><span>{$found_student['fName']}</span></td></tr>";
34 | P a g e
$html.="<tr><td><strong>Last Name
</strong></td><td><span>{$found_student['lName']}</span></td></tr>";
$html.="<tr><td><strong>Address</strong>
</td><td><span>{$found_student['address']}</span></td></tr>";
$html.="<tr><td><strong>Gender</strong>
</td><td><span>{$found_student['gender']}</span></td></tr>";
$html.="<tr><td><strong>Place of
Residence</strong></td><td><span>{$found_student['placeOfResidence']}</span></td></tr>";
$html.="<tr><td><strong>Phone
Number</strong></td><td><span>{$found_student['phoneNumber']}</span></td></tr>";
35 | P a g e
36 | P a g e