MVJCE HOSTEL

MANAGEMENT

A PROJECT REPORT

Submitted by
NAME
REGISTER NUMBER
ABSTRACT
ABSTRACT:

Hostel management by manual way is tedious process, since it involves work load and time
consumption. In this system, we can easily manage the hostel details, room details, student records,
mess expenditure, mess bill calculation, easy way of room allocation and hostel attendance.

The main feature of this project is easy to allocate for the student and also easy to calculate mess bill.

This project is carried out using .NET as front end and MS ACCESS as back

end.
 INTRODUCTION

INTRODUCTION
 With the fast changing technology, today an organization has become surprisingly large and sophisticated
operation. Technologies often have an important role to play and are the key to play and are the key to
success in competing with the world .Thus the working approach of people has changed a lot.

Nowadays time and money matters a lot. So we need to automate our existing manual system, and thus
comes concept of improvisation in the existing technology and here comes the one stop easy solution to
compile and run java programs.

The project is fully compatible with running all the forms suitable for the hostel project and in the own
window which designed to display the output of the forms

.
 LITERATURE
SURVEY

INTRODUCTION

1.1. TO THE PROBLEM

 Hostel management gives on idea about how the students details, room allocation, mess

expenditure are maintained in the particular concern. The hostel management system also includes some

special features. The administration has the unique identity for each members as well as students details.

The stock management has also held by mess expenditure, the mess expenditure that used to calculate the

mess bills of each of the students. The modules of this project are student details, attendance details, room

details, mess modules.

Visual Basic6.0 is used as the front end tool and Oracle is used as a backend tool. Visual Basic is

one of the driven programming languages. The application wizards, menu editor and data reports etc is

very much useful for creating very good professional software.

1.2. TO THE SOFTWARE TOOL

The “visual” part refers to the method used to create the graphical user interface (GUI). Rather

than writing numerous lines of code to describe the appearance and location of interface elements, you

simply drag and drop pre-built objects into place on screen. If you’ve ever used a drawing program such as

paint, you already have most of the skills necessary to create an effective user interface.

It revolves around ready-made objects and it is event-driven that is all the activities in a program

are triggered by one event or another. Each object has its own properties, determining its position, size,

color, appearance and nature of its text and much more. Each object also has its own event-handling

procedures.

Visual basic knows what a button is and how it works? It also works how to handle images,

menus, dialog boxes, drive and directory list and much else. The programmer does not have to write code

to trap these events the system does that automatically because the program code runs in response to

events. The flow of execution is not as fixed in a traditional program.

Operations do not have to follow a set of sequence and can be easily interrupted, suspended or

abandoned. The process of program design reflects the nature of the system. You begin by the screen

layout events and then any necessary code to co-ordinate the whole program.
 HARDWARE
AND
SOFTWARE
REQUIREMENTS
 4. HARDWARE AND SOFTWARE REQUIREMENTS

4.1 HARDWARE REQUIREMENTS:

Processor : Pentium III 333 MHz (Min)

RAM : 64 MB (Min)

Hard disk : 2 GB (Min)

Monitor : Color/Black & White

Keyboard : Standard 104 keys

4.2 SOFTWARE REQUIREMENTS:

Language : Java(Jdk 1.6)

Operating System : Windows XP and above

 SOFTWARE
REQUIREMENT
SPECIFICATION
 5. SOFTWARE REQUIREMENT SPECIFICATION

Software requirement specification is the starting point of the software development activity. This section
provides an overview of the entire requirement document. This document describes all the data, functional
and behavioral requirements for Software. The SRS is a mean of translating the ideas in the mind of the
clients into formal documents.

The purpose of this SRS is to define the requirements, which will enable the development of the JEditor.
SRS is only written document that describe the requirement of the system. It is meant for use by
developers and will be the basis for validating the final delivery system.

5.1 PURPOSE
This project is developed to implement the java functionalities to make the program compatible to run in
the editor it provides user interface to write edit and compile the java programs it shows bugs in the
program. Highlights the keywords.

5.2 SCOPE

SRS establishes the basis for agreement between Customer and the Developer on what the software
product will do.

1. an SRS provides a reference for validation of the final product.

2. a high-quality SRS is a Pre-requisite to high-quality software.
3. a high-quality SRS reduces the development cost
5.3 PROBLEM DEFINITION:

To run a java program it is necessary to

The following are the desired functionalities to be achieved in JEditor:

 Writing java programs

 Compiling java program
 Identifying the bugs
 Running the java Programs
 Saving java files in directories in drive and directory
 Opening java files in directories in drive and directory

5.4 FEASIBILITY STUDY

For all system, the requirement engineering process should start with feasibility study. The input to the
feasibility study is an outline description of the system and how it will be used within an organization. The
result of the feasibility study should be report which recommends whether or not it is worth carrying on
with the requirement engineering and development process.

A feasibility study is a short, focused which aims to answer a number of questions.

1. Do the JEditor shows the overall objective of the functions.

2. Can the JEditor be implemented using technology and within given cost and schedule
constraints?
3. Can JEditor be integrated with the other operating system which is already in place?
Yes, my project JEditor fulfills all the three criteria of feasibility studies.
 SYSTEM
