Hostel Information System (HISYS)

PP rroo jj eecctt RReeppoo rr tt

SUBMITTED IN PARTIAL FULFILMENT OF THE DEGREE OF

MASTER OF COMPUTER APPLICATIONS

By

Sidh Nath Singh (Y2M005)

Under the Guidance of

Abdul Nazeer K A

Department of Computer Engineering

National Inst i tute of Technology Calicut NIT CAMPUS P.O, KOZHIKODE 673601, KERALA

APRIL - 2005

Certificate

This is to certify that the this project report entitled ‘Hostel Information System (HISYS)’, is a

bona-fide record of the work done by Sidh Nath Singh, a student in the Department of

Computer Engineering, National Institute of Technology Calicut from December 2004 to April

2005 in partial fulfilment for the award of the degree of Master of Computer Applications of the

National Institute of Technology, Calicut.

Guide: Head of the Department

Mr. Abdul Nazeer K A Dr. V K Govindan Lecturer (SS) Professor and Head

Dept of Computer Engineering Dept of Computer Engineering

NITC NITC

Acknowledgement

I am deeply indebted to my project guide Mr. Abdul Nazeer K A, Lecturer (SS), Department of

Computer Engineering, National Institute of Technology, Calicut, for his excellent guidance and

suggestions during entire period of the project work. He is the one who saved not only my effort

involved in this project but also made this a successful one by making it good looking, more

informative, and above all simple to use. Whatever I say will be less. I am once again very much

thankful and grateful to him.

I express my heartiest thanks to our project coordinator Dr. Vineeth Kumar Paleri, Asst.

professor, Department of Computer Engineering, National Institute of Technology, Calicut for

his continuous, timely, and invaluable suggestions during project work. He can be regarded as a

‘Man Behind Timely Success.’

I express my sincere thanks to Mr. Saidalvi Kalady whose single presence was enough to give a

proper direction to my project work. His suggestions during mid-term evaluation were simply

great which helped me in betterment of my project. His suggestions played very important role in

simplifying my work.

I will also be thankful to Dr. V. K. Govindan, Professor and Head, Dept of Computer

Engineering, National Institute of Technology, Calicut whose presence behind all the COE

students helps them in a great way.

I am also thankful to my classmates, especially, Sandeep and Ajesh who were always with me

to help me out of the problems I faced with during this project work.

Last but not the least I will be thankful to my Lord “Sri Krishna”.

Sidh Nath Singh

Abstract

This Project entitled “Hostel Information System (HISYS)” is a web-based project, which serves

two major purposes. First, it gives a site for each hostel and also provides various information

about a hostel or a student related to a hostel. Second, it provides various facilities to the hostel

administration such as recording students’ personal information when they first register for the

hostels, updating them as well as deleting if necessary. These facilities also include storing

information about students when they change their hostels, creating a hostel-account for students

when they first join a hostel. But this account will be activated only when they first join a hostel.

It also maintains a list of current hostel inmates on individual hostel basis as well as all together.

Along with this, HISYS provides information pertaining to all previous inmates who no longer is

a part of NITC hostels.

Now, from the prospective users’ point of view, this software provides five different types of

facilities. Firstly, it is the chief administrator who is privileged to use all the above-mentioned

facilities. Second, it is the separate administrator for each hostel who takes care of students

joining and leaving the hostel, only updating personal information of students, generating a list

of hostel- inmates for his/her hostel, and generating all complaints for that hostel. Third, it is the

maintenance office administrator who can also generate a list of complaints but has been

privileged for all hostels. Apart from this only he (and chief administrator) can check off the

complaints, which have been repaired. Fourth, it is NITC Hostels inmates who possess their

respective user accounts mentioned above and avail the facilities like viewing their personal

profiles, viewing their respective hostel details, posting complaints through Web, comprehensive

web-search for the NITC hostels, and changing their account details mainly password. Fifth

category of users are outsiders, who, apart from having each hostel details provided in the site

(which is open to all), is having search (limited) facility through which they can exactly locate a

particular student in NITC hostels except first years and girls.

Contents

1 Introduction...........................................................................................................................7 1.1 Purpose................................................................................................................................... 8

1.2 Scope...................................................................................................................................... 8

1.3 Overview of the Report.......................................................................................................... 8

2. System Overview...................................................................................................................8 2.1 Students’ Information Management ...................................................................................... 9

2.2 Hostels’ Complaints Management ....................................................................................... 10

2.3 Hostels’ Inmates List Generation......................................................................................... 10

2.4 Hostel Web-Site Maintenance and Information Processing ................................................ 10

2.5 Who is responsible for all these? ......................................................................................... 11

3. System Analysis...................................................................................................................12 3.1 Functional Requirements ..................................................................................................... 12

3.2 Problem Definition............................................................................................................... 12

3.3 General Constraints.............................................................................................................. 13

3.4 Operational Requirements.................................................................................................... 14

3.5 Interface Requirements ........................................................................................................ 14

