CONTENTS

1. Introduction ………………………………………………………… 1
2. Abstract ………………………………………………………… 1
3. Project Definition……………………………………………………. 2
4. Need ………………………………………………………... 2
5. Project Overview……………………………………………………. 2
6. H/W, S/W Configuration…………………………………………… 4
7. Software process model…………………………………………….. 11
8. Problem Definition and Description………………………………. 13
9. System Analysis & Design………………………………………..... 15
10. System Analysis…………………………………………………….. 16
11. Data Flow Diagram………………………………………………… 18
12. E-R Diagram……………………………………………………….. 24
13. Database Design……………………………………………………. 25
14. Screen Layouts…………………………………………………….. 26
15. Testing………………………………………………………………. 36
16. Implementation…………………………………………………….. 38
17. Discussion…………………………………………………………… 40
18. Bibliography………………………………………………………. 41
1. INTRODUCTION

Technology makes lifestyle easier by providing better support to

different systems, better accuracy, better security options, easier
maintenance, etc.
Now a day’s technology eventually means “computers” which is the
greatest achievements of last century. Day by day computers are being more
and more popular because of its features like ease of work, ease of learning,
greater accuracy with the least time consumption and the last but not the
least i.e. ease of maintenance with cost effectiveness.
So as a part of these ongoing evolutionary approach traditional
systems are being computerized to make them more fruitful than ever.
2.ABSTRACT

Time Table Management system is an automated system which genets

time table according to the data given by the user. The main requirement of
the application is to provide the details about the branch, subjects, no. of
labs, total no. of period and details about the lab assistance. Then the
application generates the time table according to your need.

3.PROJECT DEFINITION

 The basic project is to create a Time Table Management System.

 To create Databases of different entities involved in this process.

 Maintaining database-containing information about the various

semesters, subjects, Labs, teachers etc.
 4.NEED

 As we discussed earlier that manual maintenance of a Time Table

Management System is a tedious job. So to enhance the ease of

working we go for this package.
 Manual maintenance of databases of items, time table processing is a

time taking process and somehow erroneous.

 To give more accuracy to the system i.e. rather going manual
modification we involve computer for accuracy.
 The least but most important it saves time.

5.PROJECT OVERVIEW

Objectives of the package

 Create a Time Table Management System to be used by any College.

 To perform the basic requirements of the firm.

 Maintaining databases of subject, Class, semester’s details.

Scopes and boundaries of the package

 As it is a computer-based package so maintenance and working

is somewhat difficult from manual mode of approach.
 As it is not possible to associate each and every requirement of
the system so in some way or other it will going to create problem at
some stage of execution (like report generation).
 As a computer based System it is easier to fetch data from the
database for unsocial activities. Also easier to destroy the existing ones.

Expected Benefits
  On implementing this package the farm will get error free data
to analyze.
 This package would limit the time and money factor involve in
“Time Table Management System”.
 Maintenance is much easier and accurate than the existing
manual system.
 Security features are somewhat higher than that of manual
approach.
6. Hardware and Software Configuration

The hardware and software should be chosen carefully keeping following point
in mind

• The System must be user friendly

• The System must be able to handle large number of data.
• Processing speed of the system must be fast

Hardware configuration

Main processor : Pentium IV

Random access memory : 1 GB
Hard disk capacity : 80 GB

Software configuration

Operating system : Windows (2000, ME, NT, XP)

Programming specification : JAVA (J2SE/J2EE), Swing, JDBC
Integrated Development
Environment : My Eclipse 5.5 / Eclipse
 Design Pattern Used:
 DAO (Data Access Object) Model
 DTO (Data Transaction Object) Model

Data Access & Data Transfer Object Model:

The Data Access Object (or DAO) pattern:

• Separates a data resource's client interface from its data access mechanisms
• Adapts a specific data resource's access API to a generic client interface

The DAO pattern allows data access mechanisms to change independently of the
code that uses the data.

DAO FACTORY
DATA

SOURC
BUSINESS OBJECT
DATA ACCESS OBJECT E
(JSP PAGE)

DATA TRANSFER OBJECT

The DAO design pattern is another abstraction layer over the persistence
mechanism of the application. The application deals with Data Access Objects
and Data Transfer Objects (DTO) rather than directly calling the JDBC driver.
Changing the persistence method at a later date doesn't require the application code
to change, only adding a new set of DAOs. Using DAO in the web application
allows more concentration on the data access rather than on the mechanics of how
the data is stored and retrieved.