DEFINITION
 6. SYSTEM DEFINITION

6.1 SYSTEM ANALYSIS

From the developer’s aspect, system is the process of understanding a problem domain and user’s
requirements for the purpose of developing a computer application system to serve the needs of the user’s.
System design is the process of translating that understanding into a computer based solution ready for
implementation on chosen system architecture.

6.2 EXISTING SYSTEM

To run a java program first we must set path in the console window to setpath=C:\Program
Files\Java\jdk1.6.0_11\bin then we write the program in notepad save it with .java extension and compile
it with “javac filename” the errors shown here are critical to understand and finally a correct program is
run using “java filename”. So much work to run a java program.

6.3 PROPOSED SYSTEM

The proposed system is having the feature of editing compiling and running the java programs efficiently.
Provides highlights for keywords and shows errors and help for debugging. Writing java programs
,Compiling java program, Identifying the bugs, Running the java Programs, Saving java files in
directories in drive and directory, Opening java files in directories in drive and directory

6.4 BENEFITS OF PROPOSED SYSTEM

• Efficient Flexibility in running programs

• Easy to Debug Errors

• Identify keywords

• Write, Edit, Compile, Run programs from same application reducing

the knowledge of individual commands
DETAILED DESIGN
7. DETAILED DESIGN

7.1 PURPOSE:
The purpose of the system is having the feature of editing compiling and running the java programs
efficiently. Provides highlights for keywords and shows errors and help for debugging. Writing java
programs ,Compiling java program, Identifying the bugs, Running the java Programs, Saving java files in
directories in drive and directory, Opening java files in directories in drive and directory

7.2 UML DISGRAMS

7.2.1 USE CASE DIAGRAM

Diagram Building Blocks:

Interaction among actors is not shown on the use case diagram. If this interaction is essential to a coherent
description of the desired behavior, perhaps the system or use case boundaries should be re-examined.
Alternatively, interaction among actors can be part of the assumptions used in the use case.

 Use cases

A use case describes a sequence of actions that provide something of measurable value to an actor and is
drawn as a horizontal ellipse.

 Actors

An actor is a person, organization, or external system that plays a role in one or more interactions with the
system.

 System boundary boxes (optional)

A rectangle is drawn around the use cases, called the system boundary box, to indicates the scope of
system. Anything within the box represents functionality that is in scope and anything outside the box is
not.
Actor Generalization:
One popular relationship between Actors is Generalization/Specialization. This is useful in defining
overlapping roles between actors. The notation is a solid line ending in a hollow triangle drawn from the
specialized to the more general actor.

Use Case Relationship:

Four relationships among use cases are used often in practice.
Include

In one form of interaction, a given use case may include another. "Include is a Directed Relationship
between two use cases, implying that the behavior of the included use case is inserted into the behavior of
the including use case".
Extend

In another form of interaction, a given use case (the extension) may extend another. This relationship
indicates that the behavior of the extension use case may be inserted in the extended use case under some
conditions. The notation is a dashed arrow from the extension to the extended use case, with the label
"«extend»". The notes or constraints may be associated with this relationship to illustrate the conditions
under which this behavior will be executed.
Generalization

In the third form of relationship among use cases, a generalization/specialization relationship exists. A
given use case may have common behaviors, requirements, constraints, and assumptions with a more
general use case. In this case, describe them once, and deal with it in the same way, describing any
differences in the specialized cases. The notation is a solid line ending in a hollow triangle drawn from the
specialized to the more general use case (following the standard generalization notation).

Associations

Associations between actors and use cases are indicated in use case diagrams by solid lines. An association
exists whenever an actor is involved with an interaction described by a use case. Associations are modeled
as lines connecting use cases and actors to one another, with an optional arrowhead on one end of the line.
The arrowhead is often used to indicating the direction of the initial invocation of the relationship or to
indicate the primary actor within the use case. The arrowheads imply control flow and should not be
confused with data flow.

7.2.2 Sequence Diagram:

Over view:

A sequence diagram shows, as parallel vertical lines (lifelines), different processes or objects that
live simultaneously, and, as horizontal arrows, the messages exchanged between them, in the
order in which they occur. This allows the specification of simple runtime scenarios in a graphical
manner.

For instance, the UML 1.x diagram on the right describes the sequences of messages of a (simple)
restaurant system. This diagram represents a Patron ordering food and wine, drinking wine then
eating the food, and finally paying for the food. The dotted lines extending downwards indicate
the timeline. Time flows from top to bottom. The arrows represent messages (stimuli) from an
actor or object to other objects. For example, the Patron sends message 'pay' to the Cashier. Half
arrows indicate asynchronous method calls.
If the lifeline is that of an object, it demonstrates a role, Activation boxes, or method-call boxes,
are opaque rectangles drawn on top of lifelines to represent that processes are being performed in
response to the message (Execution Specifications in UML).

Objects calling methods on themselves use messages and add new activation boxes on top of any
others to indicate a further level of processing.

