Criminal Face Identification System

INDEX

1. Abstract 2. Introduction 3. System Analysis a. Existing System b. proposed System 4. Feasibility Report a. Tec nical Feasibility b. !perational Feasibility c. Economical Feasibility ". System Re#uirement Speci$ication %ocument a. &odules %escription b. 'rocess Flo( c. S%)* &et odology d. So$t(are Re#uirements e. +ard(are Re#uirements ,. System %esign

A.E-R %iagram b. %F% c. .&) /. Tec nology %escription 0. *oding 1. Testing 2 %ebugging Tec ni#ues 13. !utput Screens 11. Future En ancements 12. 4ibliograp y

ABSTRACT: Title: Criminal Face Identification System

Objective:
*riminal record generally contains personal in$ormation about particular person along (it p otograp . To identi$y any *riminal (e need some identi$ication are gi6en by eye(itness. In most cases t e #uality and ard to identi$y a $ace. To

regarding person5 ( ic

resolution o$ t e recorded image segments is poor and

o6ercome t is sort o$ problem (e are de6eloping so$t(are. Identi$ication can be done in many (ays li7e $inger print5 eyes5 %8A etc. !ne o$ t e applications is $ace identi$ication. T e $ace is our primary $ocus o$ attention in social inters course playing a ma9or role in con6eying identi$y and emotion. Alt oug intelligence or c aracter $rom $acial appearance is suspect5 t e recogni:e $ace is remar7able. t e ability to in$er uman ability to

INTRODUCTION

PURPOSE OF T E PRO!ECT: T is pro9ect is aimed to identi$y t e criminals in any in6estigation department. +ere t e tec ni#ue is (e already store some images o$ t e criminals in our database along (it eyes5 is details and t at images are segmented into many slices say

airs5 lips5 nose5 etc. T ese images are again stored in anot er database

record so to identi$y any criminals; eye(itnesses (ill see t e images or slices t at appear on t e screen by using it (e de6elop t e $ace5 ( ic matc ed (it may or may not be

our images. I$ any image is matc ed up to 11< t en (e predict t at

e is only t e criminal. T us using t is pro9ect it pro6ides a 6ery $riendly en6ironment $or bot criminals 6ery easy. PRO!ECT OB!ECTI"E: T is pro9ect is intended to identi$y a person using t e images pre6iously ta7en. T e identi$ication (ill be done according t e pre6ious images o$ di$$erent persons. PRO!ECT SCOPE: T e scope o$ t e pro9ect is con$ined to store t e image and store in t e database. = en a person as to be identi$ied t e images stored in t e database are operator and eye(itness to easily design any $ace can identi$y

compared (it t e existing details. O"ER"IE# OF T E PRO!ECT: T is pro9ect is aimed to identi$y t e criminals in any in6estigation department. +ere t e tec ni#ue is (e already store some images o$

t e criminals in our database along (it segmented into many slices say eyes5

is details and t ose images are

airs5 lips5 nose5 etc. T ese images are again

stored in anot er database record so to identi$y any criminals; eye(itnesses (ill see t e images or slices t at appear on t e screen by using it (e de6elop t e $ace5 ( ic may or may not be matc ed (it our images. I$ any image is matc ed up to

11< t en (e predict t at

e is only t e criminal. T us using t is pro9ect it pro6ides operator and eye(itness to easily design any

a 6ery $riendly en6ironment $or bot $ace can identi$y criminals 6ery easy.

PROB$E% AREA DESCRIPTION

T e pro9ect is aimed at identi$ying t e criminals (it t e elp o$

eye (itness. T ere are mainly $our modules in our pro9ect. T ey are Adding5 %eleting5 .pdating and identi$ying t e criminals. T ere are mainly t ree roles in our pro9ect. T ey are> Administrator !perator Eye(itness T e administrator is responsible $or pro6iding .ser id?s and pass(ords. +e pro6ides aut entication to t e users. +e creates deletes and .pdates t e .ser ids and 'ass(ords. T e operator5 ( o belongs to t e in6estigating department5 is responsible $or entering t e criminal details and maintains t em. +e adds5 deletes and updates t e criminal details. +e also constructs t e criminal $ace (it o$ eye (itness. t e elp

T e eye(itness identi$ies t e criminals (it

t e

elp o$

cropped parts stored in a di$$erent database by t e operator. T e eye(itness selects a cropped part $rom t e database and t at cropped part (ill be $ree:e by t e operator in t is (ay5 complete $ace o$ t e criminal is constructed and t e details o$ t at criminal is retrie6ed $rom t e database. =e can also construct a ne( image $rom t ose cropped parts ( ic (e consider as an imaginary $ace o$ t e criminal.

S&STE% ANA$&SIS

T e $irst step in de6eloping anyt ing is to state t e re#uirements. T is applies 9ust as muc to leading edge researc as to simple programs and to

personal programs5 as (ell as to large team e$$orts. 4eing 6ague about your ob9ecti6e only postpones decisions to a later stage ( ere c anges are muc more costly. T e problem statement s ould state ( at is to be done and not o( it

is to be done. It s ould be a statement o$ needs5 not a proposal $or a solution. A user manual $or t e desired system is a good problem statement. T e re#uestor s ould indicate ( ic $eatures are mandatory and ( ic are

optional5 to a6oid o6erly constraining design decisions. T e re#uestor s ould a6oid describing system internals5 as t is restricts implementation $lexibility. 'er$ormance speci$ications and protocols $or interaction (it external

systems are legitimate re#uirements. So$t(are engineering standards5 suc as modular construction5 design $or testability5 and pro6ision $or $uture extensions5 are also proper. &any problems statements5 $rom indi6iduals5 companies5 and

go6ernment agencies5 mixture re#uirements (it

design decisions. T ere

may sometimes be a compelling reason to re#uire a particular computer or language; t ere is rarely 9usti$ication to speci$y t e use o$ a particular algorit m. T e analyst must separate t e true re#uirements $rom design and implementation decisions disguised as re#uirements. T e analyst s ould

c allenge suc

pseudo re#uirements5 as t ey restrict $lexibility. T ere may

be politics or organi:ational reasons $or t e pseure#uirements5 but at least t e analyst s ould recogni:e t at t ese externally imposed design decisions are not essential $eatures o$ t e problem domain. A problem statement may a con6entional product5 suc a6e more or less detail. A re#uirement $or

as a payroll program or a billing system5 may e$$ort in a ne( area as some ob9ecti6e5

a6e considerable detail. A re#uirement $or a researc may lac7 many details5 but presumably t e researc ( ic s ould be clearly stated. &ost alt oug problem statements are ambiguous5

incomplete5

or

e6en

inconsistent. Some re#uirements are 9ust plain (rong. Some re#uirements5 precisely stated5 a6e unpleasant conse#uences on t e system be a6ior or impose unreasonable implementation costs. Some re#uirements seem reasonable at $irst but do not (or7 out as (ell as t e re#uest or t oug t. T e problem statement is 9ust a starting point $or understanding t e problem5 not an immutable document. T e purpose o$ t e subse#uent analysis is to $ully understand t e problem and its implications. T ere is no reasons to expect t at a problem statement prepared (it out a $ully analysis (ill be correct. T e analyst must (or7 (it t e re#uestor to re$ine t e re#uirements so t ey represent t e re#uestor?s true intent. T is in6ol6es c allenging t e re#uirements and probing $or missing in$ormation. T e psyc ological5 organi:ational5 and political considerations o$ doing t is are beyond t e scope o$ t is boo75 except $or t e $ollo(ing piece o$ ad6ice> I$ you do exactly ( at t e customer as7ed $or5 but t e result does not meet t e customer?s real needs5 you (ill probably be blamed any(ay.

E'istin( System: T is system is manual system only. +ere5 a6e a $acility to store t e t e

criminal images. I$ you (ant to compare t e criminal images (it

existing images it is manual process. T is process is 6ery slo( to gi6e t e result. It is 6ery critical to $ind t e criminal images. Pro)osed System:
To o6ercome t e dra(bac7s t at (ere in t e existing system (e de6elop a system t at (ill be 6ery use$ul $or any in6estigation department. +ere t e program 7eeps trac7 o$ t e record number o$ eac identi$iable slice during t e construction o$

uman $ace and calculate maximum number o$ slices o$ t e similar

record number. 4ased on t is record number t e program retrie6es t e personal record o$ t e suspect @( ose slice constituted t e ma9or parts o$ t e constructed uman $aceA on exercising t e BlocateC option.

Ad*anta(es:
Dery $ast and accurate. 8o need o$ any extra manual e$$ort. 8o $e6er o$ data loss. Eust need a little 7no(ledge to operate t e system. %oesn?t re#uire any extra ard(are de6ice. At last 6ery easy to $ind t e criminals

O*er*ie+:

Addition5 *lipping5 *onstruction and updating o$ t e criminal record and $ace. *omparing t e image (it t e $aces t at are t ere in our database. I$ any ne(

images are $ound t en it s ould be entered into our database by add image module and t en it s ould be segmented into di$$erent slices.

FEASIBI$IT& REPORT

Feasi,ility St-dy A $easibility study is a ig -le6el capsule 6ersion o$ t e entire System

analysis and %esign 'rocess. T e study begins by classi$ying t e problem de$inition. Feasibility is to determine i$ it?s (ort problem de$inition doing. !nce an acceptance

as been generated5 t e analyst de6elops a logical model $or alternati6es is analy:ed care$ully. T ere are 3

o$ t e system. A searc parts in $easibility study.

O)erational Feasi,ility:

Fuestion t at going to be as7ed are =ill t e system be used i$ it de6eloped and implemented. I$ t ere (as su$$icient support $or t e pro9ect $rom t e management and $rom t e users. +a6e t e users been in6ol6ed in planning and de6elopment o$ t e 'ro9ect. =ill t e system produce poorer result in any respect or areaG

T is system can be implemented in t e organi:ation because t ere is ade#uate support $rom management and users. 4eing de6eloped in Ea6a so t at t e necessary operations are carried out automatically.
Tec.nical feasi,ility: %oes t e necessary tec nology exist to do ( at is been suggested

%oes t e proposed e#uipment a6e t e tec nical capacity $or using t e ne( systemG

Are t ere tec nical guarantees o$ accuracy5 reliability and data securityG T e pro9ect is de6eloped on 'entium ID (it 2", &4 RA&.

T e en6ironment re#uired in t e de6elopment o$ system is any (indo(s plat$orm

T e obser6er pattern along (it $actory pattern (ill update t e results e6entually

T e language used in t e de6elopment is EADA 1." 2 =indo(s En6ironment

Financial and Economical Feasi,ility: T e system de6eloped and installed (ill be good bene$it to t e organi:ation. T e system (ill be de6eloped and operated in t e existing ard(are and so$t(are in$rastructure. So t ere is no need o$ additional ard(are and so$t(are $or t e system.

S&STE% RE/UIRE%ENT SPECIFICATION

F-nctional Re0-irements: 4y conducting t e re#uirements analysis (e listed out t e re#uirements t at are use$ul to restate t e problem de$inition. Insert t e image into database Split t e image into no o$ parts. &erge t e parts. Identi$y t e image. %ra( image manually. &aintain separate login $or admin and operator. &aintain in$ormation about eac criminal

%od-le Descri)tion =ell structured designs impro6e t e maintainability o$ a system. A structured system is one t at is de6eloped $rom t e top do(n and modular5 t at is5 bro7en do(n into manageable components. In t is pro9ect (e modulari:ed t e system so t at t ey a6e minimal e$$ect on eac ot er. T is application is designed into $i6e independent modules ( ic di$$erent tas7s e$$iciently. 12 User Interface %od-le2 32 Admin %od-le2 42 Client %od-le2 52 Data,ase O)erations %od-le2 62 S)littin( and %er(in( %od-le2 72 Identify %od-le2 ta7e care o$

User Interface %od-le: Actually e6ery application as one user inter$ace $or accessing t e entire

application. In t is application also (e are pro6iding one user inter$ace $or accessing t is application. T e user inter$ace designed completely based on t e end users. It is pro6ide $riendly accessing to t e users. T is user inter$ace as attracti6e loo7 and

$eel. Tec nically I am using t e s(ings in core 9a6a $or preparing t is user inter$ace. Admin %od-le:

User requirements Create

Elaboration Assign new user id & password for an employee. Administrator can delete the user id & password of unwanted employee.

Further Elaboration

Delete

Update

First the details of employees are to be obtained by using user id & password.

After obtaining the original details the updated details are submitted.

Client %od-le: User requirements Login Elaboration Employee log in to home page by entering id & password. Adding details Personal details of criminal store in to data base Update process Enter criminal id and obtain his details Delete process Enter criminal id Update the details and images of e"isting criminal Delete the details and image of unwanted criminal Logout Logout in to the home page S)littin( and %er(in( %od-le: Requirements Elaboration mages are cropped and sa!ed in database. Further Elaboration

Further
Elaboration Compare the clippings with images of criminals

#iew clippings

#iew all clips and select the clip shown by eyewitness

Construction

Construct the face of criminal by clubbing all free$ed clippings

Data,ase O)erations %od-le:

ADD %ODU$E> T e add module is

elp$ul in adding t e details o$ t e criminals

along (it t e details o$ t e criminal p oto. = ile adding t e details o$ t e criminal5 (e crop t e image o$ t e criminal and store t ose cropped parts in a separate database. DE$ETE %ODU$E > T is module deletes t e criminal details along (it t e p oto.

T e operator $irst submits t e criminal id and searc es $or t e a6ailability o$ t e id in t e database. I$ t at id is a6ailable in t e database5 t en t e operator may delete t e record o$ t at particular r criminal. UPDATE %ODU$E > T e operator $irst enters t e criminal id and searc es $or t e a6ailability o$ t at id .I$ t at id is a6ailable in t e database 5 t en t e details o$ t at criminal are retrie6ed and t e operator can update t e details o$ t at criminal and t at updated details o$ t e criminal are stored in t e database again $or $uture retrie6al.

Identify %od-le>
T e cropped parts o$ t e criminals5 along (it t e criminal Id are 6ie(ed by t e eye(itness .T e eye(itness selects particular cropped part o$ t e criminal and it is $ree:e by t e operator.5 t en complete $ace o$ t e criminal is constructed and t e details o$ t e criminal is retrie6ed.

SD$C %ET DO$O8IES

SD$C %ET DO$O8IES: T is document play a 6ital role in t e de6elopment o$ li$e cycle @S%)*A as it describes t e complete re#uirement o$ t e system. It means $or use by de6elopers and (ill be t e basic during testing p ase. Any c anges made to t e re#uirements in t e $uture (ill appro6al process. S'IRA) &!%E) (as de$ined by 4arry 4oe m in is 1100 article5 BA spiral a6e to go t roug $ormal c ange

&odel o$ So$t(are %e6elopment and En ancement. T is model (as not t e $irst model to discuss iterati6e de6elopment5 but it (as t e $irst model to explain ( y t e iteration models. As originally en6isioned5 t e iterations (ere typically , mont s to 2 years long. Eac p ase starts (it a design goal and ends (it a client

re6ie(ing t e progress t us $ar. applied at eac t e pro9ect.

Analysis and engineering e$$orts are an eye to(ard t e end goal o$

p ase o$ t e pro9ect5 (it

T e steps $or Spiral &odel can be generali:ed as $ollo(s> T e ne( system re#uirements are de$ined in as muc possible. details as

T is usually in6ol6es inter6ie(ing a number o$ users

representing all t e external or internal users and ot er aspects o$ t e existing system. A preliminary design is created $or t e ne( system.

A $irst prototype o$ t e ne( system is constructed $rom t e preliminary design. T is is usually a scaled-do(n system5 and

represents an approximation o$ t e c aracteristics o$ t e $inal product. A second prototype is e6ol6ed by a $our$old procedure> 1. E6aluating t e $irst prototype in terms o$ its strengt s5 (ea7ness5 and ris7s. 2. %e$ining t e re#uirements o$ t e second prototype. 3. 'lanning an designing t e second prototype. 4. *onstructing and testing t e second prototype. At t e customer option5 t e entire pro9ect can be aborted i$ t e ris7 is deemed too great. Ris7 $actors mig t in6ol6e de6elopment cost o6erruns5 operating-cost miscalculation5 or any ot er $actor t at could5 in t e customer?s 9udgment5 result in a less-t an-satis$actory $inal product. T e existing prototype is e6aluated in t e same manner as (as t e pre6ious prototype5 and i$ necessary5 anot er prototype is

de6eloped $rom it according to t e $our$old procedure outlined abo6e. T e preceding steps are iterated until t e customer is satis$ied t at t e re$ined prototype represents t e $inal product desired. T e $inal system is constructed5 based on t e re$ined prototype.

T e $inal system is t oroug ly e6aluated and tested.

Routine

maintenance is carried on a continuing basis to pre6ent large scale $ailures and to minimi:e do(n time. T.e follo+in( dia(ram s.o+s .o+ a s)iral model acts li9e:

Fi( 12:;S)iral %odel

AD"ANTA8ES: Estimates@i.e. budget5 sc edule etc .A become more relistic as (or7 progresses5 because important issues disco6ed earlier . It is more able to cope (it t e c anges t at are so$t(are de6elopment generally entails. So$t(are engineers can get t eir ands in and start (oring on t e core o$ a pro9ect earlier.

APP$ICATION DE"E$OP%ENT N;TIER APP$ICATIONS 8-Tier Applications can easily implement t e concepts o$ %istributed Application %esign and Arc itecture. T e 8-Tier Applications pro6ide strategic bene$its to Enterprise Solutions. = ile 2-tier5 client-ser6er can elp us create #uic7 and easy solutions and may be used $or Rapid 'rototyping5 t ey can easily become a maintenance and security nig t mare T e 8-tier Applications pro6ide speci$ic ad6antages t at are 6ital to t e business continuity o$ t e enterprise. Typical $eatures o$ a real li$e n-tier may include t e $ollo(ing> Security A6ailability and Scalability &anageability Easy &aintenance

%ata Abstraction

T e abo6e mentioned points are some o$ t e 7ey design goals o$ a success$ul n-tier application t at intends to pro6ide a good 4usiness Solution.

DEFINITION Simply stated5 an n-tier application elps us distribute t e o6erall $unctionality into 6arious tiers or layers> 'resentation )ayer 4usiness Rules )ayer %ata Access )ayer %atabaseH%ata Store

Eac layer can be de6eloped independently o$ t e ot er pro6ided t at it ad eres to t e standards and communicates (it t e ot er layers as per t e speci$ications. T is is t e one o$ t e biggest ad6antages o$ t e n-tier application. Eac layer can potentially treat t e ot er layer as a I4loc7-4ox?. In ot er (ords5 eac layer does not care o( ot er layer processes t e data as long as it sends t e rig t data in a correct $ormat.

Fi( 121;N;Tier Arc.itect-re

12 T E PRESENTATION $A&ER Also called as t e client layer comprises o$ components t at are dedicated to presenting t e data to t e user. For example> =indo(sH=eb Forms and buttons5 edit boxes5 Text boxes5 labels5 grids5 etc. 32 T E BUSINESS RU$ES $A&ER T is layer encapsulates t e 4usiness rules or t e business logic o$ t e encapsulations. To a6e a separate layer $or business logic is o$ a great ad6antage. T is is because any c anges in 4usiness Rules can be easily andled in t is layer. As long as t e inter$ace bet(een t e layers remains t e same5 any c anges to t e $unctionalityHprocessing logic in t is layer can be made (it out impacting t e ot ers. A lot o$ client-

ser6er apps $ailed to implement success$ully as c anging t e business logic (as a pain$ul process. 42 T E DATA ACCESS $A&ER T is layer comprises o$ components t at elp in accessing t e %atabase. I$ used in t e rig t (ay5 t is layer pro6ides a le6el o$ abstraction $or t e database structures. Simply put c anges made to t e database5 tables5 etc do not a$$ect t e rest o$ t e application because o$ t e %ata Access layer. T e di$$erent application layers send t e data re#uests to t is layer and recei6e t e response $rom t is layer. 52 T E DATABASE $A&ER T is layer comprises o$ t e %atabase *omponents suc as %4 Files5 Tables5 Die(s5 etc. T e Actual database could be created using SF) Ser6er5 !racle5 Flat $iles5 etc. In an n-tier application5 t e entire application can be implemented in suc a (ay t at it is independent o$ t e actual %atabase. For instance5 you could c ange t e %atabase )ocation (it minimal c anges to %ata Access )ayer. T e rest o$ t e Application s ould remain una$$ected.

SOFT#ARE RE/UIRE%ENT

Soft are Requirements:

!perating System > =indo(s Ea6a S(ing5 A=T. Ea6a /. !racle 13g &y Eclipse ,.3.

Jrap ical .ser Inter$ace > Application )ogic %atabase I%EH=or7benc > > >

ARD#ARE RE/UIRE%ENT

ard+are Re0-irements:

System Confi(-ration 'rocessor +ard %is7 RA& > > > 'entium III K 133 &+: 23 J4 120 &4

S&STE% DESI8N

%uring analysis5 t e $ocus is on ( at needs to be done5 independent o$

o( it is

done. %uring design5 decisions are made about o( t e problem (ill be sol6ed5 $irst at ig le6el5 t en at increasingly detailed le6els.

System design is t e $irst design stage in ( ic t e basic approac

to sol6ing

t e problem is selected. %uring system design5 t e o6erall structure and style are decided. T e system arc itecture is t e o6erall organi:ation o$ t e system into components called subsystems. T e arc itecture pro6ides t e context in ( ic more detailed decisions are made in later design stages. 4y ma7ing ig le6el decisions

t at apply to t e entire system5 t e system designer partitions t e problem into subsystems so t at $urt er (or7 can be done by se6eral designers (or7ing independently on di$$erent subsystems. T e system designer must ma7e t e $ollo(ing decisions> !rgani:e t e system into subsystems. Identi$y t e concurrency in erent in t e problem. Allocate subsystems to processors and tas7s. * oose an approac $or management o$ data stores. +andle access to global resources. * oose t e implementation o$ control in so$t(are. +andle boundary conditions. Set trade-o$$ priorities.

Brea9in( t.e System into S-,systems:

T e $irst step in system design is to di6ide t e system into small number o$ components. Eac ma9or component o$ a system is called a sub system. Eac

subsystem encompasses aspects o$ t e system t at s are some common property K similar $unctionality5 t e same p ysical location5 or execution on t e same 7ind o$ ard(are. A subsystem not an ob9ect nor a $unction but a pac7age o$ classes5 associations5 operations5 e6ents5 and constraints t at are interrelated and t at a reasonably (ell-de$ined and small inter$ace (it a6e

ot er subsystems. A subsystem

usually identi$ied by t e ser6ices it pro6ides. A ser6ice is a group o$ related $unctions t at s are some common purpose suc as IH! processing. A subsystem

de$ines a co erent (ay o$ loo7ing at one aspect o$ t e problem. Eac subsystem as a (ell-de$ined inter$ace to t e rest o$ t e system. T e

inter$ace speci$ies t e $orm o$ all interactions and t e in$ormation $lo( across subsystem boundaries but does not speci$y internally. Eac t e ot ers. T e decomposition o$ systems into subsystems may be organi:ed as a se#uence o$ ori:ontal layers or 6ertical partitions. A layered system is an ordered set o$ 6irtual (orlds5 eac built in terms o$ o( t e sub system is implemented

subsystem t en can be designed independently (it out a$$ecting

t e ones belo( it and pro6iding t e basis o$ implementation $or t e ones abo6e it. T e ob9ects in eac layer can be independent5 alt oug t ere is o$ten some

correspondence bet(een ob9ects in di$$erent layers. Lno(ledge is one-(ay only> a subsystem 7no(s about t e layers belo( it5 but layers. Eac layer may as no 7no(ledge o$ t e abo6e layer is

a6e its o(n set o$ classes and operations. Eac

implemented in terms o$ t e classes and operations o$ lo(er layers.

)ayered arc itecture comes in t(o $orms> closed and open. In a closed arc itecture5 eac layer is built only in terms o$ t e immediate lo(er layer. In a

open arc itecture5 a layer can use $eatures o$ any lo(er layer to any dept . =e decomposed our system into t ree subsystems as layers. T e t ree layers are closed arc itecture $orm. T e t ree layers are J.I layer5 8et(or7 layer and IH! layer. T e purpose o$ J.I layer is to pro6ide an e$$icient user inter$ace to t e user to interact (it t e system. It is built upon t e 8et(or7 layer ( ic

pro6ides basic FT' ser6ices. T e lo(est layer is t e IH! layer t at pro6ides ser6ices li7e reading or (riting $ile to and $rom local and remote systems.

!UI subsystem "#$ subsystem

I#O subsystem

= en top-le6el subsystems are identi$ied5 t e designer s ould s o( t e in$ormation $lo( among t e sub systems. T ere are se6eral arc itectural

$rame(or7s t at are common in existing systems. T ey are batc

trans$ormation5

continuous trans$ormation5 interacti6e inter$ace5 dynamic simulation5 real-time system and transaction manager.

In t e arc itectural $rame(or7s speci$ied abo6e5 our system (ill best suit in interacti6e inter$ace arc itecture5 since t ere are large number o$ interactions bet(een system and user. An interacti6e inter$ace is a system t at is dominated by interactions bet(een t e system and external agents5 suc as umans5 de6ices or ot er programs. T e

external agents are independent o$ system5 so t eir inputs can?t be controlled5 alt oug t e system may solicit responses $rom t em.

Identifyin( Conc-rrency:
!ne important goal o$ system design is to identi$y ( ic acti6e concurrently and ( ic ob9ects ob9ects must be

a6e acti6ity t at is mutually exclusi6e. T e

latter ob9ects can be $olded toget er in a single t read o$ control or tas7. 4ut t ere is no part t at is concurrent in our system.

Allocatin( S-,systems to Processor:

In t is step system designer estimates t e t e implementation c oice o$ eit er ard(are resources re#uired and

ard(are or so$t(are. In our system all t e ard(are re#uirements are

subsystems (ill be implemented in so$t(are. T e general suc as 'entium K III5 120 &4 o$ RA&.

%ana(ement of Data Stores:

In t is stage t e system designer decides ( at $ormat is used to store t e data stores. T ere are %4&S systems or $ile systems and ot ers. +ere in our

pro9ect t ere are no data stores except $iles. =e t en de$initely pre$er $iles to do(nload and upload.

C.oosin( Soft+are Control Im)lementation:

%uring t e analysis5 all interactions are s o(n as e6ents bet(een ob9ects. 4ut t e system designer must c oose among se6eral (ays to implement control in so$t(are. T ere are t(o 7inds o$ control $lo(s in a so$t(are system> internal and external. External control is t e $lo( o$ externally 6isible e6ents among t e ob9ects in t e system. T ere are t ree 7inds o$ control $or external e6ents> procedure dri6en5 e6ent dri6en se#uential and concurrent. Internal control is t e $lo( o$ control (it in a process. !ur system $alls in external control $lo( li7e e6ent dri6en control. E6ents are $ired by external agent suc as user in di$$erent order but se#uential not concurrent.

PROCESS F$O#

E%R&I'!R'(S E(*+O,EE:

)ET$EE"

'&(I"ISTR'TOR

'"&

User id

Pwd User id Pwd

Administrato r

Authenticat ion %

Employee

E%R

&I'!R'(S

)ET$EE"

E(*+O,EE

'"&

E,E$IT"ESS:

User id

Pwd

Crimina l images

User id

Pwd

Employee

#iewing & selecting & images

Eyewitness

Crimin al details

Crimina l images

E%R

&I'!R'(

)ET$EE"

E,E$IT"ESS

'"&

CRI(I"'+:

Crimina l images

Crimina l id

Criminal details

Eyewitness

dentificati on

Criminal

E%R &I'!R'( )ET$EE" E(*+O,EE '"& CRI(I"'+:

User id

Pw d

Crimina l d

Crimin al details

Employee

'etti ng detail s of crimi nal

Criminal

E%R

&I'!R'(

)ET$EE"

E,E$IT"ESS

'"&

'&(I"ISTTR'TOR

Use r id

Pwd User id Pw d

Administrator

Auth entic ation

Eyewitness

DATA F$O# DIA8RA%S

DATA F$O# DIA8RA%S: A grap ical tool used to describe and analy:e t e moment o$ data t roug a

system manual or automated including t e process5 stores o$ data5 and delays in t e system. %ata Flo( %iagrams are t e central tool and t e basis $rom ( ic ot er components are de6eloped. T e trans$ormation o$ data

$rom input to output5 t roug

processes5 may be described logically and

independently o$ t e p ysical components associated (it %F% is also 7no( as a data $lo( grap or a bubble c art.

t e system. T e

%F%s are t e model o$ t e proposed system. T ey clearly s ould s o( t e re#uirements on ( ic t e ne( system s ould be built. )ater during design

acti6ity t is is ta7en as t e basis $or dra(ing t e system?s structure c arts. T e 4asic 8otation used to create a %F%?s are as $ollo(s> 12 Dataflo+: %ata mo6e in a speci$ic direction $rom an origin to a destination.

32 Process: 'eople5 procedures5 or de6ices t at use or produce @Trans$ormA %ata. T e p ysical component is not identi$ied.

42 So-rce: External sources or destination o$ data5 ( ic may be 'eople5 programs5 organi:ations or ot er entities.

52 Data Store: +ere data are stored or re$erenced by a process in t e System.

Data Flo+ Dia(rams:

+E-E+ .

+E-E+ /

/0

&F& FOR Client:

+E-E+%/:

&F& FOR S1lit 2 (er3e:

+E-E+ .:

+E-E+ /:

U%$ Dia(rams T e .ni$ied &odeling )anguage @.&)A is an open met od used to speci$y5 6isuali:e5 modi$y5 construct and document t e arti$acts o$ an ob9ect-oriented

so$t(are intensi6e system under de6elopment. .&) o$$ers a standard (ay to (rite a systemMs blueprints5 including conceptual components suc as>

actors5 business processes and system components and acti6ities

as (ell as concrete t ings suc as>

programming language statements5 database sc emas5 and Reusable so$t(are components. as entity

.&) combines best practices $rom data modeling concepts suc component modeling. It can be used (it

relations ip diagrams5 business modeling @(or7 $lo(A5 ob9ect modeling and all processes5 t roug out t e so$t(are as de6elopment li$e cycle5 and across di$$erent implementation tec nologies .N3O .&)

succeeded t e concepts o$ t e 4ooc met od5 t e !b9ect-modeling tec ni#ue @!&TA and !b9ect-oriented so$t(are engineering @!!SEA by $using t em into a single5 common and (idely usable modeling language. .&) aims to be a standard modeling language ( ic can model concurrent and distributed systems. .&) is not as initially called $or in$ormation on ob9ectan industry standard5 but is ta7ing s ape under t e auspices o$ t e !b9ect &anagement Jroup @!&JA. !&J oriented met odologies5 t at mig t create a rigorous so$t(are modeling language. &any industry leaders a6e responded in earnest to elp create t e standard .N1O

.&) models may be automatically trans$ormed to ot er representations @e.g. Ea6aA by means o$ FDT-li7e trans$ormation languages5 supported by t e !&J. .&) is extensible5 o$$ering t e $ollo(ing mec anisms $or customi:ation> pro$iles and stereotype. Class Dia(ram:

Use case Descri)tion:

In so$t(are engineering5 a use case diagram in t e .ni$ied &odeling )anguage @.&)A is a type o$ be a6ioral diagram de$ined by and created $rom a .se-case analysis. Its purpose is to present a grap ical o6er6ie( o$ t e $unctionality pro6ided by a system in terms o$ actors5 t eir goals @represented as use casesA5 and any dependencies bet(een t ose use cases. T e main purpose o$ a use case diagram is to s o( ( at system $unctions are per$ormed $or ( ic depicted. .se *ase diagrams are $ormally included in t(o modeling languages de$ined by t e !&J. 4ot t e .&) and Sys&) standards de$ine a grap ical notation diagrams. !ne complaint about t e standards $or modeling use cases (it Jenerally5 bot system. T e use case diagram s o(s t e position or context o$ t e use case among ot er use cases. As an organi:ing mec anism5 a set o$ consistent5 co erent use cases promotes a use$ul picture o$ system be a6ior5 a common understanding bet(een t e customerHo(nerHuser and t e de6elopment team. actor. Roles o$ t e actors in t e system can be

as been t at t ey do not de$ine a $ormat $or describing t ese use cases. grap ical notation and descriptions are important as t ey an actor uses a document t e use case5 s o(ing t e purpose $or ( ic

Use case Dia(ram:

'dministrator:

+o3in

Insertin3# U1datin3 Criminal &etails

'lready E4isted Criminal criminal 'dministrator S1littin3# U1datin3 Ima3es "e Criminal Insertin3# U1datin3 Face &etails

&eletin3 Ima3es

Client 5O1erator6:

o1erator +o3in

retrivin3 the ima3es

o1erator identifyin3 the ima3es

Criminal

Se0-ence Dia(ram:

A se#uence diagram in .ni$ied &odelling )anguage @.&)A is a 7ind o$ interaction diagram t at s o(s o( processes operate (it one anot er and in ( at order. It

is a construct o$ a &essage Se#uence * art. Se#uence diagrams are sometimes called E6ent-trace diagrams5 e6ent scenarios5 and timing diagrams. A se#uence

diagram s o(s5 as parallel 6ertical lines @Pli$elinesPA5 di$$erent processes or ob9ects t at li6e simultaneously5 and5 as ori:ontal arro(s5 t e messages t ey occur. T is allo(s t e

exc anged bet(een t em5 in t e order in ( ic

speci$ication o$ simple runtime scenarios in a grap ical manner. Administrator:

Authentication

Criminal

split image()

Face

System

login into system as administrator()

giving/retrieving Details()

Ask details()

insert/Updat details()

split image()

insert/update face()

delete crimminal()

O1erator:

perator

Data!ase

System

login into system as operator()

setting the Image Id()

"etrieving the Images()

Identifying Images()

Colla,oration Dia(ram:

A *ommunication diagram models t e interactions bet(een ob9ects or parts in terms o$ se#uenced messages. *ommunication diagrams represent a combination o$ in$ormation ta7en $rom *lass5 Se#uence5 and .se *ase %iagrams describing bot system. +o(e6er5 communication diagrams use t e $ree-$orm arrangement o$ ob9ects and lin7s as used in !b9ect diagrams. In order to maintain t e ordering o$ messages in suc a $ree-$orm diagram5 messages are labeled (it a c ronological number and placed near t e lin7 t e message is sent o6er. Reading a communication diagram in6ol6es starting at message 1.35 and $ollo(ing t e messages $rom ob9ect to ob9ect. t e static structure and dynamic be a6ior o$ a

*ommunication diagrams s o( a lot o$ t e same in$ormation as se#uence diagrams5 but because o$ ( ic elements eac o( t e in$ormation is presented5 some o$ it is better5 but se#uence diagrams s o( easier to $ind in one diagram t an t e ot er. *ommunication diagrams s o( one interacts (it t e order in ( ic t e interactions ta7e place more clearly. Administrator:

System

Face

$: insert/update %ace() 1: login into system as administrator()

#: split image() 2: giving/retrieving Details() Criminal 3: As details() !: insert/"pdat details() &: delete crimminal() Authentic ation

split image()

O)erator:

!: )denti%ying )mages()

2: setting the )mage )d() 'perator 3: *etrieving the )mages() Data(as e

1: login into system as operator()

System

Acti*ity Dia(ram:

Acti6ity diagrams are a loosely de$ined diagram tec ni#ue $or s o(ing (or7$lo(s o$ step(ise acti6ities and actions5 (it support $or c oice5

iteration and concurrency. In t e .ni$ied &odeling )anguage5 acti6ity diagrams can be used to describe t e business and operational step-by-step (or7$lo(s o$ components in a system. n Sys&) t e acti6ity diagram as

been extended to indicate $lo(s among steps t at con6ey p ysical element @e.g.5 gasolineA or energy @e.g.5 tor#ue5 pressureA.

Administrator:

Adm inistrator

chec* +o yes

Crim inal Details

(perations

nsert

Update

Delete

#iew

splitting

)erging

O)erator:

(perator

chec* +o yes

,etrie!e m age

dentify m age

Com)onent Dia(ram:

A component diagram in t e .ni$ied &odeling )anguage5 depicts

o(

components are (ired toget er to $orm larger components and or so$t(are systems. *omponents are (ired toget er by using an assembly connector to connect t e re#uired inter$ace o$ one component (it t e pro6ided inter$ace o$ anot er component. T is illustrates t e ser6ice consumer - ser6ice pro6ider relations ip bet(een t e t(o components. An assembly connector is a Pconnector bet(een t(o components t at de$ines t at one component

pro6ides t e ser6ices t at anot er component re#uires. An assembly connector is a connector t at is de$ined $rom a re#uired inter$ace or port to a pro6ided inter$ace or port.P = en using a component diagram to s o( t e internal structure o$ a component5 t e pro6ided and re#uired inter$aces o$ t e encompassing component can delegate to t e corresponding inter$aces o$ t e contained components.

'dministrator

O1erator

Ima3es

S1lit

(er3e

De)loyment Dia(ram: A deployment diagram in t e .ni$ied &odeling )anguage ser6es to model t e p ysical deployment o$ arti$acts on deployment targets. %eployment diagrams s o( Pt e allocation o$ Arti$acts to 8odes according to t e %eployments de$ined bet(een t em.P %eployment o$ an arti$act to a node is indicated by placing t e arti$act inside t e node. Instances o$ nodes @and de6ices and execution en6ironmentsA are used in deployment diagrams to indicate multiplicity o$ t ese nodes. For example5 multiple instances o$ an

application ser6er execution en6ironment may be deployed inside a single de6ice node to represent application ser6er clustering.

In1ut Ima3es

S1littin3

!ettin3 ima3e *arts

Identify Ima3e

TEC NO$O8& DESCRIPTION

FEATURES OF THE LANGUAGE USED:

A,o-t !a*a:

Initially t e language (as called as Boa7C but it (as renamed as BEa6aC in 111". T e primary moti6ation o$ t is language (as t e need $or a plat$ormindependent @i.e.5 arc itecture neutralA language t at could be used to create so$t(are to be embedded in 6arious consumer electronic de6ices.
Ea6a is a programmer?s language. Ea6a is co esi6e and consistent. Except $or t ose constraints imposed by t e Internet en6ironment5

Ea6a gi6es t e programmer5 $ull control. Finally5 Ea6a is to Internet programming ( ere * (as to system programming. S+in(s:
S(ing5 ( ic is an extension library to t e A=T5 includes ne( and impro6ed

components t at en ance t e loo7 and $unctionality o$ J.Is. S(ing can be used to build Standalone s(ing J.I Apps as (ell as Ser6lets and Applets. It employs a modelH6ie( design arc itecture. S(ing is more portable and more $lexible t an A=T. S(ing is built on top o$ A=T and is entirely (ritten in Ea6a5 using A=T?s lig t(eig t component support. In particular5 unli7e A=T5 t components ma7es it easy to customi:e bot e arc itecture o$ S(ing t eir appearance and be a6ior.

*omponents $rom A=T and S(ing can be mixed5 allo(ing you to add S(ing support

to existing A=T-based programs. For example5 s(ing components suc E4utton and E* ec7box could be used in t e same program (it c ange listener classes (it out

as ESlider5

standard A=T

labels5 text$ields and scrollbars. Qou could subclass t e existing S(ing .I5 model5 or a6ing to rein6ent t e entire implementation. S(ing also as t e ability to replace t ese ob9ects on-t e-$ly.

133< Ea6a implementation o$ components 'luggable )oo7 2 Feel )ig t(eig t components Uses %"C Arc.itect-re &odel represents t e data Die( as a 6isual representation o$ t e data *ontroller ta7es input and translates it to c anges in data

T.ree )arts *omponent set @subclasses o$ E*omponentA Support classes Inter$aces

In S(ing5 classes t at represent J.I components (it

a6e names beginning

t e letter E. Some examples are E4utton5 E)abel5 and ESlider. Altoget er

t ere are more t an 2"3 ne( classes and /" inter$aces in S(ing R t(ice as many as in A=T. !a*a S+in( class .ierarc.y
T e class E*omponent5 descended directly $rom *ontainer5 is t e root class $or most o$ S(ing?s user inter$ace components.

S(ing contains components t at you?ll use to build a J.I. I am listing you some o$ t e commonly used S(ing components. To learn and understand t ese s(ing programs5 A=T 'rogramming 7no(ledge is not re#uired.

A))lications and A))lets An application is a program t at runs on our *omputer under t e operating system o$ t at computer. It is more or less li7e one creating using * or *SS. Ea6a?s ability to create Applets ma7es it important. An Applet is an application designed5 to be transmitted o6er t e Internet and executed by a Ea6a Kcompatible (eb bro(ser. An applet is actually a tiny Ea6a program5 dynamically do(nloaded across t e net(or75 9ust li7e an image. 4ut t e di$$erence is5 it is an intelligent program5 not 9ust a media $ile. It can react to t e user input and dynamically c ange.

FEATURES OF !A"A: Sec-rity E6ery time you t at you do(nload a BnormalC program5 you are ris7ing a 6iral in$ection. 'rior to Ea6a5 most users did not do(nload executable programs $re#uently5 and t ose ( o did scan t em $or 6iruses prior to execution. &ost users still (orried about t e possibility o$ in$ecting t eir systems (it a 6irus. In addition5 anot er type o$ malicious program

exists t at must be guarded against. T is type o$ program can gat er pri6ate in$ormation5 suc as credit card numbers5 ban7 account balances5 o$ t ese concerns by pro6iding a

and pass(ords. Ea6a ans(ers bot

B$ire(allC bet(een a net(or7ed application and your computer. = en you use a Ea6a-compatible =eb bro(ser5 you can sa$ely do(nload Ea6a applets (it out $ear o$ 6irus in$ection or malicious intent. Porta,ility
For programs to be dynamically do(nloaded to all t e 6arious types o$ plat$orms connected to t e Internet5 some means o$ generating portable executable code is needed .As you (ill see5 t e same mec anism t at elps ensure security also elps

create portability. Indeed5 Ea6a?s solution to t ese t(o problems is bot elegant and e$$icient.

T.e Byte code

T e 7ey t at allo(s t e Ea6a to sol6e t e security and portability problem is t at t e output o$ Ea6a compiler is 4yte code. 4yte code is a ig ly optimi:ed set o$ is called t e

instructions designed to execute by t e Ea6a run-time system5 ( ic

Ea6a Dirtual &ac ine @ED&A. T at is5 in its standard $orm5 t e ED& is an interpreter $or byte code. Translating a Ea6a program into byte code elps ma7es it muc easier to run a

program in a (ide 6ariety o$ en6ironments. T e reason is5 once t e run-time pac7age exists $or a gi6en system5 any Ea6a program can run on it.

Alt oug

Ea6a (as designed $or interpretation5 t ere is tec nically not ing

about Ea6a t at pre6ents on-t e-$ly compilation o$ byte code into nati6e code. Sun as 9ust completed its Eust In Time @EITA compiler $or byte code.

= en t e EIT compiler is a part o$ ED&5 it compiles byte code into executable code in real time5 on a piece-by-piece5 demand basis. It is not possible to compile an entire Ea6a program into executable code all at once5 because Ea6a per$orms 6arious run-time c ec7s t at can be done only at run time. T e EIT compiles code5 as it is needed5 during execution. !a*a "irt-al %ac.ine <!"%= 4eyond t e language5 t ere is t e Ea6a 6irtual mac ine. T e Ea6a 6irtual mac ine is an important element o$ t e Ea6a tec nology. T e 6irtual mac ine can be embedded (it in a (eb bro(ser or an operating system. !nce a piece o$ Ea6a code is loaded onto a mac ine5 it is 6eri$ied. As part o$ t e loading process5 a class loader is in6o7ed and does byte code 6eri$ication

ma7es sure t at t e code t at?s

as been generated by t e compiler (ill not

corrupt t e mac ine t at it?s loaded on. 4yte code 6eri$ication ta7es place at t e end o$ t e compilation process to ma7e sure t at is all accurate and correct. So byte code 6eri$ication is integral to t e compiling and executing o$ Ea6a code.

7ava Source
2!a*a

7avac

Java byte code

7ava -irtu al

2Class

T e

abo6e

picture

s o(s

t e

de6elopment

process

typical

Ea6a

programming uses to produce byte codes and executes t em. T e $irst box indicates t at t e Ea6a source code is located in a. Ea6a $ile t at is processed (it a Ea6a compiler called !A"A. T e Ea6a compiler produces a $ile called a. contains t e byte code. T e class $ile is t en loaded across

class $ile5 ( ic

t e net(or7 or loaded locally on your mac ine into t e execution en6ironment is t e Ea6a 6irtual mac ine5 ( ic byte code. interprets and executes t e

!a*a Arc.itect-re Ea6a arc itecture pro6ides a portable5 robust5 ig per$orming en6ironment

$or de6elopment. Ea6a pro6ides portability by compiling t e byte codes $or t e Ea6a Dirtual &ac ine5 ( ic is t en interpreted on eac plat$orm by t e

run-time en6ironment. Ea6a is a dynamic system5 able to load code ( en needed $rom a mac ine in t e same room or across t e planet. Com)ilation of Code = en you compile t e code5 t e Ea6a compiler creates mac ine code @called byte codeA $or a ypot etical mac ine called Ea6a Dirtual &ac ine @ED&A. T e

ED& is supposed to execute t e byte code. T e ED& is created $or o6ercoming t e issue o$ portability. T e code is (ritten and compiled $or one mac ine and interpreted on all mac ines. T is mac ine is called Ea6a Dirtual &ac ine. *ompiling and interpreting Ea6a Source *ode

%uring run-time t e Ea6a interpreter tric7s t e byte code $ile into t in7ing t at it is running on a Ea6a Dirtual &ac ine. In reality t is could be a Intel 'entium =indo(s 1" or Suns AR* station running Solaris or Apple &acintos running system and all could recei6e code $rom any computer t roug Internet and run t e Applets. SI%P$E

Ea6a (as designed to be easy $or t e 'ro$essional programmer to learn and to use e$$ecti6ely. I$ you are an experienced *SS programmer5 learning Ea6a (ill be e6en easier. 4ecause Ea6a in erits t e *H*SS syntax and many o$ t e ob9ect oriented $eatures o$ *SS. &ost o$ t e con$using concepts $rom *SS are eit er le$t out o$ Ea6a or implemented in a cleaner5 more approac able manner. In Ea6a t ere are a small number o$ clearly de$ined (ays to accomplis a gi6en tas7.

Object-Oriented
Ea6a (as not designed to be source-code compatible (it allo(ed t e Ea6a team t e $reedom to design (it t is (as a clean usable5 pragmatic approac any ot er language. T is

a blan7 slate. !ne outcome o$

to ob9ects. T e ob9ect model in Ea6a is as integers5 are 7ept as ig -

simple and easy to extend5 ( ile simple types5 suc per$ormance non-ob9ects.

Robust
T e multi-plat$orm en6ironment o$ t e =eb places extraordinary demands on a program5 because t e program must execute reliably in a 6ariety o$ systems. T e ability to create robust programs (as gi6en a ig priority in t e design o$ Ea6a.

Ea6a is strictly typed language; it c ec7s your code at compile time and run time. Ea6a 6irtually eliminates t e problems o$ memory management and de-allocation5 ( ic is completely automatic. In a (ell-(ritten Ea6a program5 all run time errors

can Kand s ould Kbe managed by your program.

What is networ in!"

*omputers running on t e Internet communicate to eac ot er using eit er t e Transmission *ontrol 'rotocol @T*'A or t e .ser %atagram 'rotocol @.%'A5 as t is diagram illustrates>

= en you (rite Ea6a programs t at communicate o6er t e net(or75 you are programming at t e application layer. Typically5 you donMt need to concern yoursel$ (it t e T*' and .%' layers. Instead5 you can use t e classes in t e java.net

pac7age. T ese classes pro6ide system-independent net(or7 communication. +o(e6er5 to decide ( ic Ea6a classes your programs s ould use5 you do need to

understand o( T*' and .%' di$$er.

TCP = en t(o applications (ant to communicate to eac establis a connection and send data bac7 ot er reliably5 t ey $ort o6er t at

and

connection.T is is analogous to ma7ing a telep one call. I$ you (ant to spea7 to Aunt 4eatrice in Lentuc7y5 a connection is establis ed ( en you dial er p one number and s e ans(ers. Qou send data bac7 and $ort o6er

t e connection by spea7ing to one anot er o6er t e p one lines. )i7e t e

p one company5 T*' guarantees t at data sent $rom one end o$ t e connection actually gets to t e ot er end and in t e same order it (as sent. !t er(ise5 an error is reported. T*' pro6ides a point-to-point c annel $or applications t at re#uire reliable communications. T e +ypertext Trans$er 'rotocol @+TT'A5 File Trans$er 'rotocol @FT'A5 and Telnet are all examples o$ applications t at re#uire a reliable communication c annel. T e order in ( ic t e data is sent and

recei6ed o6er t e net(or7 is critical to t e success o$ t ese applications. = en +TT' is used to read $rom a .R)5 t e data must be recei6ed in t e order in ( ic it (as sent. !t er(ise5 you end up (it a 9umbled +T&) $ile5

a corrupt :ip $ile5 or some ot er in6alid in$ormation.

Definition: T*' @Transmission Control ProtocolA is a connection-based protocol t at pro6ides a reliable $lo( o$ data bet(een t(o computers.

UDP
T e .%' protocol pro6ides $or communication t at is not guaranteed bet(een t(o applications on t e net(or7. .%' is not connection-based li7e T*'. Rat er5 it sends independent pac7ets o$ data5 called datagrams5 $rom one application to anot er. Sending datagrams is muc li7e sending a letter t roug t e postal ser6ice> T e message is

order o$ deli6ery is not important and is not guaranteed5 and eac independent o$ any ot er.

Definition: .%' @User Datagram ProtocolA is a protocol t at sends independent pac7ets o$ data5 called datagram?s5 $rom one computer to anot er (it guarantees about arri6al. .%' is not connection-based li7e T*'. no

For many applications5 t e guarantee o$ reliability is critical to t e success o$ t e trans$er o$ in$ormation $rom one end o$ t e connection to t e ot er. +o(e6er5 ot er $orms o$ communication donMt re#uire suc strict standards.

In $act5 t ey may be slo(ed do(n by t e extra o6er ead or t e reliable connection may in6alidate t e ser6ice altoget er. *onsider5 $or example5 a cloc7 ser6er t at sends t e current time to its client ( en re#uested to do so. I$ t e client misses a pac7et5 it doesnMt really ma7e sense to resend it because t e time (ill be incorrect ( en t e client recei6es it on t e second try. I$ t e client ma7es t(o re#uests and recei6es pac7ets $rom t e ser6er out o$ order5 it doesnMt really matter because t e client can $igure out t at t e pac7ets are out o$ order and ma7e anot er re#uest. T e reliability o$ T*' is unnecessary in t is instance because it causes per$ormance degradation and may inder t e use$ulness o$ t e ser6ice. Anot er example o$ a ser6ice t at doesnMt need t e guarantee o$ a reliable c annel is t e ping command. T e purpose o$ t e ping command is to test t e communication bet(een t(o programs o6er t e net(or7. In $act5 ping needs to 7no( about dropped or out-o$-order pac7ets to determine o(

good or bad t e connection is. A reliable c annel (ould in6alidate t is ser6ice altoget er. T e .%' protocol pro6ides $or communication t at is not guaranteed bet(een t(o applications on t e net(or7. .%' is not connection-based li7e T*'. Rat er5 it sends independent pac7ets o$ data $rom one application to anot er. Sending datagram?s is muc li7e sending a letter t roug t e mail

ser6ice> T e order o$ deli6ery is not important and is not guaranteed5 and eac message is independent o$ any ot ers.
Note: &any $ire(alls and routers I$ youMre are a6e been con$igured not to allo( .%' pac7ets.

a6ing trouble connecting to a ser6ice outside your $ire(all5 or i$ clients

a6ing trouble connecting to your ser6ice5 as7 your system administrator i$ .%'

is permitted. FTP Protocol:

File Transfer Protocol @FTPA is a standard net(or7 protocol used to exc ange
and manipulate $iles o6er an Internet 'rotocol computer net(or75 suc as t e Internet. FT' is built on a client-ser6er arc itecture and utili:es separate control and data connections bet(een t e client and ser6er applications. *lient applications (ere originally interacti6e command-line tools (it syntax5 but grap ical user inter$aces a standardi:ed command a6e been de6eloped $or all des7top operating

systems in use today. FT' is also o$ten used as an application component to automatically trans$er $iles $or program internal $unctions. FT' can be used (it user-based pass(ord a = ile data is being trans$erred 6ia t e data stream5 t e control stream sits idle. T is can cause problems (it $ire(alls ( ic large data trans$ers t roug time out sessions a$ter lengt y periods o$ idleness. = ile t e $ile

may (ell be success$ully trans$erred5 t e control session can be disconnected by t e $ire(all5 causing an error to be generated. T e FT' protocol supports resuming o$ interrupted do(nloads using t e REST command. T e client passes t e number o$ bytes it as already recei6ed as argument to t e REST command and restarts t e trans$er. In some commandline clients $or example5 t ere is an o$ten-ignored but 6aluable command5 PregetP @meaning Pget againPA5 t at (ill cause an interrupted PgetP command to be continued5 ope$ully to completion5 a$ter a communications interruption. Resuming uploads is not as easy. Alt oug t e FT' protocol supports t e A''E

command to append data to a $ile on t e ser6er5 t e client does not 7no( t e exact position at ( ic a trans$er got interrupted. It as to obtain t e si:e o$ t e $ile some ot er (ay5 $or example o6er a directory listing or using t e SITE command. In AS*II mode @see belo(A5 resuming trans$ers can be troublesome i$ client and ser6er use di$$erent end o$ line c aracters.

Understandin( Ports
Jenerally spea7ing5 a computer as a single p ysical connection to t e net(or7. All t at connection. +o(e6er5

data destined $or a particular computer arri6es t roug

t e data may be intended $or di$$erent applications running on t e computer. So o( does t e computer 7no( to ( ic use o$ ports. application to $or(ard t e dataG T roug t e

%ata

transmitted

o6er

t e

Internet

is

accompanied

by

addressing

in$ormation t at identi$ies t e computer and t e port $or ( ic T e computer is identi$ied by its 32-bit I' address5 ( ic

it is destined.

I' uses to deli6er

data to t e rig t computer on t e net(or7. 'orts are identi$ied by a 1,-bit number5 ( ic T*' and .%' use to deli6er t e data to t e rig t application.

In connection-based communication suc a soc7et to a speci$ic port number. T is ser6er (it

as T*'5 a ser6er application binds as t e e$$ect o$ registering t e

t e system to recei6e all data destined $or t at port. A client can

t en rende:6ous (it t e ser6er at t e ser6erMs port5 as illustrated ere>

Definition: T e T*' and .%' protocols use ports to map incoming data to a particular process running on a computer.

In datagram-based communication suc

as .%'5 t e datagram pac7et

contains t e port number o$ its destination and .%' routes t e pac7et to t e appropriate application5 as illustrated in t is $igure>

'ort numbers range $rom 3 to ,"5"3" because ports are represented by 1,-bit numbers. T e port numbers ranging $rom 3 - 1323 are restricted; t ey are reser6ed $or use by (ell-7no(n ser6ices suc as +TT' and FT' and ot er system ser6ices.

T ese ports are called well-known ports. Qour applications s ould not attempt to bind to t em.

Net+or9in( Classes in t.e !D>

T roug t e classes in java.net5 Ea6a programs can use T*' or .%' to

communicate o6er t e Internet. T e URL5 URL Connection5 Socket5 and Server

Socket classes all use T*' to communicate o6er t e net(or7. T e Datagram Packet5 Datagram Socket5 and Multicast Socket classes are $or use (it
.%'.

What #s a URL? I$ youM6e been sur$ing t e =eb5 you a6e undoubtedly eard t e term .R)

and a6e used .R)s to access +T&) pages $rom t e =eb. ItMs o$ten easiest5 alt oug not entirely accurate5 to t in7 o$ a .R) as t e

name o$ a $ile on t e =orld =ide =eb because most .R)s re$er to a $ile on some mac ine on t e net(or7. +o(e6er5 remember t at .R)s also can point to ot er resources on t e net(or75 suc output.
Definition: .R) is an acronym $or Uniform Resource Locator and is a re$erence @an addressA to a resource on t e Internet.

as database #ueries and command

T e $ollo(ing is an example o$ a .R) ( ic osted by Sun &icrosystems>

addresses t e Ea6a =eb site

As in t e pre6ious diagram5 a .R) as t(o main components> 'rotocol identi$ier Resource name

8ote t at t e protocol identi$ier and t e resource name are separated by a colon and t(o $or(ard slas es. T e protocol identi$ier indicates t e name o$ t e protocol to be used to $etc t e resource. T e example uses t e is typically used to ser6e up

+ypertext Trans$er 'rotocol @+TT'A5 ( ic

ypertext documents. +TT' is 9ust one o$ many di$$erent protocols used to access di$$erent types o$ resources on t e net. !t er protocols include File Trans$er 'rotocol @FT'A5 Jop er5 File5 and 8e(s. T e resource name is t e complete address to t e resource. T e $ormat o$ t e resource name depends entirely on t e protocol used5 but $or many protocols5 including +TT'5 t e resource name contains one or more o$ t e components listed in t e $ollo(ing table>

ost Name

T e name o$ t e mac ine on ( ic t e resource li6es. T e pat name to t e $ile on t e mac ine. T e port number to ( ic to connect @typically optionalA. A re$erence to a named anc or (it in a resource t at usually identi$ies a speci$ic location (it in a

Filename

Port N-m,er

Reference

$ile @typically optionalA.

For many protocols5 t e

ost name and t e $ilename are re#uired5 ( ile t e

port number and re$erence are optional. For example5 t e resource name $or an +TT' .R) must speci$y a ser6er on t e net(or7 @+ost 8ameA and t e pat to t e document on t at mac ine @FilenameA; it also can speci$y a port

number and a re$erence. In t e .R) $or t e Ea6a =eb site java.sun.com is t e ost name and t e trailing slas is s ort and $or t e $ile named /index.html.
Se0-ence of soc9et calls for connection;oriented )rotocol:

System Calls
Soc7et - create a descriptor $or use in net(or7 communication. !n success5 soc7et system call returns a small integer 6alue similar to a $ile descriptor 8ame.

Bind - Bind a local IP address and protocol port to a socket

= en a soc7et is created it does not a6e nay notion o$ endpoint address. An

application calls bind to speci$y t e local; endpoint address in a soc7et. For T*'HI' protocols5 t e endpoint address uses t e soc7et address in structure. Ser6ers use bind to speci$y t e (ell-7no(n port at ( ic t ey (ill a(ait connections.

Connect - connect to remote client

A$ter creating a soc7et5 a client calls connect to establis an actual connection to a

remote ser6er. An argument to connect allo(s t e client to speci$y t e remote

endpoint5 ( ic

include t e remote mac ines I' address and protocols port

number. !nce a connection as been made5 a client can trans$er data across it.

ccept !" - accept t#e ne$t incoming connection

Accept creates a ne( soc7et $or eac ne( connection re#uest and returns t e

descriptor o$ t e ne( soc7et to its caller. T e ser6er uses t e ne( soc7et only $or t e ne( connections it uses t e original soc7et to accept additional connection re#uests once it soc7et. as accepted connection5 t e ser6er can trans$er data on t e ne(

Ret-rn "al-e:
T is system-call returns up to t ree 6alues An integer return code t at is eit er an error indication or a ne( soc7et description T e address o$ t e client process T e si:e o$ t is address )isten - place t e soc7et in passi6e mode and set t e number o$ incoming T*' connections t e system (ill en-#ueue. 4ac7log - speci$ies o( many connections

re#uests can be #ueued by t e system ( ile it (ants $or t e ser6er to execute t e accept system call it us usually executed a$ter bot calls5 and immediately be$ore t e accept system call. Send; send to5 rec6 and rec6$rom system calls t e soc7et and bind system

T ese system calls are similar to t e standard read and (rite system calls5 but additional arguments are re#uested. *lose - terminate communication and de-allocate a descriptor. T e normal .8IU close system call is also used to close a soc7et.

CODIN8

import 9a6a.a(t.V; Import 9a6a.a(t.e6ent.V; Import 9a6ax.s(ing.V;

public class !perator extends EFrame implements Action)istener W )abel l5l3; E)abel l25l1; Font $; 4utton b15b25b35b45b"5b05b15b13; *ontainer c1;

!perator@A W c1Xget*ontent'ane@A; c1.set)ayout@ne( Flo()ayout@AA;

set4ac7ground@*olor.)IJ+TYJRAQA;

$Xne( Font@PArialP5Font.4!)%523A;

setFont@$A;

ImageIcon iXne( ImageIcon@Pcriminal1.9pgPA;

lXne( )abel@P PA; l2Xne( E)abel@P P5i5E)abel.)EA%I8JA;

=elcome * anduZZZZZZZZ

+i5

l3Xne( )abel@P P5)abel.*E8TERA;

T is is !perator

b3Xne( 4utton@P

Identi$ying o$ Images

PA;

b4Xne( 4utton@P

Images $rom %ata 4ase

PA;

HHb"Xne( 4utton@P

Images $rom Eye(itnesses

PA;

b0Xne( 4utton@P

%ra(ing o$ Images

PA;

HH b1Xne( 4utton@P

&atc ing o$ Images

PA;

HHb13Xne( 4utton@P

%ata to Administrator

PA;

add=indo()istener@ne( =indo(Adapter@A W public 6oid (indo(*losing@=indo(E6ent eA W System.exit@3A; [ [A;

l.setForeground@ne( *olor@13351335133AA; l.setFont@ne( Font@PArialP5Font.4!)%533AA; l2.setForeground@ne( *olor@13351335133AA; l2.setFont@ne( Font@PArialP5Font.4!)%523AA; l3.setForeground@ne( *olor@35,45,4AA; l3.setFont@ne( Font@PArialP5Font.4!)%523AA;

b3.setForeground@ne( *olor@2""52""52""AA; b3.set4ac7ground@ne( *olor@35,45,4AA; b3.setFont@ne( Font@PArialP5Font.4!)%51"AA;

b4.setForeground@ne( *olor@2""52""52""AA; b4.setFont@ne( Font@PArialP5Font.4!)%51"AA; b4.set4ac7ground@ne( *olor@35,45,4AA;

HH b".setForeground@ne( *olor@2""52""52""AA; HH b".setFont@ne( Font@PArialP5Font.4!)%51"AA; HH b".set4ac7ground@ne( *olor@35,45,4AA;

b0.setForeground@ne( *olor@2""52""52""AA; b0.setFont@ne( Font@PArialP5Font.4!)%51"AA; b0.set4ac7ground@ne( *olor@35,45,4AA;

HVb1.setForeground@ne( *olor@2""52""52""AA; b1.setFont@ne( Font@PArialP5Font.4!)%51"AA; b1.set4ac7ground@ne( *olor@35,45,4AA;

b13.setForeground@ne( *olor@2""52""52""AA; b13.setFont@ne( Font@PArialP5Font.4!)%51"AA; b13.set4ac7ground@ne( *olor@35,45,4AA;VH

b3.addAction)istener@t isA; b4.addAction)istener@t isA; HHb".addAction)istener@t isA; b0.addAction)istener@t isA;

HHb13.addAction)istener@t isA; HHb1.addAction)istener@t isA;

c1.add@lA; c1.add@l2A; c1.add@l3A;

HH

c1.add@b"A; c1.add@b4A; c1.add@b3A; c1.add@b0A; HH c1.add@b1A; HH c1.add@b13A;

setSi:e@"335,33A; setDisible@trueA;

[ public 6oid action'er$ormed@ActionE6ent aeA W i$@ae.getSource@AXXb"A W Insert1 dXne( Insert1@A; d.setSi:e@/335,33A; d.setDisible@trueA; [ i$@ae.getSource@AXXb3A W System.out.println@PFace Framing page openingPA; $aceId&ain1 $1Xne( $aceId&ain1@A; $1.setSi:e@0335033A; $1.setDisible@trueA;

i$@ae.getSource@AXXb0A

W %ra( d1Xne( %ra(@A; d1.setSi:e@,335433A; d1.setDisible@trueA;

i$@ae.getSource@AXXb1A W &atc ingImg miXne( &atc ingImg@A; mi.setSi:e@/335,33A; mi.setDisible@trueA;

i$@ae.getSource@AXXb13A W %ata$rom!p daXne( %ata$rom!p@A; da.setSi:e@,335433A; da.setDisible@trueA;

i$@ae.getSource@AXXb4A W Retr r1Xne( Retr@A; r1.setSi:e@,335,33A; r1.setDisible@trueA; [

[ public static 6oid main@String argsNOA W !perator opX ne( !perator@A; [[

TESTIN8

So$t(are testing is a critical element o$ so$t(are #uality assurance and represents t e ultimate re6ie(s o$ speci$ication5 design and coding. Testing represents an interesting anomaly $or t e so$t(are. %uring earlier de$inition and de6elopment p ases5 it (as attempted to build so$t(are $rom an abstract concept to a tangible implementation. 8o system is error $ree because it is so till t e next error crops up during any p ase o$ t e de6elopment or usage o$ t e product. A sincere e$$ort o(e6er needs to be put to bring out a product t at is satis$actory. T e testing p ase in6ol6es t e testing o$ de6elopment system using 6arious data. 'reparation o$ t e test data plays a 6ital role in system testing. A$ter preparing t e test data5 t e system under study (as tested using t ose data. = ile testing t e system5 by using t e test data5 errors (ere $ound and corrected by using t e $ollo(ing testing steps and corrections (ere also noted $or $uture use. T us5 a series o$ testing is per$ormed on t e proposed system be$ore t e system is ready $or implementation. T e 6arious types o$ testing done on t e system are> Unit testin(: Integration testing Dalidation testing .nit testing !utput testing .ser Acceptance testing

.nit testing $ocuses on 6eri$ication e$$ort on t e smallest unit o$ so$t(are design module. .sing t e unit test plans prepared in t e design p ase o$ t e system de6elopment as a guide5 important control pat s are tested to unco6er errors (it in t e boundary o$ t e modules. T e inter$aces o$ t e modules are tested to ensure proper $lo( o$ in$ormation into and out o$ t e modules under consideration boundary conditions (ere c ec7ed. All independent pat s (ere exercised to ensure t at all statements in t e module andling pat s (ere tested. Eac unit is t oroug ly tested to c ec7 i$ it mig t $ail in any possible a6e been executed at least once and all error-

situation. T is testing is carried during t e programming state itsel$. At t e end o$ t is testing p ase eac module is $ound to be a6e an ad6erse e$$ect (or7ing

satis$actorily5 as regard to t e expected output $rom t e module. Inte(ration Testin(: %ata can be lost across an inter$ace5 one module can on anot er; sub$unctions ( en combined may not produce t e desired ma9or $unction> global data structures can present problems. Integration testing is a systematic tec ni#ue $or t e program structure ( ile at t e same time concluding tests to unco6er errors associated (it inter$ace. All modules are combined in t is testing step. T en t e o$ t e module is integrated and tested

entire program is tested as a ( ole. Eac

separately and later all modules are tested toget er $or sometime to ensure t e system as a ( ole (or7s (ell (it out any errors. "alidation Testin(:

At t e culmination o$ t e integration testing5 t e so$t(are is completely assembled as a pac7age5 inter$acing errors a6e been unco6ered and corrected5

and a $inal series o$ so$t(are 6alidation testing began. +ere (e test i$ t e system $unctions in a manner t at can be reasonably expected by t e customer. T e system is tested against t e system re#uirement speci$ication. O-t)-t Testin(: A$ter per$orming 6alidation testing5 t e next p ase is output testing o$ t e proposed system5 since no system can be use$ul i$ it does not produce t e desired output in t e speci$ied $ormat. T e output generated or displayed by t e system under consideration is tested by as7ing t e user about t e $ormat re#uired by t em5 ere5 t e output $ormat is considered in t(o (ays> !ne is on t e screen and t e ot er is on t e printed $orm. 4eta testing is carried output by t e client5 and minor errors t at a6e been disco6ered by t e client are recti$ied to impro6e t e user

$riendliness o$ t e system.

Object-Oriented Testin!
T e o6erall ob9ecti6es o$ t e ob9ect-oriented testing K to $ind t e maximum number o$ errors (it a minimum amount e$$ort K is identical to t e to t e ob9ecti6e o$ con6entional so$t(are testing. 4ut t e strategy and tactics $or !! testing di$$er signi$icantly. T e 6ie( o$ testing broadens to include t e re6ie( o$ bot t e analysis and design model. In addition5 t e $ocus o$ testing mo6es a(ay $rom t e procedural component and to(ard t e class. 4ecause t e !! analysis and design models and t e resulting source code are semantically coupled5 testing begins during t ese engineering acti6ities. For t is reason5 a re6ie( o$ *R*5 ob9ect relations ips5 and ob9ect be a6ior models can be 6ie(ed as $irst stage testing. As a result o$ t is $irst stage testing5 (e encountered $e( problems in !!A done at analysis time. =e (it a6e gone bac7 and remodeled

ne( errorless classes and t eir relations ips. T e documented model is t e

re6ised model o$ earlier analysis model. !nce !!' as been accomplis ed5 unit testing is applied $or eac class. *lass testing uses a 6ariety o$ met ods> $ault-based5 random5 and partition test met ods. Eac o$ t ose met ods exercises t e operations encapsulated by t e class. Test

se#uences are designed to ensure t at rele6ant operations are exercised. T e state o$ t e class5 represented by t e 6alues o$ its attributes5 is examined to determine i$ errors exist. Integration test can be accomplis ed using a t read-based or use-based strategy. T read-based strategy integrates t e set o$ classes t at collaborate to respond to one input or e6ent. .se-based testing constructs t e system in layers5

beginning (it

t ose classes t at do not ma7e use o$ ser6er classes. Integration

test case design met ods can also ma7e use o$ random and partition tests. In addition5 scenario based testing and t e tests deri6ed $rom be a6ioral models can be used to test a class and its collaborators. A test se#uence trac7s t e $lo( o$ operations across class collaborations. !! system 6alidation testing is blac7 box oriented and can be accomplis ed by applying t e same blac7 box met ods 7no(n $or con6entional so$t(are. +o(e6er scenario based testing dominates t e 6alidation o$ !! systems5 ma7ing t e use case a primarily dri6er $or 6alidation testing. =e mainly concentrated on scenario based testing strategy. Some o$ t e test cases $or scenario based testing are gi6en belo(.

Test case ?1
.se *ase> 4ac7ground> System E6ent Se#uence> 1. Select $ile to do(n load in remote tree panel. 2. Rig t clic7 and t en clic7 do(nload. do(nload a $ile .ser (ants to do(nload a $ile $rom *riminal Face Identi$ication

Test case ?3
.se *ase > upload a $ile .ser (ants to upload a $ile to t e ser6er $rom client.

4ac7ground >

E6ent Se#uence> 1. *lic7 $ile in local $ile 6ie( tree. 2. Rig t clic7 and select upload.

Test case ?4
.se *ase > Remo6e $ile on remote ser6er .ser (ants to delete a $ile on t e ser6er..

4ac7ground > E6ent Se#uence>

1. Select $ile on remote $ile 6ie( tree panel. 2. Rig t clic7 and select I%elete?.

Test case ?5
.se *ase > %isconnect to ser6er .ser (ants to close t e session.

4ac7ground > E6ent Se#uence> 1.

*lic7 disconnect option in menu (ere

In t is (ay (e tested using di$$erent test cases t at $ound lot o$ errors ( ic corrected by recoding o$ t at related procedures.

SCREENS

FUTURE EN ANCE%ENTS

T e Future en ancements o$ t is pro9ect include t e $ollo(ing> T e criminal p otos may be o$ any si:e. 4y selecting any one cropped part o$ t e criminal5 (e can get t e $ull image o$ t e criminals along (it details. 8e( $ace constructed by di$$erent cropped parts can be sa6ed.

BIB$IO8RAP &

!a*a <S+in( @ X%$=: Ea6a in a 8ut S ell .sing Ea6a2 'lat$orm T e *omplete Re$erence Ea6a 1.2 *ore Ea6a !?Rielly Eosep =eber +erbert Sc ildt Lennet 'aul

System De*elo)ment: Fundamentals !$ System *oncepts System Analysis And %esign !b9ect !riented &odeling And %esign Eerry Fit: Jerald Elias &. A(ad Eames Rumaba