3.6 Non-Functional Requirements ............................................................................................. 14

4 System Architecture ...........................................................................................................15 4.1 Architectural Description..................................................................................................... 15

4.2 Architectural Alternatives.................................................................................................... 16

4.3 Design Rationale .................................................................................................................. 16

5. Design...................................................................................................................................16 5.1 Use-Case Diagrams.............................................................................................................. 17

5.2 Class Diagram...................................................................................................................... 18

5.3 Sequence Diagrams.............................................................................................................. 19

5.4 Database Tables ................................................................................................................... 20

5.5 Entity-Relationship Diagram ............................................................................................... 21

6. Implementation...................................................................................................................22 6.1 Introduction.......................................................................................................................... 22

6.2 Languages and Tools Used .................................................................................................. 22

6.3 Implementation Issues.......................................................................................................... 25

7. System Testing ....................................................................................................................27 7.1 Introduction.......................................................................................................................... 27

7.2 Testing Methods................................................................................................................... 28

8 Maintenance ........................................................................................................................29

9 Conclusion...........................................................................................................................30 9.1 Features of the system.......................................................................................................... 30

9.2 Scope for future work .......................................................................................................... 30

10 References............................................................................................................................31

Appendices....................................................................................................................................33 Appendix-A : Screen Shots........................................................................................................... 33

Appendix-B : Database Tables ..................................................................................................... 41

Appendix-C : Database Views ...................................................................................................... 44

1 I n t r o d u c t i o n

In this world of web or so-called age of Internet, we want all information about

everything to be available on the Internet. NIT Calicut, a premier technical institution in

India is of course not an exception. Everything or more appropriately almost all the

things are there in the NITC web site. But as everyone know NITC is a residential

institution and in every institution, residences are supposed to be of utmost important

especially if it comes to students’ hostels. At this juncture something was missing from

NITC official web site http://www.nitc.ac.in. There was information about NITC hostels

but it wasn’t full fledged. This project has been undertaken with that viewpoint. HISYS

has tried its best to provide most of the information for various user-group.

This will help people staying outside NITC Campus to locate their wards and to know

their cur rent where about. Even in this campus, as we know we need some information

about our friends, which we may not be having at some particular moment of time,

HISYS will be of some help. Not only this, this will help hostel administrators to

automate their various activities such as after room-allotment, maintaining students’

personal information, maintaining their hostel information, maintaining their

user-accounts, generating their hostel-wise lists, generating and reporting their various

hostel-wise complaints, and repairing and checking them off through net, etc. This and

some more work Apart from administrative people, HISYS provides some facilities to

NITC Hostel’s Student Community. It provides them separate user accounts, which will

enable them to see their various personal and hostel profiles maintained in this NITC

Hostel office, post a complaint through Internet, change their respective password, and

have a comprehensive search facility.

This will provide a real new look to the NITC official web site. Now let’s go through the

detail aspect of HISYS:

1 Purpose

2 Scope

3 Overview

1.1 Purpose

The purpose of this document is to lay out the design of the hostel information system,

which belongs to NITC hostels. This document will discuss the type of data that the

system will process, as well as the way the data will be stored, processed and reported.

This document will also show the task to be done in Object-Oriented manner, starting

with a high- level approach down to various in-depth details.

1.2 Scope

The scope of this document is to present to the various groups of users of this application

for their respective use. It is such that it helps the designer of the project to understand

this application. It also helps the programmer to go for particular coding methodology. It

also serves purposes to the end-users how to use the delivered software.

1.3 Overview of the Report

This document contains an overview that explains the system design. There are also

sections on the architecture of the HISYS as well as its design, which will show the

major components of the application and the data storage to be used, respectively. The

computer specifications that the client needs to run the application will also be discussed.

2 . S y s t e m O v e r v i e w

The system can be described in the following way:

1. Overview of post-allotment students’ hostel information management

2. Overview of complaints management from each Hostel

3. Overview of Generating monthly list of inmates of each hostel

4. Maintaining web sites and providing web-based information processing for each

hostel

5. Who is responsible for all these?

2.1 Students’ Information Management

This software handles the management work ‘after’ the allotment of students to various

hostels. Here three things are taken care of:

• Students’ persona l information

• Students’ information for all the hostels

• An account for each student that enables him/her

§ To post a complaint through Internet

§ Change his/her password

§ To make a comprehensive search for all hostels

This part of job is mainly under the control of Chief-Administrator and separate

Administrator for each hostel. Where Chief-Administrator can handle all these jobs,

respective Hostel-Administrator will handle only that particular hostel information for

students such as hostel joining and vacating information, and only updating the personal

information, etc.

Now, when students have to join any hostel, they will first be registered in the hostel

administrative office. Here, their personal data will be recorded and then they will be

given one account consisting of one User ID, which are nothing but only their Institute

Roll and one password, which they can change it later. But this account will be activated

only after they got into any hostel i.e., their particulars for that hostel are entered in that

hostel database.

Now once they are in a particular hostel, their account will enable them to change the

password if they wish. Another thing they can do is to write complaint through net where

they will be asked only the complaint-text, and rest of the ir information like their Room

No., Hostel, date, etc. will be fetched from the database. But above all they will be

entitled to do comprehensive search on student community of NITC hostels. This search

can give them information regarding mailing address of all student as well as their current

staying in the NITC hostels.

2.2 Hostels’ Complaints Management

In this particular functionality, system records the complaints sent by students staying in

the different hostels through net in a complaint database reserved for each hostels. Here

the Serial Number of each complaint is automatically generated by the system. Now, the

Chief-Administrator, Respective Hostel-Administrator, and Maintenance Administrator,

anyone, can generate the printed reports of pending list of complaints. And after

repairing, only Chief-Administrator and Maintenance-Administrator can check it off to

prevent it from getting reported again.

Briefly,

• Student with an account can post a complaint on Internet

• And, Maintenance Staff can

♦ Generate a list of reports of pending complaints

♦ Check a complaint off after repairing

2.3 Hostels’ Inmates List Generation

Chief-Administrator and Respective Hostel-Administrator will handle this functionality.

They can generate list of hostels’ current inmates and send it to hostel office for various

verification and validation done on interval basis. This can also help these people see

students’ where about, generate mailing list, etc.

2.4 Hostel Web-Site Maintenance and Information Processing

This will be dealing with creation of web sites for each hostel with various information

related to that hostel such as Student Council, Photo Gallery, Magazine Detail, Events,

and News, etc. It also includes searching for a particular student with his/her roll number,

name and/or hostel.

The interesting thing with this part is that it is open to everyone and no login is required.

2.5 Who is responsible for all these? Above I have talked much about who is responsible for which type of work but without

putting every job profile together I think my report will not be complete. So here is the

summary of all the above-mentioned profiles.

Nature of Job User Type

Students’ personal Info Entry Chief-Administrator

Students’ personal Info Deletion Chief-Administrator

Students’ personal Info Updating Chief-Administrator,

Students’ Current Hostel-Administrator

Students’ User-Account Creation Chief-Administrator

Students’ User-Account Updating Chief-Administrator

Students’ User-Account Deletion Chief-Administrator

Students’ Hostel Joining Info Entry Chief-Administrator,

Students’ Current Hostel-Administrator

Students’ Hostel Leaving Info Entry Chief-Administrator,

Students’ Current Hostel-Administrator

Generate Student List Chief-Administrator (for all hostels),

Hostel-Administrator for that Hostel only

Generate Complaint List Chief-Administrator (for all hostels),

Hostel-Administrator for that Hostel only

Check Off Complaints Chief-Administrator (for all hostels),

Maintenance-Admin for that Hostel only

Nature of Job

Change Password

Post Complaints

Comprehensive Search

Administrators

Students

The System Overview is shown in fig-1 as follows:

User

Fig 1: - System Overview 3 . S y s t e m A n a l y s i s

3.1 Functional Requirements

1) Administrators should be able to Create, Update, and Delete Students’ personal

Information, hostel information, and account information.

2) Administrators should be able to generate report of students, complaints and update

these if necessary.

3) Students should be able to change their own password, view their own profile, post a

complaint, and get almost all information about other students.

4) There should be facility for outsiders to locate a student in NITC Hostels.

5) There should be site maintained for providing general information related to a

particular hostel as well as common information related to all hostels.

3.2 Problem Definition

This is a web-based software application, which incorporates the following feature:

• Managing post-allotment students’ hostel information

- Students’ personal information

- Students’ information for all the hostels

HISYS

S t u d e n t

Administrator

Report Database

- An account for each student that enables him/her

§ To post a complaint through internet

§ To make a comprehensive search for his/her hostel

• Managing complaints from each Hostel

- Student with an account can post a complaint on Internet

- And, Maintenance Staff can

§ generate a list of pending complaints

§ check it off after repairing

• Generating monthly list of inmates of each hostel

• Maintaining web sites and providing web-based information processing for each

hostel.

- Provides information for

§ Hostel

§ Student

§ Room and its various occupants (current & Previous)

§ Student and their various hostels (current & Previous)

3.2.1 Inputs

1) Students’ Data

2) Complaints from the students

3) Mouse click on the link

3.2.2 Output

1) Reports related to students

2) Reports related to pending complaints

3) Opening of desired web pages

3.3 General Constraints

This system although will be trying to verify the data at input point, it assumes that user

enters correct data. And signs out the system after using it. This application uses Session

variable for managing the password so these information will be available only for that

particular session. After that he/she has to log in to the system again for reusing it.

3.4 Operational Requirements

3.4.1 Software Requirements

At client side Java Enabled Web-Browser

- At Backend JSP Server Technology, Servlet Container such as Tomcat Apache,

Oracle 9i Database

3.4.2 Hardware requirements

- Pentium-III and onwards for fast and better use of the Application