When an object is destroyed (removed from memory), an X is drawn on top of the lifeline, and
the dashed line ceases to be drawn below it (this is not the case in the first example though). It
should be the result of a message, either from the object itself, or another.

A message sent from outside the diagram can be represented by a message originating from a
filled-in circle (found message in UML) or from a border of sequence diagram (gate in UML).

Sequence Diagram of JEditor:

CODING
IMPLEMENTATION
9. SYSTEM IMPLEMENTATION

9.1 Implementation procedure

Implementation is the process of converting a new system into an operational one. The designed system is
converted to an operational one using a suitable programming language. Implementation includes all those
activities that take place to convert an old system to new. Proper implementation is essential to provide a
reliable system to meet the organizational requirement.

The JEditor is a software in which can write ,compile, run java programs efficiently without hectic codes
and procedures.

9.2 Operational document

A software product is composed of code and documentation. Documentation consist of all the information
about the software except the code itself. In size the code is by far the smaller part of the product. The
production of effective documentation is sometimes overlooked, but it is vital to the success of software
engineering.

Documentation is aimed at three different audiences.

1. The employee: who will depend on documents from previous life cycle stages to guide continued
development and maintenance.
2. The managers: who will use document from project past projects to plan and understand current
projects.
3. The user: who learns how to use the software from documentation?
 It often seems to be unfair to the software engineers that a user judges the product on the
basis of its documentation rather than the performance of the code. From the engineers
limited viewpoint he fails to see that best program in then world is useless if one does not
know how to operate it.
 In preparing documentation, careful consideration has to be given to a number of factors.
 First the documentation should be complete.
 Second the documentation should be consistent; inconsistency will destroy the readers
confidence in the documentation.
 Third the documentation has to be patched at the right label for its intended audience. A
training manual cannot demand as much from its readers as a design document. We
 should use an appropriate label of formality and an appropriate vocabulary in our
presentation.
 Finally, we need to select the right approach in presenting information so that it will be
readily understood. This certainly includes a choice of formal text, technical manual,
workbook, tutorial, help package and soon. Illustration since they organize and present
large amount of materials for quick reference.
TESTING
AND
RESULTS
10. TESTING AND RESULTS

10.1 INTRODUCTION

Software testing forms an activity of software development. Software testing identifies errors at an early
stage. A planned testing identifies the difference between the expected result and the actual results. Te
main objective of the software testing is to find errors. This helps to make software more rugged and
reliable.

Testing plays a very critical role in determining the reliability and efficiently of the software and hence is
very important stage in software development. Tests are to be conducted on software to evaluate its
performance under a number of conditions ideally it should do so at the label of each module and also
when all of them are integrated to form the complete system. Software testing is done at different levels;
they are unit testing and system testing which comprises of integration testing and acceptance testing.

10.2 TESTING

Testing is a well established and may be defined as the process of judging experimentally whether a
system and its particular components satisfy particular components requirements.

System testing is the stage of implementation, which is aimed at ensuring that the system works
accurately before live operations commences. Testing is vital to the successes of the system. No program
design is perfect. The communication between the user and designer

Is not always complete or clear and the time is usually short. The number and nature of errors depends on
the several factors.

• Communication between the user and the designer.

• The programmer’s ability to generate a code that reflects exactly
the system specification.

• The time frame of the design.

Theoretically a newly designed system should have all the pieces in working order, in reality each piece of
works independently. Now is the time to put all the pieces in to one system and the test determines
whether it meet the user’s requirements.
 Software testing is the one if the element of a border topic and often referred to as verification refer to all
the activities that software correctively performs a specific function. Validation refers to a different set of
activities that ensure that the software built is traceable to user requirements.

In developing the software both verification and validation was done.

Testing was carried out into two phases.

• Module testing
• Integrating testing

10.2.1 Module testing:-

• First the individual modules ware tested for effective performance.
• Every form was subjected to test for many data to check its effectiveness
• Each of these forms was tested with raw data in order to ensure that all the modules of the
system works correctively.
• Those who were not in the development conducted the tests.
10.2.2 Integrating testing:-
• When the individual modules were found to work satisfactorily the system integration test
was carried out.
• Data was collected in such a way that all program path could be covered.
• Using these data a complete test was made.
• All the outputs were generated.
• The package was found to handle all the exceptional cases.
SL. NO. TEST CASE PROCEDURE EXPECTED STATUS
RESULT

1 Pass

2 Pass

3 Pass

4 Pass
CONCLUSION
11. CONCLUSION

Efficient software ready to use can run java swing programs efficiently and
provides one stop solution to editing, compiling and running the java application.
This is a efficient program to run core java and swing programs easily with user
friendly user interface.
 FUTURE
ENHANCEMENT
12. FUTURE ENHANCEMENT
 Prediction for keywords it was difficult to include all the commands because of time
constraint.
 The code is in only in one module, so making any changes to the code is little bit difficult.
 Could be used to run Applet programs also will be an interesting addition.
BIBLIOGRAPHY
13. BIBLIOGRAPHY
USER MANUAL
14. OUTPUT FOR MULTITASKING

14.1 Screen Shots: