Hostel Information System (HISYS)

P r o j e ct R e po r t
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 Institute 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

Lecturer (SS) Dept of Computer Engineering NITC

Dr. V K Govindan
Professor and Head Dept of Computer Engineering 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 f r all hostels. Apart from this only he (and chief administrator) can check off the o 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 1.1 1.2 1.3 2. 2.1 2.2 2.3 2.4 2.5 3. 3.1 3.2 3.3 3.4 3.5 3.6 4 4.1 4.2 4.3 5. 5.1 5.2 5.3 5.4 5.5 Introduction...........................................................................................................................7 Purpose................................................................................................................................... 8 Scope...................................................................................................................................... 8 Overview of the Report.......................................................................................................... 8 System Overview...................................................................................................................8 Students Information Management ...................................................................................... 9 Hostels Complaints Management ....................................................................................... 10 Hostels Inmates List Generation......................................................................................... 10 Hostel Web-Site Maintenance and Information Processing ................................................ 10 Who is responsible for all these? ......................................................................................... 11 System Analysis...................................................................................................................12 Functional Requirements ..................................................................................................... 12 Problem Definition............................................................................................................... 12 General Constraints.............................................................................................................. 13 Operational Requirements.................................................................................................... 14 Interface Requirements ........................................................................................................ 14 Non-Functional Requirements ............................................................................................. 14 System Architecture ...........................................................................................................15 Architectural Description..................................................................................................... 15 Architectural Alternatives.................................................................................................... 16 Design Rationale .................................................................................................................. 16 Design...................................................................................................................................16 Use-Case Diagrams.............................................................................................................. 17 Class Diagram...................................................................................................................... 18 Sequence Diagrams.............................................................................................................. 19 Database Tables ................................................................................................................... 20 Entity-Relationship Diagram ............................................................................................... 21

6. 6.1 6.2 6.3 7. 7.1 7.2 8 9 9.1 9.2 10

Implementation...................................................................................................................22 Introduction.......................................................................................................................... 22 Languages and Tools Used .................................................................................................. 22 Implementation Issues.......................................................................................................... 25 System Testing ....................................................................................................................27 Introduction.......................................................................................................................... 27 Testing Methods................................................................................................................... 28 Maintenance ........................................................................................................................29 Conclusion...........................................................................................................................30 Features of the system.......................................................................................................... 30 Scope for future work .......................................................................................................... 30 References............................................................................................................................31

Appendices....................................................................................................................................33 Appendix-A : Screen Shots........................................................................................................... 33 Appendix-B : Database Tables ..................................................................................................... 41 Appendix-C : Database Views ...................................................................................................... 44

Introduction
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 wasnt 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 va rious 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 Hostels 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 lets go through the detail aspect of HISYS: 1 2 3 Purpose Scope 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.

System Overview
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 wit h 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. Administrator s Nature of Job Students personal Info Entry Students personal Info Deletion Students personal Info Updating Students User-Account Creation Students User-Account Updating Students User-Account Deletion Students Hostel Joining Info Entry

User Type Chief-Administrator Chief-Administrator Chief-Administrator, Students Current Hostel-Administrator Chief-Administrator Chief-Administrator Chief-Administrator Chief-Administrator, Students Current Hostel-Administrator Chief-Administrator, Students Current Hostel-Administrator Chief-Administrator (for all hostels), Hostel- Administrator for that Hostel only

Students Hostel Leaving Info Entry

Generate Student List

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

Students Nature of Job Change Password Post Complaints Comprehensive Search

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

User

Administrator

HISYS
Student
Report Database

Fig 1: - System Overview

3.
3.1

System Analysis
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

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
3.4.1

Operational Requirements
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
3.6.1

Non-Functional Requirements
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
4.1

System Architecture
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 itll be fetched from the database and put into a report format for the user to view.

Storing & Updating Student

User Interface

HISYS

Repository
Fig 2: - Report Generation

Reporting Complaint & Student List

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.

Design
In this section a detailed design issue has been considered starting from Use-case Diagrams, Class-Diagrams, and Sequence-Diagrams, Database-Tables up to EntityRelationship Diagram.

5.1
5.1.1

Use-Case Diagrams
Students Information Management

Enter Students Hostel Info

Create a Students User

Update a Students User Staff Enter Students Personal Info <<extends> Check for First Time Hostel Inmate Student

5.1.2

Handling Complaints from Students

Write Complaint Student

Repair & Check-off Pending Complaints Maintenance Staff

<<uses>> Generate Complaints List

5.1.3

Browsing the Site

Request for Page User

<<extends>> Check if Privileged Page

<<extends>> Check for Required Privilege

5.1.4