- 128 MB of RAM

- 5 GB of Hard Disk

3.5 Interface Requirements

- User Interfaces

- Here the interfaces for the user group should be web page itself, where they can

see, and do data manipulation type of work.

- Communication Interface

- For this purpose HTTP-Hyper Text Transfer Protocol will be used.

3.6 Non-Functional Requirements

3.6.1 Security

The security feature in this system will be implemented by providing Login and

Passwords to various user groups like chief-administrator, hostel-administrator, and

students. And since their login will valid only for a particular session (until windows are

closed) this feature should be more promising. IP-Based Security can be implemented in

near future to restrict some of the pages to be available outside this campus.

3.6.2 Maintainability

The system should be fault- free and providing services without any problem. But in case

if there arises any problem after its implementation and while in use, finding and

debugging should be easier. For that some programming conventions should be adopted

as a usual practice. These include proper indentation of codes, naming conventions for

variables and functions provided in the form, scripting-code, server-side coding, and also

for file-names.

3.6.3 Portability

One who is having Internet connection and Java enabled web browser can use this

software on Linux and Windows platforms.

3.6.4 Extensibility

Apart from the coding technique files and directory or software component should be

managed in such a way that an independent set of code fulfilling just the basic

requirement for web site can be added and also removed if necessary without affecting

much to the others.

3.6.5 Serviceability

Since most of the tasks should be simple enough to provide services in an easy and

efficient way. And in case, if fault occurs, system can be recovered within a short time

span.

4 S y s t e m A r c h i t e c t u r e

4.1 Architectural Description

The architecture of the HISYS can be seen in Fig-2. The user will enter students’ various

information into the GUI interface, which will send the information to a database where it

will be stored. The user will also be able to view the information that is being stored in

the database through the interface. When the user wants to run a report on the students’

various information it’ll be fetched from the database and put into a report format for the

user to view.

4.2 Architectural Alternatives

The only other architecture that I considered was ASP technology. The reason I chose

JSP is because of the fact of portability and security of web pages.

4.3 Design Rationale

I decided to go with JSP technology for a couple of reasons. First, JSP technology is

designed to be platform independent. And second, it can run on any server including

Apache, IIS, or Netscape. Further, JSP technology has been created for the input from

broader community of tools, server, and database vendors. In contrast, ASP is a

Microsoft technology that relies mainly on Microsoft technology.

5 . D e s i g n

In this section a detailed design issue has been considered starting from Use-case

Diagrams, Class-Diagrams, and Sequence-Diagrams, Database-Tables up to Entity-

Relationship Diagram.

Reporting Complaint & Student List

Storing & Updating Student

HISYS

Repository User

Interface

Fig 2: - Report Generation

5.1 Use-Case Diagrams

5.1.1 Students’ Information Management 5.1.2 Handling Complaints from Students

Enter Students’ Personal Info Student Staff

Enter Students’ Hostel Info

Create a Students’ User

Check for First Time Hostel Inmate

<<extends>

Update a Students’ User

Repair & Check-off Pending Complaints

Write Complaint

Student

Generate Complaints’ List

<<uses>> Maintenance

Staff

5.1.3 Browsing the Site 5.1.4 Searching the Database 5.2 Class Diagram

Check for Required Privilege

Request for Page

User <<extends>>

Check if Privileged Page

<<extends>>

Check for Administrator

Enter Query

User

<<extends>>

Show result

<<uses>>

Student Hostel Occupying Occupies

1..*

OccupiedBy

0..*

ContainedBy

Containing

0..*

Complaining

Complains

1..1

1..1 Maintenance

Office

ComplainedBy

1..1

Contains

5.3 Sequence Diagrams

5.3.1 Students’ Information Management 5.3.2 Complaints from Students

Hostel Staff

:Student :Hostel

FoundStudent() new(Student)

EnterPersonalData(), EnterNewHostelData()

loop [For Each New Student] CreateUser()

Status

EnterNewHostelData() [For Each Old Student] UpdateUser()

System :Student

validateStudent() new(Student)

PostComplaint()

Status

5.3.3 Maintenance Office Checking Off Complaints 5.3.4 Browsing the Site and Searching the Database 5.4 Database Tables

This application will be using all together 26 tables and 2 views. There are 11 tables for

students in each of the 11 hostel and 11 tables for storing complaints from each hostel.

One table is for students’ personal information, one is for hostels’ information, one is for

Administrators’ login details, and one is for students’ login details. First view contains

hostel information about all the hostel- inmates, and second contains information about

the current-students. For detail structure of table please see Appendix-B and for views

Appendix-C.

System :Staff

ValidateStaff()

CheckOff()

Status

System :Server

validateUser() new(Query)

Result

5.5 Entity-Relationship Diagram

STUDENT

StudName

DOB

Stud_Roll TotalRooms HostelID

Sex

Address

OCCUPIES HOSTEL

DOJ

COMPLAINT

COMPLAINS BELONGSTO