The standardization provided by this new layer also makes it easier to

automatically generate the Java code necessary to access the database. Most JDBC
calls are very repetitive and time consuming. Using a DAO Generator is a good
way to eliminate that work and make the application development faster.

Overview of Swing:

Swing is a widget toolkit for Java. It is part of Sun Microsystems' Java Foundation
Classes (JFC) — an API for providing a graphical user interface (GUI) for Java
programs.

Swing was developed to provide a more sophisticated set of GUI components than
the earlier Abstract Window Toolkit. Swing provides a native look and feel that
emulates the look and feel of several platforms, and also supports a pluggable look
and feel that allows applications to have a look and feel unrelated to the underlying
platform.

Architecture
Swing is a platform-independent, Model-View-Controller GUI framework for Java.
It follows a single-threaded programming model, and possesses the following
traits:

• Platform independence: Swing is platform independent both in terms of its

expression (Java) and its implementation (non-native universal rendering of
widgets).

• Extensibility: Swing is a highly partitioned architecture, which allows for

the "plugging" of various custom implementations of specified framework
interfaces: Users can provide their own custom implementation(s) of these
components to override the default implementations. In general, Swing users
can extend the framework by extending existing (framework) classes and/or
providing alternative implementations of core components.
 • Component-Oriented: Swing is a component-based framework. The
distinction between objects and components is a fairly subtle point:
concisely, a component is a well-behaved object with a known/specified
characteristic pattern of behaviour. Swing objects asynchronously fire
events, have "bound" properties, and respond to a well-known set of
commands (specific to the component.) Specifically, Swing components are
Java Beans components, compliant with the Java Beans Component
Architecture specifications.

• Customizable: Given the programmatic rendering model of the Swing

framework, fine control over the details of rendering of a component is
possible in Swing. As a general pattern, the visual representation of a Swing
component is a composition of a standard set of elements, such as a
"border", "inset", decorations, etc. Typically, users will programmatically
customize a standard Swing component (such as a JTable) by assigning
specific Borders, Colors, Backgrounds, opacities, etc., as the properties of
that component. The core component will then use these property (settings)
to determine the appropriate renderers to use in painting its various aspects.
However, it is also completely possible to create unique GUI controls with
highly customized visual representation.

• Configurable: Swing's heavy reliance on runtime mechanisms and indirect

composition patterns allows it to respond at runtime to fundamental changes
in its settings. For example, a Swing-based application can change its look
and feel at runtime. Further, users can provide their own look and feel
implementation, which allows for uniform changes in the look and feel of
existing Swing applications without any programmatic change to the
application code.

• Lightweight UI: Swing's configurability is a result of a choice not to use the

native host OS's GUI controls for displaying itself. Swing "paints" its
controls programmatically through the use of Java 2D APIs, rather than
calling into a native user interface toolkit. Thus, a Swing component does
not have a corresponding native OS GUI component, and is free to render
itself in any way that is possible with the underlying graphics APIs.

However, at its core every Swing component relies on an AWT container, since
(Swing's) JComponent extends (AWT's) Container. This allows Swing to plug into
the host OS's GUI management framework, including the crucial device/screen
mappings and user interactions, such as key presses or mouse movements. Swing
simply "transposes" its own (OS agnostic) semantics over the underlying (OS
specific) components. So, for example, every Swing component paints its rendition
on the graphic device in response to a call to component.paint(), which is defined
in (AWT) Container. But unlike AWT components, which delegated the painting
to their OS-native "heavyweight" widget, Swing components are responsible for
their own rendering.

This transposition and decoupling is not merely visual, and extends to Swing's
management and application of its own OS-independent semantics for events fired
within its component containment hierarchies. Generally speaking, the Swing
Architecture delegates the task of mapping the various flavors of OS GUI
semantics onto a simple, but generalized, pattern to the AWT container. Building
on that generalized platform, it establishes its own rich and complex GUI
semantics in the form of the JComponent model. A review of the source of
Container.java and JComponent.java classes is recommended for further insights
into the nature of the interface between Swing's lightweight components and
AWT's heavyweight widgets.

• Loosely-Coupled/MVC: The Swing library makes heavy use of the

Model/View/Controller software design pattern, which conceptually
decouples the data being viewed from the user interface controls through
which it is viewed. Because of this, most Swing components have associated
models (which are specified in terms of Java interfaces), and the
programmer can use various default implementations or provide their own.
The framework provides default implementations of model interfaces for all
of its concrete components.