Searching the Database

Enter Query User Check for Administrator

<<uses>> Show result <<extends>>

5.2

Class Diagram
Student 0..* OccupiedB yOccupying Occupies 1..1 Hostel 1..* ContainedB y

0..* ComplainedBy Complaining Complains 1..1 Maintenance Office Contains 1..1

Containing

5.3
5.3.1

Sequence Diagrams
Students Information Management

Hostel Staff

:Student

:Hostel

new(Student) FoundStudent() loop [For Each New Student] EnterPersonalData(), EnterNewHostelData() CreateUser()

[For Each Old Student] EnterNewHostelData()

UpdateUser()

Status

5.3.2

Complaints from Students

System

:Student

new(Student) validateStudent() PostComplaint()

Status

5.3.3

Maintenance Office Checking Off Complaints

System

:Staff

ValidateStaff() CheckOff()

Status

5.3.4

Browsing the Site and Searching the Database

System new(Query) validateUser() Result

:Server

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.

5.5

Entity-Relationship Diagram
HostelID TotalRooms Stud_Roll DOB Address DOJ StudName COMPLAINS BELONGSTO StartDate TotalFloors Sex STUDENT OCCUPIES HOSTEL

COMPLAINT

ComplnID

ComplaintText

6.
6.1

Implementation
Introduction
This projects 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
6.2.1

Languages and Tools Used

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 WWWs 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 ma ny 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
6.3.1

Implementation Issues
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 webserver 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.
7.1

System Testing
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 systems 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.

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

Conclusion
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
9.1.1

Features of the system

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

10

References
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 Developers 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-ExceptionHandling- in-JSP-Pages.html 21 A Java Tutorial: A Practical Guide for Programmers http://java.sun.com/docs/books/tutorial/index.html

Appendices
Appendix-A : Screen Shots
1 NITC Hostel Home

Figure: 3- NITC Hostel Home

Old PG HOME

Figure: 4- PG-I Home

Administrators Privileged Page

Figure-5: Administrators Home

Students Personal Data Entry Form (only for Chief Admin)

Figure: 6 Data-Entry Form

Students Hostel Joining Form (For Chief-Admin & respective Hostel-Admin)

Figure: 7 Hostel-Joining Form

User-Creation Form (for Chief-Admin)

Figure: 8 User Creation Form

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

Figure: 9 Hostel-Leaving Form 8 Students Privileged Page

Figure: 10 Student Privileged Page

Student Posting Complaints

Figure: 11 Writing Complaints

10 Student Changing Password

Figure: 12 Changing Password

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

Figure: 13 Checking Off Complaints

Appendix-B : Database Tables

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

NOT NULL NOT NULL

NOT NULL NOT NULL

NOT NULL NOT NULL

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

3. Administrators Account Table : TABLE NAME Admin_Users Attribute Name User_Id Password User_Type Data-Type [length] Varchar 2(256) Varchar 2(256) Varchar 2(20) Constraints PRIMARY KEY NOT NULL

4. Students Account Table : TABLE NAME Student_Users Attribute Name Stud_Roll Password User_Type Data-Type [length] Varchar 2(8) Varchar 2(256) Varchar 2(20) Constraints PRIMARY KEY, References (Student) 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 EHostel), 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 Hostel_Slno Room_Id Join_Date Stud_Roll Join_Sem Cot_YN Table_YN Chair_YN Hanger_YN Fan_YN Bulb_YN Leav_Date Remark Data-Type [length] Varchar2(2) Varchar 2(4) Date Varchar 2(10) Date Date Char(1) Char(1) Char(1) Char(1) Char(1) Char(1) Char(100) Constraints Primary Key, References (Hostels) Primary Key Primary Key Primary Key, References (Student)

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 Comp_Slno Hostel_Slno Stud_Roll Room_Id DOC Complaint Is_Pending

Data-Type [length] Varchar2(5) Varchar 2(2) Varchar 2(8) Varchar 2(4) Date Varchar2(256) Char(1)

Constraints Primary Key References (Hostels) References (Student) Not Null Not Null Not Null Not Null

Appendix-C : Database Views

1. Students in All Hostels : View Name AllHostels Attribute Name Hostel_Slno Room_Id Join_Date Leav_Date Stud_Roll Data-Type [length] Varchar 2(2) Varchar 2(4) Date Date Varchar 2(8) Constraints

2.

Current Students in All Hostels : View Name Curr_Studs Attribute Name Roll Name Course Hostel_Slno Hostel Room CheckIn Data-Type [length] Varchar 2(8) Varchar 2(30) Varchar 2(5) Varchar 2(2) Varchar 2(6) Varchar2(4) Date Constraints