ComplnID

TotalFloors StartDate

ComplaintText

6 . I m p l e m e n t a t i o n

6.1 Introduction

This project’s implementation spans across four phases where the detailed design is

transformed into the executable form.

1) Designing and developing general or open web pages. Providing information in those

pages, which can be made available to everyone.

2) Designing and developing Secure pages that which can be accessed only by

authorized people.

3) Providing proper interlinking of secure and open pages, so that people from can

traverse from secure to open page but reverse is prohibited.

4) Respective functionalities were added to open and secure pages.

6.2 Languages and Tools Used

6.2.1 Macromedia Dream Weaver MX

It is a powerful WYSIWYG (What You See Is What You Get) authoring software from

Macromedia enabling easy creation of sites containing graphics and multimedia

elements. It is one of the best programs for creating JavaScript and DHTML animations.

Of all the WYSIWYG Editors out there, Macromedia's Dreamweaver has consistently

been reviewed the best. The clean code it produces as well as its hands off approach

makes it among the most popular editors for web developers.

Instead of spending hours writing HTML tags to code a complex table, the developer can

build the table, resize it, and view it exactly as it will appear on a Web page. There is no

chance that a person will omit a tag or create table cells that are the wrong size because

the developer works visually. Dreamweaver generates the correct code for the table.

Similarly, Dreamweaver will generate code for rollovers, image maps, and animated

layers. With a tool like Dreamweaver, coding these elements was a time consuming

detailed task. Dreamweaver's development environment integrates other development

tools such as Fireworks, Flash, and Aria.

6.2.2 HTML

HTML is an acronym for Hyper-Text Markup Language. A markup language based on

but simpler than SGML (Standard Generalized Markup Language) used to annotate

hypertext documents for publication on the World Wide Web, to take advantage of the

WWW’s capacity to connect documents and sections of documents across the Net. It is a

document format language used on the World Wide Web. It is a language that specifies

how text will be formatted and displayed in a web browser, such as Netscape or Internet

Explorer. So in a very simple way we can say that Hypertext Markup Language (HTML)

is programming language used in the creation of Web pages.

6.2.3 JavaScript

JavaScript is a scripting language developed by Netscape to enable Web authors to

design interactive sites. Although it shares many of the features and structures of the full

Java language, it was developed independently.

JavaScript can interact with HTML source code, enabling Web authors to spice up their

sites with dynamic content. JavaScript is endorsed by a number of software companies

and is an open language that anyone can use without purchasing a license.

It is supported by recent browsers from Netscape and Microsoft. Though Internet

Explorer supports only a subset, which Microsoft calls JScript.

JavaScript is not the same as Java as some people tend to think it is. Rather it is a

computer language that is a subset of the Java programming language but is easier for

nonprogrammers to write.

JavaScript programs are run in the web browser on the client side rather than on the

server. JavaScript is a programming or script language, which can be imbedded in Web

pages and read by the browser.

It can be used to do things such as open a separate browser window or to display a

message when the mouse moves over an object on the page.

JavaScript is a cross-platform, object-based scripting language developed for client and

server applications. It is commonly used on web pages to add interactivity and dynamic

content such as banner rotation.

It was originally developed by Brendan Eich of Netscape Communications under the

name Mocha and then LiveScript but then renamed to "JavaScript".

6.2.4 JSP

JSP (Java Server Page) is a technology for controlling the content or appearance of web

pages through the use of servlets, small programs that are specified in the web page and

run on the Web server to modify the web page before it is sent to the user who requested

it.

Java server pages are a way to create dynamic Web content. They may also be used to

generate and consume XML between n-tier servers or between servers and clients.

JSP is a server-side technology, Java Server Pages are an extension to the Java servlet

technology that was developed by Sun. JSP have dynamic scripting capability that works

in tandem with HTML code, separating the page logic from the static elements -- the

actual design and display of the page. Embedded in the HTML page, the Java source

code and its extensions help make the HTML more functional, being used in dynamic

database queries, for example. JSP are not restricted to any specific platform or server.

JSP a freely available specification for extending the Java Servlet API to generate

dynamic web pages on a web server. JSP was designed to be simpler than pure servlets or

CGI scripting.

Java Server Page standard was developed by Sun Microsystems as an alternative to

Microsoft's active server page (ASP) technology. JSP pages are similar to ASP pages in

that they are compiled on the server rather than in a user's web browser. However, JSP is

Java based, whereas ASP is Visual Basic based. JSP pages are useful for building

dynamic web sites and accessing database information on a web server. Though JSP

pages may have Java interspersed with HTML all the Java code is parsed on the server.

Therefore, once the page gets to the browser, it is only HTML. JavaScript, on the other

hand, is usually parsed by the web browser, not the web server.

6.2.5 Oracle SQL

SQL (Structured Query Language): A specialized language for sending queries to

databases. Most industrial-strength and many smaller database applications can be

addressed using SQL. Each specific application will have its own slightly different