Typically, Swing component model objects are responsible for providing a concise
interface defining events fired, and accessible properties for the (conceptual) data
model for use by the associated JComponent. Given that the overall MVC pattern
is a loosely-coupled collaborative object relationship pattern, the model provides
the programmatic means for attaching event listeners to the data model object.
Typically, these events are model centric (ex: a "row inserted" event in a table
model) and are mapped by the JComponent specialization into a meaningful event
for the GUI component.

For example, the JTable has a model called TableModel that describes an interface
for how a table would access tabular data. A default implementation of this
operates on a two-dimensional array.

The view component of a Swing JComponent is the object used to graphically

"represent" the conceptual GUI control. A distinction of Swing, as a GUI
framework, is in its reliance on programmatically-rendered GUI controls (as
opposed to the use of the native host OS's GUI controls). (This distinction is a
source of complications when mixing AWT controls, which use native controls,
with Swing controls in a GUI.)
It must be noted that the typical use of the Swing framework does not require the
creation of custom models, as the framework provides a set of default
implementations that are transparently, by default, associated with the
corresponding JComponent child class in the Swing library. In general, only
complex components, such as tables, trees and sometimes lists, may require the
custom model implementations around the application-specific data structures.

(However, to get a good sense of the potential that the Swing architecture makes
possible, consider the hypothetical situation where custom models for tables and
lists are wrappers over DAO and/or EJB services.)

Finally, in terms of visual composition and management, Swing favors relative

layouts (which specify the positional relationships between components) as
opposed to absolute layouts (which specify the exact location and size of
components). This bias towards "fluid"' visual ordering is due to its origins in the
applet operating environment that framed the design and development of the
original Java GUI toolkit. (Conceptually, this view of the layout management is
quite similar to that which informs the rendering of HTML content in browsers,
and addresses the same set of concerns that motivated the former.)

Look and feel

Swing allows one to specialize the look and feel of widgets, by modifying the
default (via runtime parameters), deriving from an existing one, by creating one
from scratch, or, beginning with J2SE 5.0, by using the skinnable synth Look and
Feel (see Synth Look and Feel), which is configured with an XML property file.
The look and feel can be changed at runtime, and early demonstrations of Swing
frequently provided a way to do this.

Relationship to AWT
Since early versions of Java, a portion of the Abstract Window Toolkit (AWT) has
provided platform-independent APIs for user interface components. In AWT, each
component is rendered and controlled by a native peer component specific to the
underlying windowing system.

By contrast, Swing components are often described as lightweight because they do

not require allocation of native resources in the operating system's windowing
toolkit. The AWT components are referred to as heavyweight components.

Much of the Swing API is generally a complementary extension of the AWT rather
than a direct replacement. In fact, every Swing lightweight interface ultimately
exists within an AWT heavyweight component because all of the top-level
components in Swing (JApplet, JDialog, JFrame, and JWindow) extend an AWT
top-level container. However, the use of both lightweight and heavyweight
components within the same window is generally discouraged due to Z-order
incompatibilities.

The core rendering functionality used by Swing to draw its lightweight

components is provided by Java 2D, another part of JFC.

Relationship to SWT
The Standard Widget Toolkit (SWT) is a competing toolkit originally developed
by IBM and now maintained by the Eclipse Foundation. SWT's implementation
has more in common with the heavyweight components of AWT. This confers
benefits such as more accurate fidelity with the underlying native windowing
toolkit, at the cost of an increased exposure to the native platform in the
programming model.

The advent of SWT has given rise to a great deal of division among Java desktop
developers, with many strongly favoring either SWT or Swing. Sun's development
on Swing continues to focus on platform look and feel (PLAF) fidelity with each
platform's windowing toolkit in the approaching Java SE 7 release (as of December
2006). In the meantime, there are other sources of high-fidelity PLAFs, many of
which are collected on the javootoo site.

There has been significant debate and speculation about the performance of SWT
versus Swing; some hinted that SWT's heavy dependence on JNI would make it
slower when the GUI component and Java need to communicate data, but faster at
rendering when the data model has been loaded into the GUI[1]. However,
benchmarks show no clear winner, and the results greatly depend on the context
and the environments[2].

SWT serves the Windows platform very well but is considered by some to be less
effective as a technology for cross-platform development. By using the high-level
features of each native windowing toolkit, SWT returns to the issues seen in the
mid 90's (with toolkits like zApp, Zinc, XVT and IBM/Smalltalk) where toolkits
attempted to mask differences in focus behaviour, event triggering and graphical
layout. Failure to match behavior on each platform can cause subtle but difficult-
to-resolve bugs that impact user interaction and the appearance of the GUI.

Debugging of Swing applications

Swing application debugging can be difficult because of the toolkit's visual nature.
In contrast to non-visual applications, GUI applications cannot be as easily
debugged using step-by-step debuggers. One of the reasons is that Swing normally
performs painting into an off-screen buffer (double buffering) first and then copies
the entire result to the screen. This makes it impossible to observe the impact of
each separate graphical operation on the user interface using a general-purpose
Java debugger. There are also some common problems related to the painting
thread. Swing utilizes the AWT event dispatch thread for painting components. In
accordance with Swing standards, all components must be accessed only from the
AWT event dispatch thread. If the application violates this rule, it may cause
unpredictable behaviour. If long-running operations are performed in the AWT
event dispatch thread, repainting of the Swing user interface temporary becomes
impossible causing screen freezes.

There are special purpose diagnostic tools and utilities that facilitate the debugging
of Swing applications and address the problems mentioned above:

7. Software process model

During the development of the system, we followed the life cycle system,
which is a general practice in Cyber Mate. Keeping in line with the ISO 9000-3
terminology, the entire software lifecycle has been divided into six distinct
processes. We have followed the iterative waterfall model as the life cycle model
for our project.

The six processes of the software life cycle system are as follows:

• Feasibility study
• Requirement analysis and specification
• Design
• Coding and unit testing
• Integration and system testing
• Maintenance

Feasibility Study:

The main aim of the feasibility study is to determine whether it would be

financially and technically feasible to develop the product.
In this phase we have analyzed the collected data and arrive at the following:
 • An abstract problem definition. It is the rough description of the project
which considers only the important requirements and ignores the rest.
• Formulation of the different solution strategies.

• Analysis of alternative solution strategies to compare their benefits and

shortcomings. In this phase we estimates the resources required, cost of
development, and development time for each of the options.

Requirement Analysis And Specification:

The aim of the requirements analysis and specification phase is to understand
the exact requirements of the customer and to document them properly.

This phase consists of two distinct activities, namely requirements gathering

and analysis, and requirement specification.
Design:
The goal of the design phase is to transform the requirements specified in the
SRS document into a structure that is suitable for implementing in some
programming language.
In this phase we followed Object-oriented design (OOD) approach. In this
technique, various objects that occur in the problem domain and solution domain
are first identified and then the different relationships exists among those objects
are identified.
Coding And Unit Testing:
The purpose of the coding and unit testing phase of software development is to
translate the software design into source code and test each module in isolation as
this is the best way to debug the errors identified at this stage.

Integration And System Testing:

The basic goal of the integration and system testing is to ensure that the developed
system conforms to its requirement specification.

During integration and system testing phase, the modules are integrated in a
planned manner. We carried out the incrementally over a number of steps. During
each integration step, the partially integrated system is tested and sets of previously
planned modules are added to it. Finally, when all the modules have been
successfully integrated and tested, system testing is carried out.
Maintenance:
Maintenance of a typical software product requires much more effort than the
effort necessary to develop the product itself.
Maintenance involves performing any one or more of the following three kinds
of activities:
Corrective Maintenance:
Correcting errors that were not discovered during the product development
phase.
Perfective Maintenance:
Improving the implementation of the system, and enhancing the functionalities

of the system according to the customers requirements.

Adaptive Maintenance:
Porting the software to work in a new environment.

8. Problem Definition and Description

Time Table Management System:

Time Table Management System is a system for maintaining entire time table
generation process in a college, and keeping track of information about subjects,
labs, and teachers. Most major firms should have their own Time Table
Management System.

Existing System

The existing System was manual system. The need for computerization of the
existing system arose because of many difficulties, irregularities and inaccuracy
present in the current system. The main cause of the worry includes missing mails,
information delay, lack of interaction. In previous system colleges were
maintaining time table details manually in pen and paper, which was time taking
and costly. These all were the causes of the least management strategy. So, the
farm decided to computerize this System.
Proposed System

The proposed System is completely computer-based application. In the proposed

