CHAPTER 1

1. INTRODUCTION
1.1 COMPANY PROFILE
Accent is an embedded consultancy and software development firm
headquartered in chennai with presence in Bangalore and Trichy. Our clientele include
ECI! "ortis! Alstom! Elgi Equipments! C#AC! "ortis! IIT$%adras& to name a few.
Accent has been providing a range of quality products and services targeting
industrial automation! Biomedical! Biometrics! #ata Acquisition and Control. 'e
leverage our technological e(pertise in )eal Time! Embedded and *C hosted +ardware
and ,oftware development combined with our application domain -nowledge to
provide customi.ed services.
"or the last three years Accent has been wor-ing as a bridge to improve
/Industry Institute Interaction0. Accent represents the leading companies li-e 1ational
Instruments! Atmel to deliver their technologies in colleges by setting up /Centre of
E(cellence0 to bridge the technolog gap. ,tudents benefit by getting hands one
e(perience in current technology with helps in placement. College benefits by providing
better value addition to students and companies benefits by creating -nowledge base for
system integrators.
OUR PARTNERS
Accent is the preferred systems integrated and authori.ed training partner for
national instruments a leading data acquisition company. 1ational instruments are
transforming the way engineers and scientists design! prototype and deploy systems for
measurement! automation and embedded applications. Accent trains student in ab view
so that the student can ta-e his /CA#0 certification valid internationally.
Accent is atmel2s #esign Consultant! 3niversity program partment and
authori.ed corporate training partner and is listed in the consultance section of the
business partners. Third party vendors page on the atmel Corporation website. This
certification is given based on our various designs we have developed for our customers
4
OUR TEAM
Being a professionally run organi.ation we understand the importance of process
to deliver training successfully. Our team comprises of the following s-illed category
personnel in broad terms.
OUR PEDAGOGY
%a5ority of our training modules will be incorporated using /earning by
#oing0 method. This enables participants to understand how a specific function would
be used for! see how it is done and then practice using e(ercises and real$case scenarios.
There is a heavy emphasis on practical hands$on application of the learned techniques.
Our course #elivery ob5ectives are achieved through these full$cycle activities
SERVICE OFFERINGS
Accent design the courses that emphasi.e pedagogy of active learning. 'e
believe that technology s-ills must be practiced e(tensively in order to be properly
mastered. As a result! we opt for plentiful hands$on e(ercises over lengthy lectures. This
approach allows you to practice under the support and guidance of an e(pert instructor
and trained classroom coordinators. 'e have a gamut of technology training courses
designed to serve right from a second year student to a 6ob Aspirant in IT or Core
Industry.
Our broad base of e(perience and ongoing process allows us to continually
change! update and adapt our s-ill development to meet your individual learning needs.
Our course portfolio could be classified as follows based on educational
qualification and level of e(pertise required by participant.
1.2 OBJECTIVE
Overview is the narrative e(planation of the purpose and scope of the pro5ect
and the reason for underta-ing the feasibility study. The pro5ect entitled /*lacement
Consultancy0 to include %asters! Transactions and 7uery analysis is as follows. In this
system includes all those activities that ta-e place to convert from the old system to the
new. The old system consists of manual operation! which is operated in a very different
manner from the proposed new system. In this traffic flow system a proper
implementation is essential to provide a reliable system to meet the requirements of the
8
organi.ation. An improper installation may affect the success of the computeri.ed
system.
The main ob5ective of this software development is to computeri.e the daily
transaction process of the Construction office and use the data to generate required
report. "or the confidential purpose only authori.ed users are allowed to access the
software. This can be maintained by providing user name and password security. The
consultancy is having all the rights to create! modify and delete the user and other
activities. +e is also having the right to generate required reports.
They include the following ob5ectives9
The more speciali.ed a system is the less able it is to adapt to different
circumstances.
The more general$purpose a system is! the less optimi.ed it is for any particular
situation. But the more the system is optimi.ed for a particular situation! the less
adaptable it will be to new circumstances.
The larger a system is the more of its resources that must be devoted to its
everyday maintenance.
:
CHAPTER 2
2. SYSTEM ANALYSIS
2.1 EXISTING SYSTEM
The study of the e(isting system deals with needed to carry out preliminary
investigation. The study proposal should be produced by user department and the
system study can be performed only on the e(isting system. ,ince it gives the structure
and function of the system. The methods used in the system study were interviews!
observation and discussions.
Interview are used to obtain the information regarding the e(isting system
performance! design of the screen! validation$chec-ing changes in the old system and
the interviews were conducted with user department.
Observations are used to correct the system to identify the coding schemes
used! the types of storage structure and etc. #iscussions were carried out to choose the
best pac-age for converting the e(isting system.
At present! the A**ICA1T #ETAI,! E%*O;E), #ETAI, are
maintained manually in many organi.ations. It is cumbersome and the process is time
consuming.
2.1.1 DRAWBACKS OF THE EXISTING SYSTEM
There is a chance for loss of record due to mishandling.
There is a possibility for error while updating details.
)eference to the previous details is tedious.
The process of transaction was found to be very slow.
<
2.2 PROPOSED SYSTEM
The *roposed system is mainly concerned with Cost Effect of the system. As
these days! maintaining the database about concern in very important
FEATURES OF PROPOSED SYSTEM
*rovides a user friendlier interface.
#eveloped in 5ava. ,o platform independent.
+ighly fle(ible.
1o special s-ills required to operate.
ow cost.
=ery easy to use.
2.3 FEASIBILITY STUDY
The feasibility analysis is designed to determine whether or not! given the
pro5ect environment! a pro5ect will be successful >in virtually any interpretation of that
word?. A feasibility analysis may be conducted for a pro5ect with an emphasis on
financial viability! environmental integrity! cultural acceptability! or political
practicability. It is a determination as to the li-elihood of success and a description of
how that determination was achieved
Economical "easibility
Operational "easibility
Technical "easibility
2.3.1 ECONOMICAL FEASIBILITY
Economic analysis is the most frequently used method for evaluating the effectiveness
of a new system. %ore commonly -nown as cost@benefit analysis! the procedure is to determine
the benefits and savings that are e(pected from a candidate system and compare them with
costs. If benefits outweigh costs! then the decision is made to design and implement the system.
An entrepreneur must accurately weigh the cost versus benefits before ta-ing an action. Time
Based9 Contrast to the manual system management can generate any report 5ust by single clic-.
A
Cost Based9 1o special investment is needed to manage the tool. 1o specific training is
required for employees to use the tool. Investment requires only once at the time of installation.
The software used in this pro5ect is freeware so the cost of developing the tool is minimal
2.3.2 OPERATIONAL FEASIBILITY
Is a measure of how well a proposed system solves the problems! and ta-es
advantages of the opportunities identified during scope definition and how it satisfies
the requirements identified in the requirements analysis phase of system development.
2.3.3 TECHNICAL FEASIBILITY
The assessment is based on an outline design of system requirements in terms of Input!
*rocesses! Output! "ields! *rograms! and *rocedures. This can be quantified in terms of
volumes of data! trends! frequency of updating! etc. in order to estimate whether the new system
will perform adequately or not this means that feasibility is the study of the based in outline.
B
CHAPTER 3
SYSTEM SPECIFICATION
3.1 HARDWARE REQUIREMENTS
*)OCE,,O) 9 *E1TI3% III CBB %+.
)A% 9 8AB %B ## )A%
%O1ITO) 9 4A0 COO)
+A)# #I,D 9 8E FB
"O**; #)I=E 9 4.<< %B
C##)I=E 9 F A8G
DE;BOA)# 9 ,TA1#A)# 4E8 DE;,
%O3,E 9 : B3TTO1,
3.2 SOFTWARE REQUIREMENTS
A1F3AFE 9 6A=A
")O1T E1# TOO 9 ,'I1F
BACD E1# TOO 9 %y,7
O*E)ATI1F ,;,TE% 9 'I1#O', G*.
H
CHAPTER 4
SOFTWARE DESCRIPTION
4.1 FRONT END
JAVA OVERVIEW
6ava is a high$level language that can be characteri.ed by all of the following
e(hortations.
,imple
Ob5ect Oriented
#istributed
%ultithreaded
#ynamic
Architecture 1eutral
*ortable
+igh performance
)obust
,ecure
In the 6ava programming language! all the source code is first written in plain
te(t files ending with the .5ava e(tension. Those source files are then compiled into
.class files by the 6ava compiler >5avac?. A class file does not contain code that is native
to your processorI it instead contains byte codes $ the machine language of the 6ava
=irtual %achine. The 6ava launcher tool >5ava? then runs your application with an
instance of the 6ava =irtual %achine.
JAVA PLATFORM
A platform is the hardware or software environment in which aprogram runs. The
most popular platforms are %icrosoft 'indows! inu(! ,olaris O, and %acO,. %ost
platforms can be described as a combination of the operating system and underlying
C
hardware. The 5ava platform differs from most other platforms in that it2s a software$
only platform that runs on the top of other hardware$based platforms.
The 5ava platform has two components9
The 6ava =irtual %achine.
The 6ava A*I
6ava =irtual %achine is the base for the 5ava platform and is pored onto various
hardware$based platforms.
The A*I is a large collection of ready$made software components that
provide many useful capabilities! such as F3I widgets. It is grouped into libraries of
related classes and interfaces! these libraries are -nown as pac-ages.
As a platform$independent environment! the 6ava platform can be a bit
slower than native code. +owever! advances in compiler and virtual machine
technologies are bringing performance close to that of native code without threatening
portability.
WHATS NEW IN JAVA TECHNOLOGY!
The general$purpose! high$level 6ava programming language is a
powerful software platform. Every full implementation of the 6ava platform gives you
the following features9
#evelopment Tools9
The development tools provide everything you2ll need for compiling!
running! monitoring! debugging! and documenting your applications.
As a new developer! the main tools you2ll be using are the 6ava compiler
>5avac?! the 6ava launcher >5ava?! and the 6ava documentation >5avadoc?.
Application programming Interface >A*I?99
J
The A*I provides the core functionality of the 6ava programming
language. It offers a wide array of useful classes ready for use in your own applications.
It spans everything from basic ob5ects! to networ-ing and security.
#eployment Technologies9
The 6#D provides standard mechanisms such as 6ava 'eb ,tart and 6ava
*lug$In! for deploying your applications to end users.
3ser Interface Tool-its9
The ,wing and 6ava 8# tool-its ma-e it possible to create sophisticated
Fraphical 3ser Interfaces >F3Is?.
JAVA SWING
The ,wing tool-it includes a rich set of components for building F3Is and
adding interactivity to 6ava applications. ,wing includes all the components you would
e(pect from a modern tool-it9 table controls! list controls! tree controls! buttons! and
labels. ,wing is far from a simple component tool-it! however. It includes rich undo
support! a highly customi.able te(t pac-age! integrated internationali.ation and
accessibility support. To truly leverage the cross$platform capabilities of the 6ava
platform! ,wing supports numerous loo- and feels! including the ability to create your
own loo- and feel. The ability to create a custom loo- and feel is made easier with
,wing! a loo- and feel specifically designed to be customi.ed. ,wing wouldnKt be a
component tool-it without the basic user interface primitives such as drag and drop!
event handling! customi.able painting! and window management.
"unctionality and the ability to create a program that can wor- in different
languages and by users with different input devices.
The ,wing tool-it includes a rich array of components9 from basic
components! such as buttons and chec- bo(es! to rich and comple( components! such as
tables and te(t. Even deceptively simple components! such as te(t fields! offer
sophisticated functionality! such as formatted te(t input or password field behavior.
There are file browsers and dialogs to suit most needs! and if not! customi.ation is
4E
possible. If none of ,wingKs provided components are e(actly what you need! you can
leverage the basic ,wing component functionality to create your own.
A ,wing application is built from a set of heavyweight containers! a set of
lightweight containers! and a hoard of F3I components. +eavyweight containers
include anything that can contain lightweight containers and components! but cannot
itself be contained. These include9
6"rame Top$level window component that has a title barI these are typically used
to host application windows.
6Applet The container for a ,wing applet that resides inside an +T% page.
6#ialog 6ust as the name suggests! these are popup dialog windowsI they have to
be owned by either a 6"rame or a 6Applet! but they stand alone on the screen and
contain lightweight containers and components.
6'indow ,imilar to a 6#ialog! but it does not contain a title barI these are good
for building ,plash ,creens.
ightweight containers! on the other hand! are containers that contain
components and are themselves containedI they can be contained by a heavyweight
container or another lightweight container. The more popular ones include9
6*anel Feneric lightweight containerI it has a layout manager associated with it
and contains components placed according to that layout manager.
6Tabbed*ane As the name implies! this is a container that places its components
inside of tabs.
6,plit*ane +ere we have a container that displays two components! either
vertically or hori.ontally! separated by a moveable bar.
J,croll*ane This is a container that hosts a single component and adds
scrollbars to itI almost all ,wing components have support for the 6scroll*ane.
,ome of the more noticeable features of ,wing include9
44
F3I Components >Trees! Tables! ists! etc.?
oo-$and$feel support
#rag$and$drop support
DRAG"AND"DROP SUPPORT
#rag$and$drop is one of the seemingly most difficult features to implement in
user interface development. It provides a high level of usability and intuitiveness.
#rag$and$drop is! as its name implies! a two step operation. Code must to
facilitate dragging and code to facilitate dropping. ,un provides two classes to help with
this namely #rag ,ource and #rop Target
#rag$and$drop can be isolated into two distinct roles9
#ragging
#ropping
,upport for dragging means that you can allow users to clic- the mouse on some
ob5ect in your user interface! hold the mouse down! and drag the ob5ect somewhere else
in the application $ to another 6ava application! or to another application running in the
native operating system. #ragging is facilitated through the 5ava.awt.and.#rag,ource
class.
LOOK AND FEEL SUPPORT
,wing defines an abstract oo- and "eel class that represents all the information
central to a loo-$and$feel implementation! such as its name! its description! whether it2s
a native loo-$and$feel$ and in particular! a hash table > -nown as the /#efaults Table0?
for storing default values for various loo-$and$feel attributes! such as colors and fonts.
Each loo-$and$feel implementation defines a subclass of oo- And "eel >for
e(ample! swing .plaf.motif.%otifoo-And"eel? to provide ,wing with the necessary
information to manage the loo-$and$feel.
48
The 3I%anager is the A*I through which components and programs access
loo-$and$feel information >they should rarely! if ever! tal- directly to a
oo-And"eelinstance?. 3I%anager is responsible for -eeping trac- of which
oo-And"eel classes are available! which are installed! and which is currently the
default. The 3I%anager also manages access to the #efaults Table for the current loo-$
and$feel.
DYNAMICALLY CHANGING THE DEFAULT LOOK"AND"FEEL
'hen a ,wing application programmatically sets the loo-$and$feel! the ideal
place to do so is before any ,wing components are instantiated. This is because the
3I%anager.setoo-And"eel>? method ma-es a particular oo- And "eel the current
default by loading and initiali.ing that oo-And"eel instance! but it does not
automatically cause any e(isting components to change their loo-$and$feel.
)emember that components initiali.e their 3I delegate at construct timeI
therefore! if the current default changes after they are constructed! they will not
automatically update their 3Is accordingly. It is up to the program to implement this
dynamic switching by traversing the containment hierarchy and updating the
components individually.
>1OTE9 ,wing provides the ,wing3tilities.updateComponentTree3>? method to assist
with this process?.
FEATURES OF SWING
Even the simplest ,wing components have capabilities far beyond what the
A'T components offer.
,wing buttons and labels can display images instead of ! or in addition to!
te(t
;ou can easily add or change the borders drawn around most ,wing
components. "or e(ample! it2s easy to put a bo( around the outside of a
container or label.
;ou can easily change the behavior or appearance of a ,wing component by
4:
either invo-ing methods on it or creating a subclass of it.
,wing components don2t have to be rectangular. Buttons! for e(ample! can
be round.
4<
Assistive technologies such as screen readers can easily get information from
,wing components. "or e(ample! a tool can easily get the te(t that2s
displayed on a button or label.
,wing lets you specify which loo- and feel your program2s F3I uses. By
contrast! A'T components always have the loo- and feel of the native
platform.
4.2 JAVA FEATURES
T#$ V%&'()* M)+#%,$
A LrealL machine runs machine code for that machine only.
A LvirtualL machine runs its own sort of binary data
The 6ava =irtual %achine >6=%? is a normal program on each architecture
It ta-es 6ava Byte code as its input language
3sing non$native machine code as the input is called LinterpretingL.
PROGRAM PORTABILTY
The 6ava =irtual %achine >6=%? is a normal program on each architecture
It ta-es 6ava Byte code as its input language
A single 6ava program will run on any platform
4A
F%- 3.1 J).) P*)'/0&1 D$2+&%3'%0,
If the 6=% has been ported to a platform then that platform can run any 6ava
program.
If a program is written in 6ava then it can be run on any platform with a 6=%.
JDBC
In an effort to set an independent database standard A*I for 6ava! ,un
%icrosystems developed 6ava #atabase Connectivity! or 6#BC. 6#BC offers a generic
,7 database access mechanism that provides a consistent interface to a variety of
)#B%,s. This consistent interface is achieved through the use of /plug$in0 database
connectivity modules! or drivers. If a database vendor wishes to have 6#BC support! he
or she must provide the driver for each platform that the database and 6ava run on.
To gain a wider acceptance of 6#BC! ,un based 6#BC2s framewor- on O#BC.
As you discovered earlier in this chapter! O#BC has widespread support on a variety of
platforms. Basing 6#BC on O#BC will allow vendors to bring 6#BC drivers to mar-et
much faster than developing a completely new connectivity solution.
6#BC was announced in %arch of 4JJB. It was released for a JE day public
review that ended 6une C! 4JJB. Because of user input! the final 6#BC v4.E specification
was released soon after.
The remainder of this section will cover enough information about 6#BC for
you to -now what it is about and how to use it effectively. This is by no means a
complete overview of 6#BC. That would fill an entire boo-.
JDBC GOALS
"ew software pac-ages are designed without goals in mind. 6#BC is one that!
because of its many goals! drove the development of the A*I. These goals! in
con5unction with early reviewer feedbac-! have finali.ed the 6#BC class library into a
solid framewor- for building database applications in 6ava.
4B
The goals that were set for 6#BC are important. They will give you some
insight as to why certain classes and functionalities behave the way they do. The eight
design goals for 6#BC are as follows9
SQL LEVEL API
The designers felt that their main goal was to define a ,7 interface for 6ava.
Although not the lowest database interface level possible! it is at a low enough level for
higher$level tools and A*Is to be created. Conversely! it is at a high enough level for
application programmers to use it confidently. Attaining this goal allows for future tool
vendors to /generate0 6#BC code and to hide many of 6#BC2s comple(ities from the
end user.
SQL CONFORMANCE
,7 synta( varies as you move from database vendor to database vendor. In an
effort to support a wide variety of vendors! 6#BC will allow any query statement to be
passed through it to the underlying database driver. This allows the connectivity module
to handle non$standard functionality in a manner that is suitable for its users.
J45+ M(2' B$ I13*$1$,')* O, T03 O/ C0110, D)')5)2$ I,'$&/)+$2
The 6#BC ,7 A*I must /sit0 on top of other common ,7 level A*Is. This
goal allows 6#BC to use e(isting O#BC level drivers by the use of a software interface.
This interface would translate 6#BC calls to O#BC and vice versa.
P&0.%4$ ) J).) I,'$&/)+$ T#)' I2 C0,2%2'$,' W%'# '#$ R$2' O/ T#$ J).)
S62'$1
Because of 6ava2s acceptance in the user community thus far! the designers
feel that they should not stray from the current design of the core 6ava system.
4H
JAVA AWT SWING
The original F3I components from the Abstract 'indowing Tool-it pac-age
6ava.awt >also called the A'T? are tied directly to the local platform2s graphical user
interface capabilities. ,o! a 5ava program e(ecuting on different platforms has a
different appearance and sometimes even different user interacts with the program are
-nown as that program2s loo- and feel. The ,wing components allow the programmer
to specify a different loo- and feel across all platforms! or even to change the loo-$and$
feel while the program is running.
,wing components are often referred to as lightweight components they are
written completely in 5ava so they are not /weighed down0 by the comple( F3I
capabilities of the platform on which they are used.
A'T Components >many of which parallel the ,wing components? that are tied
to the local platform are correspondingly called heavyweight components they are rely
on the local platform2s windowing system to determine their functionality and their loo-
feel. Each heavyweight component has a peer >from pac-age 5ava.awt.peer? that is
responsible for the interactions between the component and the local platform to display
and manipulate the component.
The inventors of 6ava wanted to design a language which could offer solutions
to some of the problems encountered in modern programming. They wanted the
language to be not only reliable! portable and distributed but also simple! compact and
interactive. ,un %icrosystems officially describes 5ava with the following attributes.
COMPILED AND INTERPRETED
3sually a computer language is either compiled or interpreted. 6ava combines
both these approaches thus ma-ing 5ava a two$stage system. "irst! 5ava compiler
translates source code into what is -nown as byte code instructions. Byte codes are not
machine instructions and therefore! in the second stage! 5ava interpreter generates
machine code that can be directly e(ecuted by the machine that is running the 5ava
program. 'e can thus say that 5ava is both a compiled and interpreted languages.
4C
PLATFORM"INDEPENDENT AND PORTABLE
The most significant contribution of 5ava over other languages is its portability.
6ava programs can be easily moved from one computer system to another! anywhere
and anytime. Changes and upgrades in operating systems! processors and system
resources will not force any changes in 6ava programs. This is the reason why 6ava has
become a popular language for programming on Internet which interconnects different
-inds of systems worldwide. 'e can download a 6ava applet from a remote computer
onto out local system via Internet and e(ecute it locally.
This ma-es the Internet an e(tension of the user2s basic system providing
practically unlimited number of accessible applets and applications.
6ava ensures portability in two ways. "irst! 6ava compiler generates byte code
instructions that can be implemented on any machine. ,econdly! the si.es of the
primitive2s data types are machine$independent.
OBJECT"ORIENTED
6ava is a true ob5ect$oriented language. Almost everything in 6ava is an ob5ect.
All program code and data reside within ob5ects and classes. 6ava comes with an
e(tensive set of classes! arranged in pac-ages that we can use in our programs by
inheritance. The ob5ect model in 6ava is simple and easy to e(tend.
ROBUST AND SECURE
6ava is a robust language. It provides many safeguards to ensure reliable code.
It has strict compile time and run time chec-ing for data types. It is designed as a
garbage$collected language relieving the programmers virtually all memory
management problems. 6ava also incorporates the concept of e(ception handling which
captures series errors and eliminates any ris- of crashing the system.
,ecurity becomes an important issue for a language that is used for
programming on Internet. Threat of viruses and abuse of resources is everywhere. 6ava
systems not only verify all memory access but also ensure that no viruses are
4J
communicated with an applet. The absence of pointer in 6ava ensures that programs
cannot gain access to memory locations without proper authori.ation.
DISTRIBUTED
6ava is designed as a distributed language for creating applications on networ-s.
It has the ability to share both data and programs. 6ava applications can open and
access remote ob5ects on Internet as easily as they can do in a local system. This
enables multiple programmers at multiple remote locations to collaborate and wor-
together on a single pro5ect.
SIMPLE7 SMALL AND FAMILIAR
6ava is a small and simple language. %any features of C and CMM that are either
redundant or sources of unreliable code are not part of 6ava. "or e(ample! 5ava does not
use pointers! preprocessor header files! go to statement and many others. It also
eliminates operators overloading and multiple inheritance.
"amiliarity is another stri-ing feature of 6ava. To ma-e the language loo-
familiar to the e(isting programmers! it was modeled on C and CMM languages. 6ava
uses many constructs of C and CMM and therefore! 6ava code /loo-s li-e a CMM0 code.
MULTITHREADED AND INTERACTIVE
%ultithreaded means handling multiple tas-s simultaneously. 6ava supports
multithreaded programs. This means that we need not wait for the application to finish
one tas- before beginning another. "or e(ample! we can listen to an audio clip while
scrolling a page and at the same time download an applet from a distant computer. This
feature greatly improves the interactive performance of graphical applications.
HIGH PERFORMANCE
6ava performance is impressive for an interpreted language! mainly due to the
use of intermediate byte code. According to ,un! 6ava speed is comparable to the native
C@CMM. 6ava architecture is also designed to reduce overheads during runtime.
8E
CHAPTER 8
PROJECT DESCRIPTION
8.1 PROBLEM DEFINITION
The problem may be defined due to the numerous limitations in the e(isting
system. The e(isting system is more comple( and specific hardware is required to
obtain and process the data.
The identification of need has been e(clusively pointed in the following areas.
The proposed system should reach each and every noo- and corner of the
public with much more fle(ibility.
The system should be able to be operator even by the novice users.
The system should be able to reach every middle class person.
8.2 OVERVIEW OF THE PROJECT
This pro5ect aims at that are involved in the placement consultancy. This is the
process! which is primarily concerned with the management in the society. The main
ob5ective of the pro5ect wor- is the development of a software pac-age in 6ava which
will automate all the details such as applicant details and employer2s details. The
pac-age is fully menu$driven! interactive! user$friendly and attractive. The function such
as data entry! updating! retrieval and deletion can be made effectively. ,pecial care has
been provided to ensure data integrity and security.
*ACE%E1T CO1,3TA1C; in te(tile describes so far has designed tested
and documented completely. The pac-age has been developed to overcome the
problems with the e(isting system. The software produced is so useful that the system
efficiency provides the required information at a time! regarding the admission system.
The software is so attractive and user friendly. It is high interactive too. It is trying at
most to avoid typing by the user. The software appears more fle(ible! since it is
84
completely menu$driven. It maintains data consistency. The system reduces wor- loaded
and produces adequate and timely information as and when needed.
PLACEMENT CALCULUS
M0&$ )50(' '#$ S0('# D)90') M)'#$1)'%+2 R$.%2%0, C011%''$$ M$15$&2
)o(ie Ahlbrecht! 8nd Frade Classroom Teacher! ,iou( "alls *ublic ,chool
#istrict <J$A ,outh #a-ota Teacher of the ;ear 8EE< *residential Award for E(cellence
in %athematics and ,cience Teaching 8EE8 D$B %athematics 1ational Board Certified
Teacher! %iddle Childhood Feneralist! 8EE4 ,outh #a-ota Council of Teachers of
%athematics! %ember
6ay Berglund! ,econdary %athematics Teacher! Fettysburg ,chool #istrict
,outh #a-ota Council of Teachers of %athematics! %ember ,teve Caron! ,econdary
%athematics Teacher! Aberdeen *ublic ,chool B$4
,tate evel *residential Awardee for E(cellence in %athematics and ,cience
Teaching! B times ,outh #a-ota Council of Teachers of %athematics! =ice *resident
%ary 6o Christensen! 8nd Frade Teacher! 'ebster ,chool #istrict *residential
Award for E(cellence In ,cience and %athematics! 4JJJ Elementary %athematics
Ellie Cooch! Cth Frade %athematics Teacher! ,pearfish ,chool #istrict
*residential Award for E(cellence in %athematics and ,cience Teaching! H$48
%athematics 4JJJ ,outh #a-ota Council of Teachers of %athematics! %ember
1ational Board Certified Teacher! Candidate
6ames Cutshaw! Hth Frade and ,heltered %athematics Teacher! ,iou( "alls
*ublic ,chool #istrict <J$A ,outh #a-ota Council of Teachers of %athematics! %ember
%arinela Cyriac-s! English anguage earner Instructor! +uron ,chool
#istrict E8$8
Carol #e=ries! <th Frade Teacher! Bennett County ,chool #istrict! Bennett
County Education Association! *resident
88
#r. )alph Erion! *rofessor of Educational eadership! ,outh #a-ota ,tate
3niversity Dathleen "amestad! ,pecial Education Teacher! ,iou( "alls *ublic ,chool
#istrict <J$A ,outh #a-ota Education Association! eadership Award
"amily %atters Award! ,iou( "alls *ublic ,chool #istrict #istrict Curriculum
Committee %ember! anguage Arts! ,cience and ,ocial ,tudies
1ominee for *residential Award for E(cellence in %athematics and ,cience
Teaching! 8EE: #ebra "ord! <th Frade Teacher! Chamberlain ,chool #istrict
#istrict %ath Curriculum Committee %ember 'ho2s 'ho in American
Education #elta Dappa Famma! *ast Treasure
6ean Fomer! H$48 %athematics Teacher! #eubroo- Area ,chools ,outh
#a-ota Council of Teachers of %athematics *resident 8EE8$8EE< *residential Award for
E(cellence in %athematics and ,cience Teaching! H$48 %athematics! 4JJH
#oug +eller! H$C %athematics and )eading Teacher! +uron *ublic
,chools,outh #a-ota Association of %iddle evel Educators! *ast *resident ,outh
#a-ota Council of %athematics Teachers! %ember 'hoKs 'ho in American Education
Delly +inds! <th Frade Teacher! Aberdeen *ublic ,chools 1ational Board
Certified Teacher! Candidate ,outh #a-ota )eading Teacher of the ;ear! 8EE4
Allen +ogie! ,econdary %athematics Instructor! Brandon =alley ,chool
#istrict Teacher of the ;ear 1ominee! Brandon =alley ,chool #istrict! 4JJH ,outh
#a-ota Council of Teachers of %athematics! %ember
Charles +olmstrom! +igh ,chool %athematics Instructor! ,iou( "alls *ublic
,chool #istrict <J$A ,outh #a-ota Teachers of %athematics! *resident 8EE< N 8EEB
Ad5unct *rofessor! Colorado Technical 3niversity! ,iou( "alls Branch ,#CT% Award
for #istinguished ,ervice in ,# %athematics Education! 8EE4
=ic-i Dapust! Associate #irector! Center for the Advancement of %athematics
and ,cience Education! Blac- +ills ,tate 3niversity %iddle$level %ath ,pecialist and
8:
*rofessional #evelopment *rovider %edallion of E(cellence! 1atrona County ,chool
#istrict! >Casper! ';?
eo Deiser! +igh ,chool %athematics Instructor! Beresford ,chools
*residential Award for E(cellence in %athematics and ,cience Teaching! H$48
%athematics! 4JJB Eisenhower Committee %ember for ,outheast Area
CooperativeAd5unct Instructor! Dilian Community College ,outh #a-ota Council of
Teachers of %athematics! %ember
,usan Dessel! Cth Frade %athematics Teacher! %eade County ,chool #istrict
<B$4 #istrict %ath Curriculum Committee %ember
Cynthia Droon! +igh ,chool %athematics Instructor! %ontrose ,chool
#istrict <:$8 *residential Award for E(cellence in %athematics and ,cience Teaching!
H$48 %athematics! 8EE4 )adio ,hac- 1ational Teacher Award! 8EE4 ,outh #a-ota
Council of Teachers of %athematics ,ecretary and 'ebmaster
Brady unde! %iddle ,chool %athematics Teacher! 'atertown ,chool #istrict
#istrict Curriculum Committee %ember *ast *resident of 'atertown Education
Association*ast *resident of the ,outh #a-ota Association of %iddle evel Educators
,outh #a-ota Council of Teachers of %athematics! %ember
6an %artin! Coordinator of Assessment and Evaluation! Todd County ,chool
#istrict Outstanding )esearch *aper! American Educational )esearch Association
#iana %cCann! %iddle ,chool@+igh ,chool %athematics! Bon +omme
,chool #istrict <$8 *residential Award for E(cellence in %athematics and ,cience
Teaching! D$B %athematics! 4JJ: #istinguished ,ervice Award in %athematics 'ho2s
'ho in American Education! 'ho2s 'ho in Teaching! 'ho2s 'ho in American 'omen
,outh #a-ota Council for Teachers of %athematics! Treasurer.
*atricia %oore! Bth Frade %athematics Teacher! Broo-ings ,chool #istrict
#r.Curtis Olson! Chairperson and Associate *rofessor of %athematical
,ciences!3niversity of ,outh #a-ota ,outh #a-ota Council of Teachers of
%athematics! 1ewsletter Editor
8<
%ichele *erri.o! <th Frade Teacher! Aberdeen *ublic ,chools
*atricia )einers! Hth Frade %athematics Instructor! 'est Central ,chool
#istrict %athematics #epartment +ead! 4JJH$8EE: 'est Central %iddle ,chool
Teacher of the ;ear! 8EE4 'est Central ,chool #istrict Teacher of the ;ear! 4JJJ ,outh
#a-ota Council of Teachers of %athematics! %ember
%arie )itten! ,econdary %athematics Coordinator! )apid City Area ,chools
Advanced *lacement Calculus Frader@Consultant! ET, Folden Apple Award! 8EE8
,outh #a-ota Council of Teachers of %athematics! %ember 'hoOs 'ho Among
AmericaOs Teachers )apid City ,chools %ath =ertical Team
Dimberly ,chara! Bth Frade %athematics! ,cience and )eading Teacher!
)apid City Area ,chools Teacher of #istinction! 8EE8$8EE:! )apid City Area ,chools
#istrict %athematics Curriculum Committee Building eadership Team
)obert ,chuh! +igh ,chool %athematics Teacher! %cIntosh ,chool #istrict
4A$4 %athematics %entor ,outh #a-ota Council of Teachers of %athematics! %ember
and *ast =ice$*resident
6ames ,tearns! C$48 %ath! ,cience and Computer Teacher! Bristol ,chool
#istrict 4C$4 Bristol ,chool #istrict Technology Coordinator Bristol Education
Association! *resident ,outh #a-ota ,cience Teachers Association! 1ewsletter Editor
)C %ath Chairman
#oris ,tiles! <th Frade Teacher! *ierre *ublic ,chools ,# #estination
Imagination! ,tate Board %ember ,# Association of Fifted Children! ,tate Board
%ember
Anne Thompson! ,econdary %athematics Instructor! ,iou( "alls *ublic
,chool #istrict <J$A *residential Award for E(cellence in %athematics and ,cience
Teaching! H$48 %athematics! 4JJ4 ,andy 3llrich! 8nd Frade Teacher! Aberdeen *ublic
,chools
#elta Dappa Famma! *ast *resident )ebecca 3menthum! Bth Frade
%athematics Teacher! Belle "ourche ,chool #istrict 1ational Board Certified Teacher!
8A
Early Adolescence %athematics! 8EE4 *residential Award for E(cellence in %ath and
,cience Teaching! ,econdary %athematics! 4JJA ,outh #a-ota Council of Teachers of
%athematics! %ember
Floria =avra! <$C Teacher! ,pring =alley Colony! 'essington ,prings ,chool
#istrict Building *rincipal ,outh #a-ota Council of Teachers of %athematics! %ember
#a-ota TE, %ember #istrict %athematics! )eading and Fates Frant Committees
1ancy 'ard! Elementary %athematics Coordinator! )apid City Area ,chools
,eeing %ath *ro5ect! ,ite "acilitator ,trategic Tutoring! Trainer ,outh #a-ota Council
of Teachers of %athematics! %ember
SD CONTENT STANDARDS FOR K"12 MATHEMATICS
Technical Fuide to the ,outh #a-ota %athematics ,tandards! 4JJC Essential
Core ,tandards for %athematics! 8EE8
O'#$& S')'$ C0,'$,' S'),4)&42 F0& K"12 M)'#$1)'%+2
Alabama Course of ,tudy! 4JJH
California %athematics Content ,tandards! 4JJH
Dansas Curriculum ,tandards for %athematics! 4JJJ
%assachusetts %athematics Curriculum "ramewor-! 8EEE
1orth Carolina %athematics Curriculum! 4JJJ
Ohio D$48 %athematics Content ,tandards! 8EE4
=ermont "ramewor- of ,tandards and earning Opportunities! 8EEE
PROFESSIONAL PUBLICATIONS
1CT% *rinciples and ,tandards for ,chool %athematics! 8EEE
%athematics "ramewor- for the 8EE: 1ational Assessment of Educational
*rogress! 8EE8
Every Child %athematically *roficient9 An Action *lan of the earning "irst
Alliance! 4JJC
8B
%a-ing ,tandards %atter! American "ederation of Teachers! 8EE4
)ethin-ing ,chool )eform! "ordham "oundation! 8EE:
Adding It 3p9 +elping Children earn %athematics! 6eremy Dilpatric-! 6ane
,wafford! Bradford "indell! EditorsI %athematics earning ,tudy Committee! 1ational
)esearch Council >8EE4?
This boo- e(plores how students in pre$-indergarten through eighth grade learn
mathematics and recommends how teaching! curricula! and teacher education should
change to improve mathematics learning during these critical years. It also discusses
what is -nown from research about teaching for mathematics proficiency! focusing on
the interactions between teachers and students around educational materials and how
teachers develop proficiency in teaching mathematics.
+elping Children earn %athematics! 6eremy Dilpatric- and 6ane ,wafford!
Editors! %athematics earning ,tudy Committee! 1ational )esearch Council >8EE8?
This report provides comprehensive and reliable information that will guide
efforts to improve school mathematics from pre$-indergarten through eighth grade. The
authors e(plain the five strands of mathematical proficiency and discuss the ma5or
changes that need to be made in mathematics instruction! instructional materials!
assessments! teacher education! and the broader educational system and answers some
of the frequently as-ed questions that emerge regarding mathematics instruction. The
report concludes by providing recommended actions for parents and caregivers!
teachers! administrators! and policy ma-ers! stressing the importance of all sta-eholders
wor-ing together to ensure a mathematically literate society.
1ational Council of Teachers of %athematics 1CT% is a public voice of
mathematics education! providing vision! leadership! and professional development to
support teachers in ensuring mathematics learning of the highest quality for all students.
"ounded in 4J8E! 1CT% is the worldKs largest mathematics education organi.ation!
with nearly JE!EEE members and 8AE affiliates throughout the 3nited ,tates and
Canada.
8H
PRINCIPLES AND STANDARDS FOR SCHOOL MATHEMATICS
This crucial document updates the messages of 1CT%Ks previous ,tandards and
shows how student learning should grow across four grade bandsN pre$-indergarten
through second grade! third grade through fifth grade! si(th grade through eighth grade!
and ninth grade through twelfth grade. It incorporates a clear set of principles and an
increased focus on how studentsK -nowledge grows as shown by recent research. It also
includes ways to incorporate the use of technology to ma-e mathematics instruction
relevant and effective in a technological world.
ILLUMINATIONS
The Illuminations site is designed to LilluminateL the 1CT% *rinciples and
,tandards for ,chool %athematics. The site contains a growing array of Internet
resources that can be used to improve the teaching and learning of mathematics. This
site is part of the %arcopolo pro5ect! funded by %CI 'orldcom.
M+&$* M%4"C0,'%,$,' E%2$,#0:$& R$-%0,)* C0,20&'%(1 F0& M)'#$1)'%+2
A,4 S+%$,+$
%c)E E)C was established in 4JJ8 by the 1ational Eisenhower *rogram for
%athematics and ,cience Education as one of ten regional consortia across the 3nited
,tates. The mission of %c)E E)C is to promote and support systemic reform in
mathematics and science education in its seven$state region. %c)E E)C serves the
states of Colorado! Dansas! %issouri! 1ebras-a! 1orth #a-ota! ,outh #a-ota! and
'yoming. To facilitate change! %c)E E)C collaborates with state departments of
education! post$secondary institutions! 1ational ,cience "oundation$funded initiatives!
school districts! and other state and federal agencies.
SOUTH DAKOTA COUNCIL OF TEACHERS OF MATHEMATICS
The purpose of the ,outh #a-ota Council of Teachers of %athematics is to
encourage and maintain an active interest in and an appreciation of mathematics9
8C
promote professional growth of mathematics educatorsI provide a forum for the
e(change of views regarding the teaching of mathematicsI develop a cohesive lin-
between and to promote the cooperative study of mathematics education at all levelsI
integrate the study of mathematics into other areas of school curriculumI and relate the
study of mathematics to situations in life. ,#CT% hosts a conference each "ebruary
and a symposium each August to help achieve the goals listed above.
The Council provides support for ,outh #a-ota mathematics teachers!
connecting them to each other! and acts as a clearinghouse for information regarding
mathematics and mathematics education. %embers act individually and collectively as
consultants for school districts and for the ,outh #a-ota #epartment of Education.
SOUTH DAKOTA EDWEB
Created for ,outh #a-ota educators! parents and students! the ,outh #a-ota
Ed'eb provides a user$friendly format to connect to the worldwide web. The Educator
section provides lin-s to instructional resources! lesson plans! and on$line activities that
have been correlated to the ,outh #a-ota core content standards. The ,tudent section
provides a safe on$line learning environment with access to learning activities and
homewor- help to assist D$48 students to succeed in their studies. The *arent section
provides an inde( to websites that promote best practices and support parents within all
areas of child rearing.
The Council provides support for ,outh #a-ota mathematics teachers!
connecting them to each other! and acts as a clearinghouse for information regarding
mathematics and mathematics education. %embers act individually and collectively as
consultants for school districts and for the ,outh #a-ota #epartment of Education.
The site contains a growing array of Internet resources that can be used to
improve the teaching and learning of mathematics. This site is part of the %arcopolo
pro5ect! funded by %CI 'orldcom.
8J
8.3 MODULE DESCRIPTION
The pro5ect entitled /*ACE%E1T CO1,3TA1C;0 is used for the peoples
who want to -now the person details in directory and also it2s tells the specific features
of the particular person details. The modules involved in the pro5ects are!
ogin
Applicant details
Employers details
8.3.1 MODULES
LOGIN
Authori.ed persons only have the rights to enter into the application. It is
possible to require a username and password before being allowed access to a module
and databases.
APPLICANT DETAILS
Applicant is a student that we to apply for 5ob of higher studies. The applicant
can also be use in mar- sheet or any important document. Applicant details contain the
whole details of the students.
EMPLOYERS DETAILS
Employers use to give opportunity 5ob for student. If there is any vacancy then
provide 5ob to applicant. Employers are the one who provide the details of the vacancy
to the consultancy
:E
8.4 DATA FLOW DIAGRAM
#ata ,tore
=acancy
,uitable Applicant

:4
Consulta
ncy
Employers
Applicants
*lace
ment
)eport

All
Applic
ant

#etail
#ATA "O' #IAF)A%
A #ata "low #iagram >#"#? is a process$oriented graphical representation of an
application system. In the words of +offer! Feorge and =alacich >4JJJ?! a #"# is a
picture of the movement of data between e(ternal entities and the processes and data
stores within a system.
The components of a typical dataflow diagram are9 the process! the flow! the
data store! and the terminator.
THE PROCESS
The process shows a part of the system that transforms inputs into outputs. The
process is represented graphically as a +%&+*$ or bubble.
The processes should be numbered in order to conveniently reference them in
the #"#. A process is named or described with a single word! phrase! or simple
sentence. The process name should describe what the process does. A good name will
generally consist of a verb$ob5ect phrase such as CO%*3TE TAG )ATE.
THE FLOW
The flow is represented graphically by an )&&0: into or out of a process. The
flow is used to describe the movement of chun-s! or pac-ets of information from one
part of the system to another part. The flows represent data in motion.
The flows show direction9 an arrowhead at either end of the flow or possibly at
both ends indicates whether data is moving into or out of a process or both.
THE DATA STORE
The data store is used to model a collection of data pac-ets at rest. The notation
for a data store is two parallel lines! as shown in "igure. The name chosen to identify
the data store is the plural of the name of the pac-ets that are carried by flows into and
out of the data store.
:8
#ata stores are typically implemented as files or databases in a computeri.ed
systemI but a data store can also be data stored on punched cards! microfilm! or a
variety of other electronic forms. A data store might also consist of :$by$A inch cards
in a card bo(! or names and addresses in an address boo-! or several files folders in a
file cabinet! or a variety of other non$computeri.ed forms.
#ata stores are connect by flows to processes. #ata stores have two types of
flows9 a flow from a store and a flow to a store
A flow from a store is normally interpreted as a read or an access to information
in a data store. The data store is not changed when a pac-et of information moves from
the store along the flow.
A flow to a store is normally described as a write! an update! or possibly a
delete. The data store is changed as a result of the flow entering the store.
THE TERMINATOR
The terminator is graphically represented as a rectangle! as shown in "igure H.
Terminators represent e(ternal entities with which the system communicates. A
terminator is a person or a group of persons that are outside the control of the system
being modeled. A terminator can also be another computer system with which your
system will communicate.
In these systems a processor with nothing else to do sleeps until it gets a
message from another tas- on another processor. 'hen the message is e(changed the
two parallel components synchroni.e. In the ,EAforth implementation processors sleep
waiting for program or data messages to arrive and when sleeping consume very
The ,EAforth processors are implemented with asynchronous circuit design.
This means that there is no master logic cloc- being distributed to circuits and used to
gate all internal operations. This is done to reduce e(ecution overhead! cost! power
consumption and generated noise. +aving huge cloc- circuits with antenna running all
over chips produces a large amount of power consumption and noise on and off chip.
::
THE USE OF DATA"FLOW DIAGRAMS IN PARALLEL
FORTHLET CODE
The compiling program passes arguments for the input data port and output data
port and in this case for a loop counter. The parameters are passed by the compiling
program by setting the values I1! O3T! and 1.
#ata$flow diagrams represent classes of parallel ob5ects. A two$dimensional
array distribute! compute! and gather results diagram is not affected by the compute
section. A two$dimensional array distribute and gather class ob5ect can be constructed
using one$dimensional array distribute and gather class ob5ect. A one$dimensional array
of 1P% data elements can be distributed to a linear group of nodes by loading 1P%
data elements at one end of the line and using % elements on each of 1 nodes for a
computation! and gathering results bac-. One case of this class collects a single element
as the result of 1 nodes computations on % elements each.


:<
8.8 E"R DIAGRAM
=acancy
,alary
ogin
+ash
Content
+ash
Employer
Applicant
Fender
1ame
*assword
,alary
Education
*asswor
d
name
3ser name
Applican
t
Employer
s
*assword
:A
ENTITY RELATIONSHIP DIAGRAM FOR ELECTRONIC
RESOURCE MANAGEMENT
This document is an entity$relationship diagram! or /E)#!0 for a system to
manage electronic resources. An E)# is a model that identifies the concepts or entities
that e(ist in a system and the relationships between those entities. An E)# is often
used as a way to visuali.e a relational database9 each entity represents a database table!
and the relationship lines represent the -eys in one table that point to specific records in
related tables. E)#s may also be more abstract! not necessarily capturing every table
needed within a database! but serving to diagram the ma5or concepts and relationships.
This E)# is of the latter type! intended to present an abstract! theoretical view of the
ma5or entities and relationships needed for management of electronic resources. It may
assist the database design process for an e$resource management system! but does not
identify every table that would be necessary for an electronic resource management
database.
This E)# should be e(amined in close consultation with other components of
the )eport of the #" Electronic )esource %anagement Initiative! especially Appendi(
E >#ata Element #ictionary? and Appendi( " >#ata ,tructure?. The E)# presents a
visual representation of e$resource management concepts and the relationships between
them. The #ata Element #ictionary identifies and defines the individual data elements
that an e$resource management system must contain and manage! but leaves the
relationship between the elements to be inferred by the reader. The #ata ,tructure
associates each data element with the entities and relationships defined in the E)#.
Together! these three documents form a complete conceptual data model for e$resource
management.
UNDERSTANDING THE MODEL
There are several different modeling systems for entity relationship
diagramming. This E)# is presented in the /Information Engineering0 style. Those
unfamiliar with entity relationship diagramming or unfamiliar with this style of notation
may wish to consult the following section to clarify the diagramming symbology.
:B
ENTITIES
Entities are concepts within the data model. Each entity is represented by a bo(
within the E)#. Entities are abstract concepts! each representing one or more instances
of the concept in question. An entity might be considered a container that holds all of
the instances of a particular thing in a system. Entities are equivalent to database tables
in a relational database! with each row of the table representing an instance of that
entity.
)emember that each entity represents a container for instances of the thing in
question. The diagram below has an entity for /student0 and another for /school.0 This
indicates
EXCLUSIVE"OR RELATIONSHIP
If an entity instance may have either one relationship or another! but not both!
the constraint may be modeled with an e(clusive$or relationship! represented as a tree
with a solid dot where the tree branches
E"RESOURCE RECURSIVE RELATIONSHIP
The e$resource entity represents e$resource pac-ages! pac-ages of pac-ages! and
individual e$resource titles. Any given e$resource title may be a standalone product! or
may be a part of an e$resource pac-age. An e$resource pac-age could in turn be part of
a larger pac-age
:H
8.; DATABASE DESIGN
8.;.1 TABLE 1< LOGIN
FIELD DATA TYPE FIELD SI=E DISCRIPTION
ogin =archar
<A ogin
*assword =archar <A *assword
8.;.2 TABLE 2< APPLICANT DETAILS
FIELD DATA TYPE FIELD SI=E DISCRIPTION
1ame =archar <A Applicant 1ame
Age =archar <A Applicant Age
,e( =archar <A ,e(
Education =archar <A Applicant Education
E(tra =archar <A Applicant E(tra
7ualification
,alary =archar <A Applicant ,alary
"ield =archar <A "ield
ogin =archar <A ogin
*wd =archar <A Applicant *assword
:C
8.;.3 TABLE 3< COMPANY DETAILS
FIELD DATA TYPE FIELD SI=E DISCRIPTION
1ame =archar <A Company 1ame
=acancy =archar
<A =acancies
,alary =archar <A ,alary #etails
"ield =archar
<A "ield
ogin =archar <A ogin
*wd =archar
<A Company *assword

:J
8.> INPUT DESIGN
Input design is the process of converting user$oriented input to computer$based
format. The goal of input data design is to ma-e data entry as easy! logical and free from
errors as possible. Inputs are raw data that are acceptable by the system and processed it
to produce the output. It also includes determining media! method of input! speed of
capture and entry into the system. Errors entered are controlled by the input design.
"our ob5ectives guiding the design of input focus on9
Controlling the amount of input required
Avoid delay
Controlling errors
Deeping the steps simple
%ain screen is designed with %enu bar! Tool bo(! *roperty window! #esign
frame and Code window. The s-eleton structure of the form design required by the user
is given as the input. Components can be added to the design frame from the Toolbo(
window and the user required form design can be designed.
8.? OUTPUT DESIGN
The output design was done so that results of processing could be communicated
to the users. The various outputs have been designed in such a way that they represent
the same format that the office and management used to.
Computer output is the most important and direct source of information to the
user. Efficient! intelligible output design should improve the systems relationships with
the user and help in decision ma-ing. A ma5or form of output is hardcopy from the
printer.
<E
CHAPTER ;
SYSTEM TESTING
The purpose of testing is to discover errors. Testing is the process of trying to
discover every conceivable fault or wea-ness in a wor- product. It provides a way to
chec- the functionality of components! sub assemblies! assemblies and@or a finished
product. It is the process of e(ercising software with the intent of ensuring that the
,oftware system meets its requirements and user e(pectations and does not fail in an
unacceptable manner. There are various types of test. Each test type addresses a specific
testing requirement.
The testing of a conventional software system involves some of the following
phases. They are
3nit Testing
Acceptance Testing
Test Cases
TESTING OBJECTIVES
Testing ob5ectives are7
Testing is a process of e(ecuting a program with the intent of finding an error.
A good test has a high probability of finding an as yet undiscovered error.
A successful test is one that uncovers an as yet undiscovered error.
The ob5ective is to design tests that systematically uncover different classes of
errors and do so with a minimum amount of time and effort. Testing
cannotshow the absence of defects! it can only show that software defects are
present.
<4
;.1 UNIT TESTING
ccA software module can be created by building up of many small parts
into a single module. This small part is called as a unit. A unit is a piece of code that will
perform a specific tas-. At the end of this testing all units will be tested so that we can
get the correct result. By using unit testing we can easily identify the errors.
1umber of input parameters should be equal to number of arguments
*arameter and argument attributes must match
*arameters passed should be in correct order
Flobal variable definitions consistent across modules.
;.2 ACCEPTANCE TESTING
3ser acceptance of the system is a -ey factor for the success of any system. The
system under the consideration is tested for user acceptance by constantly -eeping touch
with prospective system and user at the time of developing and ma-ing changes
whenever required. This is done regarding to the following points.
Input ,creen design
Output screen design
"ormat of the report and other user
;.3 INTEGRATION TESTING
TOP DOWN INTEGRATION
%odules integrated by moving down the program design hierarchy. Can
use depth first or breadth first top down integration
=erifies ma5or control and decision points early in design process. Top$
level structure tested most. #epth first implementation allows a complete function to be
implemented! tested and demonstrated. Can do depth first implementation of critical
<8
functions early. Top down integration forced >to some e(tent? by some development
tools in programs with graphical user interfaces.
VALIDATION TESTING
=alidation testing is aims to demonstrate that the software functions in a
manner that can be reasonably e(pected by the customer. This tests conformance the
software to the ,oftware )equirements ,pecification.
SYSTEM TESTING
,oftware is only one component of a system. ,oftware will be
incorporated with other system components and system integration and validation test
performance
;.4 TEST CASES
TEST"DRIVEN DEVELOPMENT
Test$driven development >T##? is a software development technique that relies
on the repetition of a very short development cycle9 first the developer writes a failing
automated test case that defines a desired improvement or new function! then produces
code to pass that test and finally refactors the new code to acceptable standards.
Test$driven development is related to the test$first programming concepts of
e(treme programming! begun in 4JJJ! but more recently has created more general
interest in its own right.
*rogrammers also apply the concept to improving and debugging legacy code
developed with older techniques.

ADD A TEST
In test$driven development! each new feature begins with writing a test. This
test must inevitably fail because it is written before the feature has been implemented.
>If it does not fail! then the proposed /new0 feature is obviated.? To write a test! the
<:
developer must clearly understand the featureKs specification and requirements. The
developer can accomplish this through use cases and user stories that cover the
requirements and e(ception conditions. This could also imply a variant! or modification
of an e(isting test. This is a differentiating feature of test$driven development versus
writing unit tests after the code is written9 it ma-es the developer focus on the
requirements before writing the code! a subtle but important difference.
RUN ALL TESTS AND SEE IF THE NEW ONE FAILS
This validates that the test harness is wor-ing correctly and that the new test
does not mista-enly pass without requiring any new code. This step also tests the test
itself! in the negative9 it rules out the possibility that the new test will always pass! and
therefore be worthless.
The new test should also fail for the e(pected reason. This increases confidence
>although it does not entirely guarantee? that it is testing the right thing! and will pass
only in intended cases.
WRITE SOME CODE
The ne(t step is to write some code that will cause the test to pass. The new code
written at this stage will not be perfect and may! for e(ample! pass the test in an
inelegant way. That is acceptable because later steps will improve and hone it.
It is important that the code written is only designed to pass the testI no further
>and therefore untested? functionality should be predicted and Kallowed forK at any stage.
RUN THE AUTOMATED TESTS AND SEE THEM SUCCEED
If all test cases now pass! the programmer can be confident that the code meets
all the tested requirements. This is a good point from which to begin the final step of the
cycle.
REFACTOR CODE
<<
1ow the code can be cleaned up as necessary. By re$running the test cases! the
developer can be confident that refactoring is not damaging any e(isting functionality.
The concept of removing duplication is an important aspect of any software design. In
this case! however! it also applies to removing any duplication between the test code and
the production code.
REPEAT
,tarting with another new test! the cycle is then repeated to push forward the
functionality. The si.e of the steps should always be small! with as few as 4 to 4E edits
between each test run. If new code does not rapidly satisfy a new test! or other tests fail
une(pectedly! the programmer should undo or revert in preference to e(cessive
debugging. Continuous Integration helps by providing revertible chec-points. 'hen
using e(ternal libraries it is important not to ma-e increments that are so small as to be
effectively merely testing the library itself! unless there is some reason to believe that
the library is buggy or is not sufficiently feature$complete to serve all the needs of the
main program being written.
DEVELOPMENT STYLE
There are various aspects to using test$driven development! for e(ample the
principles of L-eep it simple! stupidL >DI,,? and L;ou ainKt gonna need itL >;AF1I?. By
focusing on writing only the code necessary to pass tests! designs can be cleaner and
clearer than is often achieved by other methods. In Test$#riven #evelopment by
E(ample Dent Bec- also suggests the principle L"a-e it! till you ma-e itL.
To achieve some advanced design concept >such as a design pattern?! tests are
written that will generate that design. The code may remain simpler than the target
pattern! but still pass all required tests. This can be unsettling at first but it allows the
developer to focus only on what is important.
'rite the tests first. The tests should be written before the functionality that is
being tested. This has been claimed to have two benefits. It helps ensure that the
application is written for testability! as the developers must consider how to test the
application from the outset! rather than worrying about it later. It also ensures that tests
<A
for every feature will be written. 'hen writing feature$first code! there is a tendency by
developers and the development organisations to push the developer onto the ne(t
feature! neglecting testing entirely.
"irst fail the test cases. The idea is to ensure that the test really wor-s and can
catch an error. Once this is shown! the underlying functionality can be implemented.
This has been coined the Ltest$driven development mantraL! -nown as red@green@refactor
where red means fail and green is pass.
Test$driven development constantly repeats the steps of adding test cases that
fail! passing them! and refactoring. )eceiving the e(pected test results at each stage
reinforces the programmerKs mental model of the code! boosts confidence and increases
productivity.
BENEFITS
A 8EEA study found that using T## meant writing more tests and! in turn!
programmers that wrote more tests tended to be more productive. +ypotheses relating to
code quality and a more direct correlation between T## and productivity were
inconclusive.
*rogrammers using pure T## on new >LgreenfieldL? pro5ects report they only
rarely feel the need to invo-e a debugger. 3sed in con5unction with a version control
system! when tests fail une(pectedly! reverting the code to the last version that passed
all tests may often be more productive than debugging.
Test$driven development offers more than 5ust simple validation of correctness!
but can also drive the design of a program. By focusing on the test cases first! one must
imagine how the functionality will be used by clients >in the first case! the test cases?.
,o! the programmer is concerned with the interface before the implementation. This
benefit is complementary to #esign by Contract as it approaches code through test cases
rather than through mathematical assertions or preconceptions.
Test$driven development offers is the ability to ta-e small steps when required. It
allows a programmer to focus on the tas- at hand as the first goal is to ma-e the test
<B
pass. E(ceptional cases and error handling are not considered initially! and tests to
create these e(traneous circumstances are implemented separately. Test$driven
development ensures in this way that all written code is covered by at least one test.
This gives the programming team! and subsequent users! a greater level of confidence in
the code.
'hile it is true that more code is required with T## than without T## because
of the unit test code! total code implementation time is typically shorter. arge numbers
of tests help to limit the number of defects in the code. The early and frequent nature of
the testing helps to catch defects early in the development cycle! preventing them from
becoming endemic and e(pensive problems.
T## can lead to more modulari.ed! fle(ible! and e(tensible code. This effect
often comes about because the methodology requires that the developers thin- of the
software in terms of small units that can be written and tested independently and
integrated together later. This leads to smaller! more focused classes! looser coupling!
and cleaner interfaces. The use of the moc- ob5ect design pattern also contributes to the
overall modulari.ation of the code because this pattern requires that the code be written
so that modules can be switched easily between moc- versions for unit testing and
LrealL versions for deployment.
Because no more code is written than necessary to pass a failing test case!
automated tests tend to cover every code path. "or e(ample! in order for a T##
developer to add an $*2$ branch to an e(isting %/ statement! the developer would first
have to write a failing test case that motivates the branch. As a result! the automated
tests resulting from T## tend to be very thorough9 they will detect any une(pected
changes in the codeKs behavior. This detects problems that can arise where a change later
in the development cycle une(pectedly alters other functionality.
VULNERABILITIES
Test$driven development is difficult to use in situations where full functional
tests are required to determine success or failure. E(amples of these are user interfaces!
programs that wor- with databases! and some that depend on specific networ-
configurations. T## encourages developers to put the minimum amount of code into
<H
such modules and to ma(imi.e the logic that is in testable library code! using fa-es and
moc-s to represent the outside world.
%anagement support is essential. 'ithout the entire organi.ation believing that
test$driven development is going to improve the product! management will feel that
time spent writing tests is wasted.
The tests themselves become part of the maintenance overhead of a pro5ect. Badly
written tests! for e(ample ones that include hard$coded error strings or which are
themselves prone to failure! are e(pensive to maintain. There is a ris- that tests that
regularly generate false failures will be ignored! so that when a real failure occurs it may
not be detected.
The level of coverage and testing detail achieved during repeated T## cycles
cannot easily be re$created at a later date. Therefore these original tests become
increasingly precious as time goes by. If a poor architecture! a poor design or a poor
testing strategy leads to a late change that ma-es do.ens of e(isting tests fail! it is
important that they are individually fi(ed. %erely deleting! disabling or rashly altering
them can lead to un$detectable holes in the test coverage.
3ne(pected gaps in test coverage may e(ist or occur for a number of reasons. *erhaps
one or more developers in a team was not so committed to the T## strategy and did not
write tests properly! perhaps some sets of tests have been invalidated! deleted or
disabled accidentally or on purpose during later wor-. If this happens! the confidence
that a large set of T## tests lend to further fi(es and refactorings will actually be
misplaced. Alterations may be made that result in no test failures when in fact bugs are
being introduced and remaining undetected.
3nit tests created in a test$driven development environment are typically created by the
developer who will also write the code that is being tested. The tests may therefore
share the same blind spots with the code9 If! for e(ample! a developer does not reali.e
that certain input parameters must be chec-ed! most li-ely neither the test nor the code
will verify these input parameters. If the developer misinterprets the requirements
specification for the module being developed! both the tests and the code will be wrong.
The high number of passing unit tests may bring a false sense of security! resulting in
less additional 7A activities! such as integration testing and compliance testing.
<C
CODE VISIBILITY
Test$suite code clearly has to be able to access the code it is testing. On the other
hand normal design criteria such as information hiding! encapsulation and the
separation of concerns should not be compromised. Therefore unit test code for T## is
usually written within the same pro5ect or module as the code being tested.
In ob5ect oriented design this still does not provide access to private data and
methods. Therefore! e(tra wor- may be necessary for unit tests. In 6ava and other
languages! a developer can use reflection to access fields that are mar-ed private.
Alternatively! an inner class can be used to hold the unit tests so they will have visibility
of the enclosing classKs members and attributes. In the .1ET "ramewor- and some other
programming languages! partial classes may be used to e(pose private methods and data
for the tests to access.
It is important that such testing hac-s do not remain in the production code. In
CQ and other languages! compiler directives such as #if DEBUG ... #endif can be
placed around such additional classes and indeed all other test$related code to prevent
them being compiled into the released code. This then means that the released code is
not e(actly the same as that which is unit tested. The regular running of fewer but more
comprehensive! end$to$end! integration tests on the final release build can then ensure
>among other things? that no production code e(ists that subtly relies on aspects of the
test harness.
There is some debate among practitioners of T##! documented in their blogs
and other writings! as to whether it is wise to test private and protected methods and
data anyway. ,ome argue that it should be sufficient to test any class through its public
interface as the private members are a mere implementation detail that may change! and
should be allowed to do so without brea-ing numbers of tests.
<J
CHAPTER >
SYSTEM IMPLEMENTATION
This pro5ect needs a 5ava development -it 5d-4.A.Eand above?. *ro5ect is
implemented in 5ava! so it can be run in any O,. "or maintaining data within an
organi.ation
After the system had been tested! the implementation type or the change over
technique from the e(isting system to the new system is a step$step process. In the
system! at first only a module of the system is implemented and chec-ed for suitability
and efficiency. 'hen the end$user to the particular module is satisfied with the
performance! the ne(t step of implementation is preceded.
Implementation to some e(tend is also parallel. "or instance! modules! which are
not lin-ed! with other modules are implemented parallel and the remaining is the step$
by$step process. Bac-ups are necessary since any time une(pected events may happen.
And so during the program e(ecution! the records are stored in the wor- space. This
helps to recover the original status of the records from any accidental updating or
intentional deletion of records.
Implementation is the stage of the pro5ect when the theoretical design is turned
out into a wor-ing system. Thus it can be considered to be the most critical stage in
achieving a successful new system and in giving the user! confidence that the new
system will wor- and be effective.
The implementation stage involves careful planning! investigation of the e(isting
system and it2s constraints on implementation! designing of methods to achieve
changeover and evaluation of changeover methods. Implementation is the process of
managing and maintaining the placement details which includes applicant! employer!
and reports modification and retrieval of details. The modification phase contains some
#% operations li-e inserting! deleting and updating the information and maintain in
the database.
AE
CHAPTER ?
CONCLUSION @ FUTURE ENHANCEMENTS
?.1 CONCLUSION
This pro5ect provides a F3I! a user friendly system! where secret information
can be protected with password settings. It attains all 5ava futures. It is platform
independent so that it can be used in any O,.
The ob5ective of this paper was to managing the te(tiles! which is based on a
property of the systematic data maintenance. The most important point for this pro5ect is
that the people who are not involving in the pro5ect can not see any information.
?.2 FUTURE ENHANCEMENTS
This phase is mainly used in demonstrates the methods that are used in
maintaining the proposed system. It should be -ept in mind that the developed system
should be easy to maintain there by giving the user some conditions that they maintain
the system to serve.
After computeri.ed it is very easy to maintain the above difficulties it is very
helpful to the according to maintain the process in effective manner.
,cope of the future enhancement is the pro5ect implemented on any
organi.ation. Then to search the information is return at the same time. The pro5ect can
be outsourcing to any technology.
A4
CHAPTER A
APPENDICES
APPENDIX 1
A.1 SOURCE CODE
L0-%,<
import 5ava(.swing.PI
import 5ava.awt.PI
import 5ava.awt.event.PI
import 5ava.sql.PI
public class login e(tends 6"rame implements ActionistenerR
6*anel butpanSnew 6*anel>?I
6*anel logpanSnew 6*anel>?I
6*anel selpanSnew 6*anel>?I
6abel unSnew 6abel>Login$I#L?I
6Te(t"ield usrSnew 6Te(t"ield>4E?I
6abel pdSnew 6abel>L*asswordL?I
6*assword"ield pwdSnew 6*assword"ield>4E?I
6Button resetSnew 6Button>L)esetL?I
6Button logSnew 6Button>LoginL?I
A8
6Button 5oinSnew 6Button>L6oinL?I
6)adioButton appSnew 6)adioButton>LApplicantsL?I
6)adioButton empSnew 6)adioButton>LEmployersL?I
ButtonFroup bgSnew ButtonFroup>?I
Connection clogI
,tatement stI
int flagSEI
int iSEI
public static void main>,tring argsTU?R
new login>?I
V
public login>?R
getContent*ane>?.add>butpan!Borderayout.,O3T+?I
getContent*ane>?.add>logpan!Borderayout.'E,T?I
getContent*ane>?.add>selpan!Borderayout.EA,T?I
logpan.add>un?I
logpan.add>usr?I
logpan.add>pd?I
logpan.add>pwd?I
butpan.add>reset?I
A:
butpan.add>log?I
butpan.add>5oin?I
selpan.add>app?I
selpan.add>emp?I
bg.add>app?I
bg.add>emp?I
set=isible>true?I
set,i.e><EE!<EE?I
set#efaultCloseOperation>EGITWO1WCO,E?I
pac->?I
reset.addActionistener>this?I
log.addActionistener>this?I
5oin.addActionistener>this?I
V
public void action*erformed>ActionEvent ae?R
Ob5ect sourceSae.get,ource>?I
if>sourceSSreset?R
usr.setTe(t>LL?I
pwd.setTe(t>LL?I
V
A<
else if>sourceSS5oin?R
if>app.is,elected>?? R new app>?I set=isible>false?IV
else if>emp.is,elected>?? R new emp>?I set=isible>false?IV
V
else if>sourceSSlog?R
@Pog in of Applicants start from hereP@
if>app.is,elected>??R
tryR
Class.for1ame>Lcom.mysql.5dbc.#riverL?I
clogS#river%anager.getConnection>L5dbc9mysql9@@localhost@placementL!Lroot
L!LrootL?I
stSclog.create,tatement>?I
)esult,et rsog4Sst.e(ecute7uery>Lselect P from ApplicantL?I
while>rsog4.ne(t>??R
boolean b4Srsog4.get,tring>C?.equals>>,tring?usr.getTe(t>??I
boolean b8Srsog4.get,tring>J?.equals>>,tring?pwd.getTe(t>??I
if> b4 XX b8 ?R
6Option*ane.show%essage#ialog>null!LdoneL?I @@)emove this line
new empdetail>rsog4.getInt>H??I
AA
flagS4I
brea-I
V
V
if>flagYS4 XX iZS:?R
MMiI
6Option*ane.show%essage#ialog>null!LInvalid EntryL?I
V
else if>flagYS4 XX i[:?R
,ystem.e(it>E?I
V
else if>flagSS4?R
set=isible>false?I
V
V
catch>E(ception e(cp?R
6Option*ane.show%essage#ialog>null!e(cp?I
,ystem.e(it>E?I
V
V
AB
@Plog in of Employers ,tart from hereP@
else if>emp.is,elected>??R
tryR
Class.for1ame>Lcom.mysql.5dbc.#riverL?I
clogS#river%anager.getConnection>L5dbc9mysql9@@localhost@placementL!
L rootL! rootL?IL
stSclog.create,tatement>?I
)esult,et rsog8Sst.e(ecute7uery>Lselect P from CompanyL?I
while>rsog8.ne(t>??R
boolean b4Srsog8.get,tring>A?.equals>>,tring?usr.getTe(t>??I
boolean b8Srsog8.get,tring>B?.equals>>,tring?pwd.getTe(t>??I
if> b4 XX b8 ?R
6Option*ane.show%essage#ialog>null!LdoneL?I@@)emove this line
new appdetail>rsog8.getInt><??I
flagS4I
brea-I
V
V
if>flagYS4 XX iZS:?R
MMiI
AH
6Option*ane.show%essage#ialog>null!LInvalid EntryL?I
V
else if>flagYS4 XX i[:?R
,ystem.e(it>E?I
V
else if>flagSS4?R
set=isible>false?I
V
V
catch>E(ception e(cp?R
6Option*ane.show%essage#ialog>null!e(cp?I
,ystem.e(it>E?IV
V
V
V
V
A33*%+),'9
import 5ava(.swing.PI
import 5ava.awt.PI
import 5ava.awt.event.PI
AC
import 5ava.sql.PI
public class appdetail e(tends 6"rameR
public static void main>,tring argsTU?R
new appdetail>E?I
V
6Table tabI
6*anel tpanSnew 6*anel>?I
6*anel bpanSnew 6*anel>?I
,tringheaderTUSRL1ameL!LAgeL!L,e(L!LEducationL!LCo$
curricularsL!L,alaryLVI
Ob5ect dataTUTUSnew ,tringT4AUTBUI
6Button chec-Snew 6Button>LT);L?I
int i!5!-iI
public appdetail>int -?R
this.-iS-I
set=isible>true?I
set,i.e>CEE!BEE?I
set#efaultCloseOperation>EGITWO1WCO,E?I
AJ
getContent*ane>?.add>tpan!Borderayout.CE1TE)?I
getContent*ane>?.add>bpan!Borderayout.,O3T+?I
bpan.add>chec-?I
tryR
Class.for1ame>Lcom.mysql.5dbc.#riverL?I
ConnectionconnS#river%anager.getConnection>L5dbc9mysql9@@localhost@
placementL!LrootL!LrootL?I
,tatement stSconn.create,tatement>?I
)esult,et rsSst.e(ecute7uery>Lselect P from Applicant where "ieldSLM-i?I
while>rs.ne(t>??R
for>5SEI5ZSAI5MM?
dataTiUT5USrs.get,tring>5M4?I
iMMI
V
V
catch>E(ception e?
R
6Option*ane.show%essage#ialog>null!dataT4UTEU?I
,ystem.e(it>E?I
V
BE
tabSnew 6Table>data!header?I
tab.set*referred,crollable=iewport,i.e>new #imension>BEE!BEE??I
6,croll*ane spSnew 6,croll*ane>tab?I
tpan.add>sp?I
pac->?I
V
V
E13*06$&29
import 5ava(.swing.PI
import 5ava.awt.PI
import 5ava.awt.event.PI
import 5ava.sql.PI
public class empdetail e(tends 6"rameR
public static void main>,tring argsTU?R
new empdetail>E?I
V
6Table tabI
6*anel tpanSnew 6*anel>?I
6*anel bpanSnew 6*anel>?I
,tring headerTUSRL1ameL!L=acancyL!L,alaryLVI
B4
Ob5ect dataTUTUSnew ,tringT4AUT:UI
6Button chec-Snew 6Button>LT);L?I
int i!5!-iI
public empdetail>int -?R
this.-iS-I
set=isible>true?I
set,i.e>BEE!BEE?I
set#efaultCloseOperation>EGITWO1WCO,E?I
getContent*ane>?.add>tpan!Borderayout.CE1TE)?I
getContent*ane>?.add>bpan!Borderayout.,O3T+?I
bpan.add>chec-?I
tryR
Class.for1ame>Lcom.mysql.5dbc.#riverL?I
Connection
connS#river%anager.getConnection>L5dbc9mysql9@@localhost@placementL!LrootL!
LrootL?I
,tatement stSconn.create,tatement>?I
)esult,et rsSst.e(ecute7uery>Lselect P from Company where "ieldSLM-i?I
while>rs.ne(t>??R
for>5SEI5ZS8I5MM?
B8
dataTiUT5USrs.get,tring>5M4?I
iMMI
V
V
catch>E(ception e?R
6Option*ane.show%essage#ialog>null!dataT4UTEU?I
,ystem.e(it>E?I
V
tabSnew 6Table>data!header?I
tab.set*referred,crollable=iewport,i.e>new #imension>BEE!BEE??I
6,croll*ane spSnew 6,croll*ane>tab?I
tpan.add>sp?I
pac->?IVV
B:
APPENDIX 2
A.2 SCREEN SHOTS
LOGIN FORM

APPLICANT FORM
B<
BA
EMPLOYER FORM
BB
A.2.1 EMPLOYER TABLE
BH
A.2.2 APPLICANT TABLE
BC
CHAPTER 1B
REFERENCES
4. #avid X #eitel>4JJJ?! 6ava +ow to program Introducing ,wing!*rentice +all.
8. )oger ,.*erssman!,oftware Engg A *ractitioner2s Approach "ifth Edition$
%cFraww +ill International Edition!,oftware Engineering ,eries.
:. The Complete )eference 6,*8.E!Tata %cFraw$+ill publishing Company imited!
*hil +anna
<. +all! Ernest .! Computer Image *rocessing and )ecognition! Academic *ress!1ew
;or-! 4JHJ.
A. 6ain! Anil D.! "undamentals of #igital Image *rocessing! *rentice +all! Englewood
Cliffs! 16! 4JCJ.
B. Dawaguchi! E.! Endo! T. and %atsunaga! 6.! /#epth$first picture e(pression viewed
from digital picture processing0!
H. IEEE Trans. on *A%I! vol.A! no.<! pp.:H:$:C<! 4JCC.
C. Dawaguchi! E. and Taniguchi! ).! /Comple(ity of binary pictures and image
hresholding $ An application of #"E(pression to the thresholding problem0!
*roceedings of Cth IC*)! vol.8! pp.4884$488A! 4JCB.
W$5 S%'$2
http9@@www.5avaranch.com
http9@@forum.5ava.sun.com
http9@@5ava.sun.com
BJ