version of SQL implementing features unique to that application, but all SQL-capable

databases support a common subset of SQL. Oracle SQL is a superset of the American

National Standards Institute (ANSI) and the International Standards Organization (ISO)

SQL99 standard.

It was developed by IBM in the mid-1970s as a way to get information into and out of

relational database management systems and was called SEQUEL for "Structured

English Query Language." Since then it has undergone a number of changes with a lot of

influence from Oracle Corporation. Today SQL is commonly used for web database

development and management. A fundamental difference between SQL and standard

programming languages is that SQL is declarative. You specify what kind of data you

want from the database; the RDBMS is responsible for figuring out how to retrieve it.

SQL is a special-purpose, nonprocedural language that supports the definition,

manipulation, and control of data in relational database management systems. SQL can

be pronounced as either "sequel" or "SQL." It is a query language used for accessing and

modifying information in a database. Some common SQL commands include "insert,"

"update," and "delete."

6.3 Implementation Issues

6.3.1 Using the System

As mentioned earlier to use the system we have considered five types of users. First,

chief administrator, separate hostel administrator, maintenance administrator, hostels

inmates, and outsiders. Except the last one every other user category is having his/her

respective passwords and privileges. Among these, only chief-administrator will be

having initial authority. At later time he can create, update, and/or delete other category.

Last category has been considered as visitors to the open pages only. Others can view

both open and their respective privileged pages.

6.3.2 Data Entry

Various users group are required to provide different set of data to the system. Some of

the entry they have to enter their own and some will be taken from the system. Entry

from system has been enabled to provide ease the job of data entry, and to prevent from

bogus entry.

6.3.3 Final Output/Report

For the final output or report, user with required privilege will send a request to the web-

server and server after fetching data from the database will send a report page which van

be printed if desired.

6.3.4 Leaving the System

Before leaving the system users must wither logout or close all the windows (parent and

childs) to avoid misuse of the system and system malfunction.

6.3.5 Chief Administrator Privileges

Chief administrator is the sole proprietor of this system. He can grant or drop various

users and their privileges if required.

7 . S y s t e m T e s t i n g

7.1 Introduction

No program or system design is perfect. The number and nature of errors in a new

design depends on such factors like the communication between the user and the

designer, the programmers’ ability to generate a code that reflects exactly the

system specifications and the time frame for the design. The purpose of system

testing is to consider all the likely variations to which it will be subjected and to

push the system to its limits. It is a tedious but necessary step in system

development. Testing is vital to the success of the system. System testing makes the

logical assumption that if all the parts of the system are correct, the goal will be

successfully achieved. The system is to be tested to see whether the outputs are

correct to a known specific input.

The process of system testing can be classified into

1. Unit testing

2. Module testing

3. Sub-system testing

4. System testing

5. Acceptance testing

7.1.1 Unit testing

Individual components are tested to ensure that they operate correctly. Each

component is tested independently, without other component

7.1.2 Module testing

A module is a collection of dependent components such as an object class, an

abstract data type or some looser collection of procedures and functions. A module

encapsulate related component so can be tested without other modules

7.1.3 Sub-system testing

This phase involves testing collection of modules, which have been integrated into

sub-systems. Sub-system may be independently designed and implemented. The

most common problem, which arises in large software systems, is sub-system

mismatches. The sub-system test process should therefore concentrate on the

detection of interface errors by rigorously exercising these interfaces

7.1.4 System testing

The sub-system is integrated to make up the entire system. The testing process is

concentrated with finding errors, which result from unanticipated interaction

between sub-systems and system components. It is also concerned with validating

that the system meets its functional and non-functional requirements.

7.1.5 Acceptance testing

This is the final stage in the testing process before the system is accepted for

operational use. The system is tested with data supplied by the system procurer

rather than simulated test data. Acceptance testing may reveal errors and omission

in the system requirements definition because the real data exercises the system in

different ways from the test data. Acceptance testing may also reveal requirements

problems where the system’s facilities do not really meets the users needs or the

system performance is unacceptable.

7.2 Testing Methods

The testing methodologies that we have adopted for our software are namely: White-Box

Testing and Black-Box testing.

7.2.1 White-Box testing

This methodology is also known as the ‘structural testing’, glass-box’ or ‘clear-box’

testing. In this approach we mainly concerned with the structure of the software and its

implementation. This testing approach is mainly applied to relatively small program units

such as sub-routines, or the operations associated with an object.

Why we chose this approach is because we have performed sufficient validation checks

for client-side working where they need to fill some entry forms like students’ personal

information, hostel information, etc and whose data will be put in the tables of the

application databases. Some constraints have been imposed on the tables’ values, for

example Primary key of a Student cannot be blank. So data-entry user cannot leave that

field as blank and try to insert the data. For that we have used one check routine, which

validates the data before sending it to server for further processing. Like this there are

various small routines. Now to check the flow of control within these routine blocks, this

approach was much better, efficient and helpful.