system administrator should not to worry about their late and improper
management of sales details. All the information will be available by just clicking
on a single button. Thousands of records can searched and displayed without
taking any significant time.

Advantages of the proposed system:

 On implementing this package the organization will get error

free data to analyze.
 Administrator will track the information of customers and items
easily.
 Daily sales report can be easily maintained and generated.
 It will give better planning process.
  This package would limit the time and money factor involve in
“Time Table Management Process”.
 Maintenance is much easier and accurate than the existing
manual system.
 Security features are somewhat higher than that of manual
approach.

Requirement Specification:

• System should be user friendly.

• It should be capable of handling multi-users simultaneously.

• System should be fast.

• Maintaining database of various items.

i. Adding new item

ii. Modifying the existing item
iii. Deleting the existing

• It should be able to manage the customer detail efficiently

i. Adding New Subjects

ii. Adding new Lab details

System must meet entire needs of the farm.

9. System Analysis & Design:

Analysis is the main focus of system development and is the stage where system
designers have to work at two levels of definition regarding the study of situational
issues and possible solutions in terms of “what to do” and “how to do”.
System Study

Definition Of The System:

A system is an orderly grouping of independent components linked together

according to a plan to achieve a specific objective. Its main characteristics are

organization, interaction, independent, integration and central objective a

system does not necessarily mean to a computer system. It may be a manual

system or any other

Needs Of The System:

• Social and economic factor:

A wave of social and economic changes often follows in the wake of the
new technology. New opportunities may arise to improve on a production
process or to do something that was not previously possible. Changes in the
ways individuals are organized into groups may then be necessary, and the
new groups may complete for economic resources with established units.
• Technological factor:
People have never before in a time when the scope of scientific inquiry was so

broad, so when the speed of applying the new technology accounts for many

changes in the organization.

• High level decisions and operating processes:

In response to technological, socio-economical factors, top-level managers may
decide to recognize operations and introduce new products.

To deal with these needs, people commonly seek new modified information to
support the decision. When that happens, then they obtain turn to a computer
system for help the information users and data processing specialist then work
together to complete a series of steps in a system study to produce output results to
satisfy information needs.
10.System analysis
System Analysis is a process by which we attribute process or goals to a human
activity, determine how well those purpose are being achieved and specify the
requirements of the various tools and techniques that are to be used within the
system if the system performances are to be achieved.

System Planning
Planning for information systems has a time horizon and a focus dimension.

The time horizon dimension specifies the time range of the plan, where as the

focus dimension relates whether the primary concern is strategic, managerial, or

operational. The Project that we were assigned was required to complete within 16

weeks. What we had planned is as follows:

Requirements analysis, Preliminary Investigation & Information Gathering

should be covered within the 1st and 2nd week. Since we were not aware of some of
the tools i.e. struts, web server, and tiles we had kept 3 weeks to understand the
knot & bolts of these tools. 9 Weeks for the design of the system under
development. 1 week for Testing & Implementation. And rest 2 reserve weeks.
Preliminary Investigation
The initial investigation has the objective of determining the validity of the
user’s request for a candidate system and whether a feasibility study should be
conducted.
The objectives of the problem posed by the user must be understood within the
framework of the organization’s MIS plan. We had investigated from the
concerned authority about the project
Information Gathering

A key part of feasibility analysis is gathering information about the present

system. The analyst must know what information to gather, where to find it, how to
collect it, and what to make of it. The proper use of tools for gathering information
is the key to successful analysis. The tools are the traditional interview,
questionnaires, and on-site observation.
Structured Analysis

The traditional tools of data gathering have limitations. An English narrative

description is often vague and difficult for the user to grasp. System flowcharts
focus more on physical than on logical implementation of the candidate system.
Because of these drawbacks, structured tools were introduced for analysis.
Structured analysis is a set of techniques and graphical tools (DFD) that allow the
analyst to develop a new kind of system specifications that are easily
understandable to the user.
11. DATA FLOW DIAGRAM

Data Flow Diagram is a diagrammatic representation of data movement through a

system –manual or automated - from inputs to outputs through processing. The
data flow diagrams help in the analysis of the flow of data through a system and
thus help in identifying the system requirements. These are of two types – Logical
Data Flow Diagrams and Physical Data Flow Diagrams. The Data Flow Diagram
(DFD) clarifies system requirements and identifies major transformations that will
become programs in system design. It is the starting point of system design that
decomposes the requirements specifications down to the lowest level of detail.

Logical Data Flow Diagrams

The Logical Data Flow Diagrams represent the transformation of the data from
input to output through processing logically and independently of the physical
components that may be associated with the system.

Physical Data Flow Diagrams

The Physical Dataflow Diagrams show the actual implementation and movement
of data between people, departments, and workstations. Each component of a DFD
is labeled with a descriptive name. Process names are further numbered that will be
used for identification purposes. The number assigned to a specific process does
not correspond to the sequence of processes. It is strictly for identification
purposes. A data flow diagram allows parallel activities i.e. a number of data-flows
coming out from the source and going into the destination. A DFD concentrates on
the data moving through the system and not on the devices or equipments. A DFD
may consist of a number of levels. The top-level diagram is called the Context
Diagram, which consists of a single process and plays a very important role in
studying the system. It gives the most general and broadest view of the system.
Move over it gives the pictorial representation of the scope boundaries of the
system under study.

NOTATIONS:

 Data-Flows show the movement of data in a specific direction from the

source to the destination. It represents a packet of data.

 Processes show the operations performed on the data, which transform it

from input to output.
  Sources and Destinations of data are the external sources and destinations of
data, which may be people, programs, organizations or other entities
interacting with the system, but are outside its boundary.

 Data Stores are places where data are stored such as files and tables.

Below is the top level DFD showing how the User’s request processed by the
server with database interaction and sends the response back to the user.

Feasibility Study

All projects are feasible when given unlimited resources and infinite time! But the
development of computer-based system is likely to be played by scarcity of
resources and difficulty in completion dates.

The feasibility of a computer-based system can be studied in three major areas:

Economic Feasibility
Technical Feasibility
Functional Feasibility

Economic Feasibility

An evaluation of development cost weighed against the ultimate income of benefit

derived from the developed system. Very important information contained in the
feasibility study is that it takes care of the cost benefit analysis, which is the
assessment of the economic justification for a computer based system project.

The system is very user friendly and only common terms are used in the
application and so it will not be difficult for the end-user in handling the system.
The system provides a very guidance for every step to follow while using.
Technical Feasibility

A study of function, performance and constraints that may affect the ability to
achieve an acceptable system. The analyst evaluates the technical merits of the
system, while at the same time collects additional information about performance,
reliability and maintainability end products.

Technology is not a constraint to system development. The latest technologies are

incorporated so as to achieve the best of these new developments on the system.
The systems developed fully generalize, so that any future expansion will not be a
problem.
Functional Feasibility:
The system will be acceptable to the users who will be helped greatly by the
system, further the involvement of the user in each part of the development will be
helpful in increasing its success factor. The current existing system is less
interactive and not up to the mark in terms of customer support.

From all these, we can conclude that this system is economically, technically and
functionally feasible.
Project Approval
Those projects that are both feasible and desirable should be put into a schedule.
After a project request is approved, its cost, priority, completion time and
personal requirement are estimated and used to determine where to add it to an
existing list.

DATA FLOW DIAGRAM

Context Level Diagram

Time Table Time Table

Administrator Management
0.0

First Level DFD

Admin Admin

Master
Entry Reporting Report
1.0 2.0

Admin Admin

DataStore
DataStore
Branch Subject
Master Master
Second Level DFD 1.1 1.2

Branch Subject
Master Master
Admin Admin

Period Teacher
Master Master
1.3 1.5

Period
Teacher
Master

Admin

Lab
Master
1.4

Lab Master
E-R DIAGRAM
 DATABASE DESCRIPTION

Table : - Branch
Desc :- This Table is for maintaining the available branches

Table :- Labs
DEsc :- This table keeps the information aout the branch information.

Table:- Lab assist

Desc :- This table contains the information about all the lab assistances

Table :- Period
In this table we are maintaining the period details.
Table :- Subject
This table is for maintaining the details record about the subjects.

Table :- Teacher
This table contains the teacher’s details
 SCREEN LAYOUTS

This is the main home page of the application.

In this screen we have to maintain the branch details. We can also update and
remove the details of the branch.
This page is responsible for maintaining the teacher information.
Subject management
Period management
Lab Details Management
Lab Assistance management
In this page the application ask you for the batch to generate report.
In this page the application ask you for the educational Session to generate report.
This page provides the fully functional time table.
TESTING

Testing is the one step in the software engineering process that could be viewed as
destructive rather than constructive. Testing requires that the developer discard
preconceived notions of the “correctness” of the software just developed and
overcome a conflict of interest that occurs when errors are uncovered.

If testing is conducted successfully, it uncovers errors in the software. As a

secondary benefit, testing demonstrates that software functions appear to be
working according to the specification. Testing provides a good indication of
software reliability and some indication of software quality as a whole.

Testing cannot show the absence of defects, it can only show that software defects
are present.

As the developed software does not fulfill all the requirements of an organization,
so it is not possible to test with real time data.

Still then we tried our best to test each individual module and also as an integrated
modules (as a whole) with sufficient data that may an organization have, fulfilling
the objective of our “Time Table Management System”.

Testing performs a very critical role for quality assurance and ensuring the
reliability of the software. During testing, the program to be tested is executed with
a set of test cases and output of the program for the test cases and output of the
program for the test case is evaluated to determine if the program is performing as
it is expected to. Hence

• Testing is the process of executing a program with the intention of finding

errors.
• A good test case is the one that has a high probability of finding as yet
undiscovered error.
• A successful test is one yet uncovers as yet undiscovered errors.

Testing is performed according to two different strategies:

.
Code Testing:
The code testing strategy examines the logic of program i.e. the analyst develops
test cases that results in executing every instruction in the program. Basically
during code testing every path through the program is tested.

Specification Testing:
To perform specification testing the analyst examines the specification starting
what the program should do and how it should perform under various conditions.
Then test cases are developed for each .In order to find which strategies to follow,
levels of testing should be followed

Levels of Testing

The basic levels are unit testing, integration testing, system testing and acceptance
testing. These different levels of testing attempt to
detect different types of faults. The different levels of testing are as follows:

Unit Testing:
In this testing different modules are tested against specification produced during
design of the modules. Unit testing is essential for verification of code produced
during the coding phase and hence its main goal is to test internal logic modules.
Integration Testing:
In this testing tested modules are combined into subsystems which are then tested.
The goal here is to see if the modules can be indicated properly and emphasis is
being on testing interfaces between modules.
System testing:
In this testing the entire software system is tested. The reference document for this
process is the requirements document and the goal is to see if the system meets its
requirements.

This is normally performing on realistic data of the client to demonstrate for the
software is working satisfactorily. Testing here focus on external behavior of the
system.

System Implementation

Implementation is the stage of the project when the theoretical design turned into a
working system. At this stage the main workload, the up heal and the major impact
on the existing practices shift to user department. If the implementation stage is not
carefully planned and controlled, it can cause chaos. Thus it can be considered to
be the most crucial stage in achieving a new successful system and in giving the
users confidence that the users confidence that the new system will work and be
effective.

The implementation view of software requirements presents the real worlds

manifestation of processing functions and information structures. In some cases a
physical representation is developed as the first step in software design. However
most computer-based systems are specified in a manner that dictates
accommodation of certain implementation details.

Implementation involves careful planning, investigation of current system and

constraints on implementation, design of methods to achieve the changeover,
training of staff in the changeover procedures and evaluation of changeover
methods. The first task is the implementation planning i.e. deciding the methods
and time scale to be adopted.

Once the planning has been completed, the major effort in the computer
department is to ensure that the programs in the system are working properly. At
the same time the user department must concentrate on training user staff. What
the staffs have been trained, a full system test can be carried out, involving both the
computer and clerical procedures.

The main steps of implementation includes

1. Installing client machine.
2. Installing the software on the server.
3. Training the operational staff.
 Requirements keep changing with time so the implementation of this
project may change with time hence implementation is an ongoing process, which
may change in future.

DISCUSSION

As we discussed earlier during project “time does not permit to complete the entire
project, so as a part of the whole is being carried out and being submitted as the
project in our curriculum. Total software along with extensive features will be
submitted as Major project”, here is the entire Time Table Management System
with extensive features fulfilling the requirements of any modern distribution
farms.

Although we have attempted to make the entire package full proof of errors, it may
have some inherent bugs (beyond out knowledge) as it is yet to being tested with
real time data.

Lastly, we will carry our effort in developing the software fulfilling the basic
requirements of any distributing farm, if time permits.

We do believe that the system will satisfy the basics and will prove to be user
friendly and effective software whenever it’s being implemented in the
organization.
 BIBLIOGRAPHY

1. Complete Reference J2SE 5th edition

2. www.forum.sun.java.com