7.2.2 Black-Box testing

Black-Box testing is also called Functional testing. In this approach of testing, tests are

derived from the program or component specification. The system is considered to be a

‘black box’ whose behavior can be studied by its inputs and the related outputs. It is

called functional testing is because the tester is concerned with the functionality and not

the implementation details of the software. This approach is very much applicable to the

systems that are organized as functions or as objects.

Why we chose this methodology is because after integration of the software components

I had to check its correctness for various data combination. we sampled some of the data

items and used as test cases. For some cases out were not as expected or sometimes

resulted in error. It helped me where locate the problem in the system functionality. For

example: to insert a ‘string’ data, which contains an apostrophe (’) in the oracle database

by using SQL query, we require to put another apostrophe adjacent to it like (’’.). This is

rare case of such strings but they do exist. This testing methodology helped me in this

regard.

8 M a i n t e n a n c e

This deals with the maintenance aspect of the system developed. Maintenance is done to

adapt the new requirements that may arise over the time. Not all additional requirements

may be supported by the system. Only the requirements that do not change the

fundamental structure of the system are supported. This is very important because

changing the fundamental structure may cause other functions malfunction or not to

function. So extreme care should be taken while modifying the system. Modification

shall be permitted only with the thorough review of the system.

9 C o n c l u s i o n

The system has been corrected for almost all sort of errors and is working properly. Also

some of features and scope of the future works have been mentioned below:

9.1 Features of the system

9.1.1 Advantages

+ Automation of the work

+ Fast processing of the information

+ Updated information availability

+ Easy to use the system

+ Secure data storage

9.2 Scope for future work

o Database may be upgraded

o Room-allotment process and student-mess management can be added

o More constraints can be enforced for better security

o Can be updated to accommodate all major operating systems (Solaris)

o And, of course better interface can be made to ease the work

1 0 R e f e r e n c e s

The books and sites referenced while doing this project are:

1. Ian Sommerville, “Software Engineering”, 6th edition, Addison-Wesley

2. Danny Goodman, “JavaScript Bible”, 3rd Edition, IDG Books Worldwide Inc.

3. James Jaworski, “Mastering JavaScript and Jscript”, 1st Edition, BPB Publication

4. Carol McCullough-Dieter, “Oracle8 Bible”, IDG Books Worldwide Inc

5. Buluson Lakshman, “Oracle9i PL/SQL: A Developer’s Guide”, 1st Edition, Apress

For JavaScript:

6 “Planet PDF Forum Archive”,

http://www.planetpdf.com/forumarchive/forum34.asp

7 “[JavaScript] RE: Checking for date”,

https://lists.latech.edu/pipermail/javascript/ 2002-July/003937.html

8 “Submitting forms via email”,

http://sharkysoft.com/tutorials /jsa/content/034.html

9 “JavaSript Articles”,

http://www.netevolution.co.uk/scriptsbycategory.asp?Cat= JavaScript&offset=0

10 “JavaScript Index”,

http://www.hypergurl.com/easyhtml.html

11 “Navigation Links and Buttons”,

http://www.codeave.com/javascript/code.asp? u_log=7013

12 “JavaScript - Enable and Disable form elements”,

http://www.codetoad.com/ javascript/ enable_disable_form_element.asp

13 “JavaScript programming”

http://www.codingforums.com/archive/index.php/f-2-p-1.html

14 “JavaScript-Object: Array”

http://www.devguru.com/Technologies/ecmascript/quickref/array.html

15 JavaScript Articles

http://tech.irt.org/javascript articles/JavaScript Articles.htm

16 “ The Date Object: JavaScript Clock-1”

http://www.pageresource.com/jscript/jclock.htm

For JSP (Java Server Page)

17 Overview of the Oracle JSP Implementation”

http://www-306.ibm.com/software/webservers/appserv/doc/v20dcadv/doc/howto/

itcache.html#prevent

18 Caching: Preventing Web Page Caching”

http://www-306.ibm.com/software/webservers/appserv/doc/v20dcadv/doc/howto/

itcache.html#prevent

19 Connect to Oracle with a JSP Page”

http://elab.bus.umich.edu/how-to-oracle-jsp.php

20 Exception Handling in JSP Pages”

http://www.nakov.com/inetjava/lectures/part-3-webapps/InetJava-3.8-Exception-

Handling- in-JSP-Pages.html

21 A Java Tutorial: A Practical Guide for Programmers”

http://java.sun.com/docs/books/tutorial/index.html

A p p e n d i c e s

Appendix-A : Screen Shots

1 NITC Hostel Home

Figure: 3- NITC Hostel Home

2 Old PG HOME

Figure: 4- PG-I Home

3 Administrators Privileged Page

Figure-5: Administrators Home

t

4 Students’ Personal Data Entry Form (only for Chief Admin)

Figure: 6 – Data-Entry Form

5 Students’ Hostel Joining Form (For Chief-Admin & respective Hostel-Admin) 6 User-Creation Form (for Chief-Admin)

Figure: 7 – Hostel-Joining Form

Figure: 8 – User Creation Form

7 Students’ Hostel Leaving Form (For Chief-Admin & respective Hostel-Admin)

8 Students’ Privileged Page

Figure: 9 – Hostel-Leaving Form

Figure: 10 – Student Privileged Page

9 Student Posting Complaints 10 Student Changing Password

Figure: 11 – Writing Complaints

Figure: 12 – Changing Password

11 Checking off the Complaints (for Chief-Admin and Maintenance-Admin)

Figure: 13 – Checking Off Complaints

l

Appendix-B : Database Tables

1. Student’s Database : TABLE NAME – ‘Student’

Attribute Name Data-Type [length] Constraints Stud_Name Varchar2(30) NOT NULL Stud_Roll Varchar 2(8) PRIMARY KEY Pres_Addr Varchar 2(50) NOT NULL Perm_Addr Varchar 2(50) NOT NULL Birt_Date Date NOT NULL Join_Date Date NOT NULL Dept Varchar 2(5) NOT NULL Course Varchar 2(5) NOT NULL Pres_City Varchar 2(30) Pres_PIN Varchar 2(6) Pres_State Varchar 2(30) NOT NULL Pres_Country Varchar 2(30) NOT NULL Perm_City Varchar 2(30) Perm_PIN Varchar 2(6) Perm_State Varchar 2(30) NOT NULL Perm_Country Varchar 2(30) NOT NULL Phone Varchar 2(15) Email Varchar 2(30) Sex Char(1) NOT NULL Last_Updated Date NOT NULL

2. Hostels’ Database : TABLE NAME – ‘Hostel’

Attribute Name Data-Type [length] Constraints Hostel_Slno Varchar 2(30) PRIMARY KEY Hostel_Name Varchar 2(8) NOT NULL Start_Date Varchar 2(50) Total_Room Varchar 2(50) Total_Floor Date QIP_Resvd Date PHD_Resvd Varchar 2(5) Mess_Y_N Varchar 2(5) Mess_Type Varchar 2(30) Remark Varchar 2(6)

3. Administrators’ Account Table : TABLE NAME – ‘Admin_Users’

Attribute Name Data-Type [length] Constraints User_Id Varchar 2(256) PRIMARY KEY Password Varchar 2(256) User_Type Varchar 2(20) NOT NULL

4. Students’ Account Table : TABLE NAME – ‘Student_Users’

Attribute Name Data-Type [length] Constraints Stud_Roll Varchar 2(8) PRIMARY KEY, References (Student) Password Varchar 2(256) User_Type Varchar 2(20) NOT NULL

5. Student In A-hostel : TABLE NAME – ‘Stud_A’

Here 11 similar type of tables are there for each a hostel. So here I am representing only one of the tables that is only for A-Hostel to save space. And for every other hostel instead of ’A’, replace it by ‘B’ (for B-Hostel), ‘C’ (for C-Hostel), ‘D’ (for D-Hostel), ‘E’ (for E-Hostel), ‘F’ (for F-Hostel), ‘G’ (for G-Hostel), ‘NPG’ (for New PG), ‘OPG’ (for Old PG), ‘NLH’ (for New LH), ‘OLH’ (for Old LH).

Attribute Name Data-Type [length] Constraints Hostel_Slno Varchar2(2) Primary Key, References (Hostels) Room_Id Varchar 2(4) Primary Key Join_Date Date Primary Key Stud_Roll Varchar 2(10) Primary Key, References (Student) Join_Sem Date Cot_YN Date Table_YN Char(1) Chair_YN Char(1) Hanger_YN Char(1) Fan_YN Char(1) Bulb_YN Char(1) Leav_Date Char(1) Remark Char(100)

6. Complaints from A-hostel : TABLE NAME – ‘Complain_A’

Here also 11 similar type of tables are there for each a hostel. So here I am representing only one of the tables that is only for A-Hostel to save space. And for every other hostel idea is same as above

Attribute Name Data-Type [length] Constraints Comp_Slno Varchar2(5) Primary Key Hostel_Slno Varchar 2(2) References (Hostels) Stud_Roll Varchar 2(8) References (Student) Room_Id Varchar 2(4) Not Null DOC Date Not Null Complaint Varchar2(256) Not Null Is_Pending Char(1) Not Null

Appendix-C : Database Views

1. Students in All Hostels : View Name – “AllHostels”

Attribute Name Data-Type [length] Constraints Hostel_Slno Varchar 2(2) Room_Id Varchar 2(4) Join_Date Date Leav_Date Date Stud_Roll Varchar 2(8)

2. Current Students in All Hostels : View Name – “Curr_Studs”

Attribute Name Data-Type [length] Constraints Roll Varchar 2(8) Name Varchar 2(30) Course Varchar 2(5) Hostel_Slno Varchar 2(2) Hostel Varchar 2(6) Room Varchar2(4) CheckIn Date