UNIVERSITATEA DIN A CORUÑA

FACULTATEA DE INFORMATICĂ
Departamentul de Tehnologii ale Informației și Comunicațiilor
PROIECT DE FINAL DE CARIERĂ ÎN INGINERIE TEHNICĂ ÎN
INFORMATICĂ DE GESTIUNE

Sistem de gestionare a amprentelor digitale în

format digital

Autor: José Antonio Orgueira Pérez

Tutor: Antonino Santos del Riego
A Coruña, ianuarie 2003
Mulțumiri

Părinț ilor mei, familiei, prietenilor ș i colegilor de facultate pentru că fără ei nimic
ar fi posibil.

Tuturor celor care mi-au oferit ajutorul lor dezinteresat pe forumurile de Internet
consultati.

Unui Nino, pentru tot.

Tuturor, mulț umesc.

Sistem de gestionare a amprentelor

dactilare în format digital

Resumen

Acest proiect reprezintă o abordare a domeniului biometriilor. În concret, ne

ne vom concentra pe recunoa ș terea amprentelor digitale, dezvoltând un sistem
ce, pe suportul unei baze de date, permite o gestionare a entităț ilor
involvate într-o arhitectură client-server.

Sistemul va face autentificarea utilizatorilor prin intermediul unui dispozitiv cititor de

amprente digitale. În procesul de autentificare se utilizează algoritmul de
verificarea ș ablonurilor bazate pe obț inerea minuciilor.

Atât gestionarea bazei de date, cât ș i verificările utilizatorilor înregistraț i

vor fi orientate spre WEB, putându-se realiza oricare dintre sarcini prin intermediul
un navigator.

Cuvinte cheie

Biometría, Autenticación, Reconocimiento, Huellas dactilares, Web, Tomcat,

Apache, Java, JSP, Javabeans, MySQL

3
Sistem de gestionare a amprentelor Indice
dactilare în format digital

INDICE

1. INTRODUCERE 6

2. DOMENIU DE APLICARE. AUTENTIFICARE Ș I AMPRENTE DIGITALE

2.1. Autentificarea utilizatorilor 9

2.2. Autentificare biometrică 11
2.3. Amprente digitale 15

[Link] ARTEI

3.1. Amprenta digitală prin ultrasunete 20

3.2. Degetele de gelatină ale lui Matsumoto 21
3.3. Algoritm de amprente 23

[Link]

4.1. Modelare 36
4.2. Limbaje ș i instrumente 53
4.3. Proiectare ș i dezvoltare 74

5. VALIDAREA SISTEMULUI 111

6. CONCLUZII 113

4
Sistem de gestionare a amprentei Indice
dactilare în format digital

ANEXA I: Manualul Administratorului 114

ANEXA II: Comanda de creare a tabelelor 127

BIBLIOGRAFIE 129

DIRECCIONES WEB 131

ÎNDICE DE FIGURI 132

INDICE DE TABELE 134

5
 Introducere

1. INTRODUCCIÓN

În domeniul tehnologiilor de securitate, una dintre problemele

fundamentale pentru a rezolva este necesitatea de a autentifica în mod sigur identitatea
de persoanele care pretind să acceseze un anumit serviciu sau spaț iu fizic. De
în acest mod, apare biometria, cunoscută ș i sub denumirea de tehnici de identificare
biometrică, cu scopul de a rezolva această problemă pe baza caracteristicilor
proprii fiecărei persoane, precum vocea, amprenta digitală, faț a, etc.

Aceste tehnici de identificare biometrică, în faț a altor forme de autentificare

personal ca utilizarea cardurilor sau a PIN-urilor (Numărul de Identificare Personală), sau numărul

de identificare personală, cum ar fi cel folosit în bancomate, au avantajul de

că modelele nu pot fi pierdute sau furate, nici nu pot fi folosite de alț ii
indivizi în cazul în care ajung să aibă acces la cardul nostru personal ș i, sau,
PIN.

Trebuie avut în vedere că o mare parte din sistemele de autentificare actuale sunt
bazate exclusiv pe utilizarea unui card personal ș i, sau, un PIN, cu ale sale
probleme de securitate consecvente.

Indiferent de tehnica selectată pentru o anumită aplicaț ie, va trebui să

pondera în fiecare caz restricț iile sau particularităț ile pe care le pot avea fiecare.
de la tehnicilor, în faț a gradului de siguranț ă suplimentar pe care îl obț inem ș i de care
anteriormente nu dispuneam. Aceste caracteristici sunt date în principal de
următoareleaspecte:

ü Necesitatea unui dispozitiv de achiziț ie specific (cititor de amprente)

dactilar, microfon, cameră, etc.) acolo unde se află utilizatorul.

6
 Introducere

ü Posibilăvariabilitateîntimpamodeluluideidentificat(afonii,
cataruri în voce, utilizarea ochelarilor/mustăț ii/bererii pe faț ă, etc.).

ü Probabilitatea de eroare individuală a fiecărei tehnici (în funcț ie de

tehnicaaleasă).

ü Acceptarea de către utilizator a fiecărei tehnici, în funcț ie de

ș isuntsaunutehniciintruzive,confortabile,caresămenț ină(saucelpuț insă

parezca) intimitatea, uș or de folosit, etc.

În acest fel, în func ț ie de situa ț ia în care trebuie să realizăm o

autentificare sigură a utilizatorului, se va căuta care este tehnica (sau combinaț ia de
tehnica) biometrică cea mai adecvată în func ț ie de cei patru parametri
fundamentelemenț ionateanterior.

În acest context, scopul acestui proiect este dezvoltarea unui sistem de

gestionarea amprentelor digitale. Suntem interesa ț i de faptul că
utilizatorii care solicită pot face parte din baza noastră de date, pentru
ce lucru le va permite să ne trimită datele ș i imaginile digitalizate ale lor
urme, putând să ne trimită un număr variabil de acestea, câte una pentru fiecare dintre
deget
După solicitare, administratorul sistemului se va ocupa de gestionare
delainformaț iagenerată(inserț ii,ș tergeri,modificări).

În cele din urmă, sistemul va dispune de posibilitatea autentificării unui utilizator

dado de alta previamente, unde se va captura amprenta acestei persoane ș i se
va compara cu cea din baza de date trimisă anterior.
Trebuie, pentru aceasta, să dezvoltăm o bază de date, cu datele de interes asupra
persoana,precumș icuimaginiledigitalizatealeamprentelorsale.

7
 Introducere

Întregul proces se va desfăș ura prin Internet, pe o arhitectură

client-server.

Obiectivele principale ale proiectului sunt:

ü Design ș i dezvoltare a unei baze de date cu informa ț ii despre

utilizatoriș iimaginialeamprentelorlordigitale.

ü Proiectareaș idezvoltareasistemuluidegestionare.

ü Integrareaunuialgoritmdeautentificarepebazaamprenteifurnizate.

ü Validareasistemului.

8
 Domeniul aplicației

2. Domeniu de aplicare. Amprente digitale în

format digital

2.1 Autentificarea utilizatorilor

În prezent, unul dintre cerinț ele fundamentale ale sistemelor informatice este
mecanismele de securitate care trebuie să includă cel puț in un sistem care să permită
identificarea entităț ilor (elemente active ale sistemului, în general utilizatori) care
intenț ionează să acceseze obiectele (elemente pasive, cum ar fi fiș ierele sau capacitatea de

cómputo), prin procese atât de simple precum o parolă sau atât de complexe
ca un dispozitiv de analiză a patternurilor retiniene.

Sistemele pe care le folosim în mod obişnuit pentru a identifica o persoană, cum ar fi

aspectul fizic sau modul de a vorbi sunt prea complexe pentru un computer;
obiectivul sistemelor de identificare a utilizatorilor nu este de obicei de a identifica o
persoană, ci să autentifici că acea persoană este cine spune că este cu adevărat. Deș i
cu siguran ț ă ambele termeni ne vor părea echivalente, pentru un computer
există o mare diferen ț ă între ei: să ne imaginăm un sistem de identificare
biometric pe baza recunoaș terii retinei; o persoană s-ar uita prin
dispozitiv cititor, iar sistemul ar fi capabil să decidă dacă este un utilizator valid, ș i în acel
cazuldeadeterminadesprecineestevorba;aceastaesteidentificarea.

Cu toate acestea, ceea ce face de obicei utilizatorul este să-ș i introducă identitatea (un
număr, un nume de utilizator, etc.) în plus faț ă de a-ș i arăta retinele în faț a cititorului. În

în acest caz, sistemul nu trebuie să identifice acea persoană, ci să o autentifice:

verificaț i parametrii retinei pe care o citiț i cu cei înregistraț i într-o
bază de date ca identificatori ai utilizatorului. În acest caz, se reduce

9
 Domeniul aplicației

problema unei populaț ii potenț ial foarte ridicate pentru un grup de utilizatori mai
reducereagrupuluideutilizatoriaisistemuluicarenecesităautentificare.

Metodele de autentificare sunt de obicei împărț ite în trei mari categorii, în funcț ie de
de ceea ce folosesc pentru verificarea identităț ii: (a) ceva ce utilizatorul ș tie, (b)
ceva ce acesta posedă ș i (c) o caracteristică fizică a utilizatorului sau un act involuntar
această ultimă categorie este cunoscută sub denumirea de autentificare
biometrică.

Este u ș or de identificat exemple pentru fiecare dintre aceste tipuri de autentificare: un

parolele sunt ceva ce utilizatorul cunoa ș te ș i restul oamenilor nu, un card de

identitatea este ceva ce utilizatorul poartă cu sine, amprenta digitală este o caracteristică
fizicautilizatorului.

Desigur, un sistem de autentificare poate ș i trebuie, pentru a- ș i cre ș te

fiabilitate, combinând mecanisme de diferite tipuri, ca în cazul unei cartele de
credit unit cu PIN-ul bancomatelor sau cu cel al unui dispozitiv generator
de chei pentru utilizarea parolelor unice.

Orice sistem de identificare (de ș i a ș a se numesc, să ne amintim că)

în realitate, sunt sisteme de autentificare) trebuie să de ț ină anumite
caracteristici pentru a fi viabil; evident, trebuie să fie fiabil cu o probabilitate foarte
elevată, economic viabilă pentru organizaț ie ș i trebuie să suporte cu succes
anumite tipuri de atacuri, de exemplu, atacuri prin forț ă brută.

În plus faț ă de aceste caracteristici, există una care nu este tehnică, ci umană, dar poate că
mai important: un sistem de autentificare trebuie să fie acceptat de utilizatori, care
vor fi în cele din urmă cei care îl vor folosi. De exemplu, să ne imaginăm un potenț ial
sistem de identificare pentru accesarea resurselor Universităț ii, constând
pe un dispozitiv care ar fi capabil să efectueze o analiză de sânge unui utilizator ș i astfel

10
 Domeniul aplicației

verifică dacă este cine spune că este; cu siguranț ă ar fi ieftin ș i foarte fiabil, dar
nimeni nu ar accepta să dea puț in sânge de fiecare dată când ar dori să-ș i consulte emailul.

2.2. Autentificare biometrică

Cu toate acestea, importan ț a criptologiei în oricare dintre sistemele de

identificarea utilizatorilor, există o altă clasă de sisteme în care aceasta nu se aplică
ș tiinț a, sau cel puț in aplicarea sa este secundară. Mai mult, pare că într-un viitor nu
foarte îndepărtate acestea vor fi sistemele care se vor impune în majoritatea
situaț ii în care este necesar să se autentifice un utilizator. În general sunt mai
prietenoase pentru utilizator, nu va trebui să-ș i amintească parole sau numere de
identificarea complexelor ș i, aș a cum se spune, utilizatorul se poate uita de card
de identificare acasă, dar nu va uita niciodată de mâna sau de ochiul său, ș i sunt mult
mai greu de falsificat decât o simplă parolă sau un card magnetic. Cele
principalele motive pentru care nu au fost impuse deja în zilele noastre sunt ridicate
pre ț , dincolo de capacitatea multor organiza ț ii, ș i dificultatea de
întreț inere.

Aceste sisteme sunt denumite biometrice, bazate pe caracteristici fizice

al utilizatorului de identificat. Recunoaș terea formelor, inteligenț a artificială ș i
învăț area sunt ramurile informaticii care joacă cel mai important rol
în sistemele de identificare biometrică; criptologia se limitează aici la o utilizare
secundar, cum ar fi criptarea unei baze de date de modele de retină, sau
transmiterea unei amprente digitale între un dispozitiv de analiză ș i o bază de date
date.

11
 Domeniul aplicației

Autentificarea bazată pe caracteristici fizice există de când există omul ș i,

fără să ne dăm seama, este ceea ce foloseș te cel mai mult oricare dintre noi în viaț a de zi cu zi: a
În viaț ade zi cu zi, identificăm persoanele după trăsăturile feț eilor sau după voce.

În mod evident, aici agentul recunoaș terii o are uș or pentru că este o persoană, dar în
modelul aplicabil reț elelor de comunicaț ii agentul trebuie să fie un dispozitiv care,
bazându-se pe caracteristicile subiectului de identificat, gestiona ț i accesul la un
resursă determinată.

Dispozitivele biometrice au trei părț iprincipale:

ü Unmecanismautomatcareciteș teș icapteazăoimaginedigitalăsauanalogică

de la caracteristica a analiza.

ü O entitate pentru a gestiona aspecte precum compresia, stocarea sau

compararea datelor capturate cu cele înregistrate într-o bază de
date (care sunt considerate valide).

ü Ointerfaț ădeaplicaț ii.

Procesul general de autentificare urmează câț iva paș i comuni tuturor modelurilor
de autentificare biometrica: capturarea sau citirea datelor pe care utilizatorul le valideaza
prezentă, extragerea anumitor caracteristici din e ș antion (de exemplu,
minu ț ii ale unei amprente digitale), compararea acestor caracteristici cu
înregistrate într-o bază de date, ș i decizia dacă utilizatorul este valid sau nu.

12
 Domeniul aplicației

În figura 1 se arată structura clasică a Diagramei de Blocuri a unui

SistemdeRecunoaș tereBiometrică.

Obținedrae
model
BadleD
Preproc. Extracț ie
Achzțideie
dela de
date
Persoană Semnal Caracteristici
Autentificator
Incógnită Decizie
Am
gtloirde
Recunoaș tere

Figura 1. Diagrama Sistemului de Recunoaș tere Biometrică

Este în Decizie unde intră în joc în principal cele două caracteristici

bancile fiabilităț ii oricărui sistem biometric: ratele de fals respingere ș i de
acceptare falsă. Prin rata de falsă respingere (False Rejection Rate, FRR) se înț elege
probabilitatea ca sistemul de autentificare să respingă un utilizator legitim deoarece
nu este capabil să-l identifice corect ș i din cauza ratei de acceptare falsă (False
Rata de acceptare, FAR) probabilitatea ca sistemul să autentifice corect
un utilizator ilegitim; evident, o FRR mare provoacă nemulț umire în rândul
utilizatori ai sistemului, dar o FAR ridicată generează o problemă gravă de securitate,
oferind acces la o resursă personalului neautorizat.

13
 Domeniul aplicației

Pentru a determina performanț ele unui sistem biometric, se utilizează adesea rata de
rata de succes (Success Rate, SR) care răspunde unei combina ț ii a celor două factori
anterioare

SR= 1 – (FAR + FRR)

ElFARy elFRRre răspunde la parametrii invers proporț ionali, aș adar,

vor varia în funcț ie de condiț iile prestabilite de programul de identificare
biometrică. Astfel, de exemplu, dacă trebuie să foloseș ti programul într-un mediu de
maximă securitate, se va încerca ca elFARsea să fie cât mai mic posibil, deș i aceasta
acț iuneaînseamnăînmodexplicitocreș teredrasticăafactoruluiFRR.

Prin urmare, trebuie stabilit un parametru sau un prag care să permită egalizarea celor doi factori.

asigurând astfel funcț ionarea optimă a sistemului. Acest prag se

denomina rata de eroare egală (Equal Error Rate, ERR), ș i este ceea ce va determina,
în sfârș it, capacitatea de identificare a sistemului. În figura 2 se arată
relaț iespusărelaț ie.

Figura 2. Relaț ia dintre FAR, FRR ș i ERR

14
 Domeniul aplicației

2.3. Amprente digitale

Tipic, amprenta digital a unui individ a fost un model destul de bun pentru
determinarea identităț ii sale în mod inconfundabil, deoarece este acceptat că două degete
niciodată nu au amprente similare, nici măcar între Gemeni sau între degete de la aceeaș i
persoană. Prin urmare, pare evident că urmele s-ar transforma mai devreme sau mai târziu într-un
model de autentificare biometric: de la secolul trecut până în zilele noastre se
se efectuează cu succes clasificări sistematice ale amprentelor digitale în
contextul poliț ienesc, iar utilizarea acestor modele a fost unul dintre primele care s-au stabilit

ca model de autentificare biometrică.

Când un utilizator doreș te să se autentifice în faț a sistemului, îș i plasează degetul într-o zonă

determinată, zona de lectură. Aici se ia o imagine care ulterior se

normaliza printr-un sistem de oglinzi fine pentru a corecta unghiurile, ș i este din aceasta
imagine normalizată din care sistemul extrage minutii (anumite arcuri, bucle ș i
remolino de la huella) care va compara cu cele existente în baza de date.
Este important de subliniat că sistemul nu analizează amprenta în sine, ci detaliile.
concret, poziț ia relativă a fiecăreia dintre ele.

15
 Domeniul aplicației

Figura 3. Amprentă digitală cu minutii

Urmele degetelor prezintă ca trăsătură principală, prezenț a unui

set de creste sau părț i unde pielea se ridică deasupra părț ilor mai joase sau văi
existente între creste. Referitor la aceste creste se definesc două caracteristici
particulare care obedesc termenului diminuiri:

ü Final de cresta. Caracteristică definită ca punctul unde

creasta se termina brusc.

ü Bifurcarea crestei (bifurcaț ia crestei). Caracteristică definită ca

punctul în care creasta se bifurcă în două sau mai multe creste.

Aceste două caracteristici sunt definitivate în mod unic în funcț ie de localizarea lor
(coordonatele x, y în raport cu sistemul de coordonate central al imaginii) ș i de a sa
orientare(unghi)

16
 Domeniul aplicației

Este dovedit că două degete nu pot avea niciodată mai mult de opt mărun ț iș uri
comune, iar fiecare are cel puț in între 30 ș i 40 dintre acestea. În figura 3 este prezentat
o imagine a unei amprente digitale cu minuț iile sale. Dacă comparaț ia dintre
poziț iile relative ale minutelor citite cu cele stocate în baza de date sunt
corectă, se permite accesul utilizatorului, fiind refuzat evident în caz contrar.

Sistemele bazate pe recunoaș terea amprentelor sunt relativ ieftine, în

compararea cu alte biometrice, cum ar fi cele bazate pe modele de retină. Fără
embargou, au împotriva lor incapacitatea temporară de a autentifica utilizatorii care se
au putut să se rănească la deget recunoscând. O mică tăietură sau o arsură care
afecte la diverse minuni pot face sistemul inutil. De asemenea, elemente precum
murdăria de pe deget, presiunea exercitată asupra cititorului sau starea pielii pot
a provoca citiri eronate.

17
 Starea Arte

3. Starea artei

Unele aeroporturi experimentează tehnologii de securitate bazate pe

recunoaș terea irisului ș i a mâinii. Identificarea prin amprente este una dintre cele mai
extinse;faț a,celmaipuț [Link]ă,standardizarea.

A pune degetul pe un scanner, a vorbi printr-un microfon sau a privi de aproape o cameră
poate fi suficient pentru a trece controlul de securitate ș i a accesa o instalaț ie sau
sistem informatic. Tehnologia biometrică a depă ș it laboratoarele de
espionaj, loca ț ii militare ș i guvernamentale pentru a- ș i extinde aplica ț iile la
piaț a de afaceri ș i de consum.

Algunos expertos consideran que el reconocimiento del rostro puede ser la

cea mai utilă unealtă pentru identificare în aeroporturi. Camerele de securitate
înregistrează la distanț ă ș i permit compararea capturilor cu baze de date de imagini.
De fapt, unul dintre aceste sisteme a fost utilizat în ultima ediț ie a finalei de fotbal
americano, la Super Bowl, celebrată în Tampa, Florida.

Aeroporturile din San Francisco ș i New York utilizează sisteme care recunosc
geometria a mâinii angajaț ilor. Acelaș i sistem este folosit în aeroport
israelian de Tel Aviv pentru pasagerii frecvenț i ai companiilor aeriene El Al. În
Heathrow (Londra) se desfă ș oară o experien ț ă cu 2.000 de pasageri
nord-americanii de la companiile aeriene British Airways ș i Virgin Atlantic (trebuie să fie

înregistraț i ș i salvaț i irisul într-o bază de date).

În prezent, extensia masivă a acestor sisteme este frânată de lipsa de

standardelor. Prea multe sisteme proprietare. Microsoft, unul dintre fondatorii
BioAPI, standard propus în 1995 de Consorț iul Biometrics sponsorizat de

18
 Stadiul Arte

Guvernul Statelor Unite a ieș it din grupul de 60 de companii ș i agenț ii pentru a-ș i crea
tehnologia sa. Departamentul de Apărare dispune de o organizaț ie ș i un
laborator de biometrică, unde testează utilitatea celor peste 600 de produse
existente pe pia ț ă. Departamentul de Energie dezvoltă un scanner
holografic care va analiza, prin intermediul undelor radio ș i în trei dimensiuni, la
pasageri pentru a verifica dacă ascund arme.

Industria este concentrată pe sistemele de identificare prin amprente. În general,

sunt cei mai economici; cei mai ieftini peste 120 €.

Experț ii consideră că pentru a nu încălca intimitatea, una dintre cele mai bune
opț iunile sunt utilizarea sistemelor hibride care stochează datele biometrice pe carduri
infrastructuri inteligente ș i infrastructuri de cheie publică. În acest fel, se evită ca
informa ț ia se află în baze de date. În prezent, sunt în studiu
sistemecareanalizeazămirosuluman,venelemâiniisauformadeamerge.

19
 Starea Arte

3.1 Amprentă digitală prin ultrasonografie

Acest sistem funcț ionează pe bază de ultrasunete, ceea ce evită defecț ele care până acum s-au
producau cu citirea optică din cauza murdăriei pe piele sau pe dispozitivul de scanare.
Compania valicense specializată în tehnologii de securitate Mundiscan
Sistemele Electronice au prezentat recent primul sistem infailibil de
identificareprinamprentădigitalăbazatăpeultrasunete.

Este o tehnologie dezvoltată în ultima decadă, care a demonstrat o

o fiabilitate mai mare în extragerea trăsăturilor cele mai caracteristice ș i inconfundabile ale persoanelor

pentru procesele ulterioare de identificare. Acest nou sistem înlocuie ș te pe cel de

identificareprinamprentadigitalăbazatăpetehnologiaoptică.

Această ultimă tehnologie provoca probleme din cauza dificultăț ilor de citire, dacă
pielea sau dispozitivul de scanare erau murdare, lucru care provoca
în consecinț ă, o respingere pe piaț ă. Mundiscan Electronic Systems este
singura companie care, prin utilizarea ultrasunetelor, a reuș it să depăș ească acest lucru
problema impunând un metod de identificare infailibil. Tehnologia este
aplicabil la controalele clădirilor care necesită un nivel înalt de securitate, cum ar fi
aeroporturi, bănci, sedii guvernamentale, companii private, facilită ț i
militarisauînchisori.

Sistemul biometric prin ultrasunete constă în trimiterea de unde de diferite

frecvenț ele care se reflectă împotriva bazei amprentei ș i a dispozitivului de scanare,
penetrând orice fel de murdărie găsită pe degete, cum ar fi grăsimea, praful sau
petice de cerneală. În acest fel, se obț ine o imagine fără erori a crestelor ș i
văile degetului scanat, obț inând o mare precizie în capturarea
imaginecarevafacilitaproceseledeidentificareulterioare.

20
 Starea artei

3.2 Degetele de gelatină ale lui Matsumoto

Recent a fost publicată o ș tire care provoacă o dezbatere

despre evaluarea biometrii: un criptograf japonez pe nume
Matsumoto a descoperit o metodă pentru a înș ela cu un "deget de gelatină" la 11
senzori biometrici în 80% din încercări.

Studiul se bazează pe obț inerea unei amprente artificiale care să înș ele sistemele de
autentificare. Profesorul Matsumoto arată cum să ob ț ii artificial o
amprentacarepoateservicaoriginală.

Afaceoamprentăartificialădirectdintr-oamprentăreală:

ü Materiale: Plastic modelabil, foaie de gelatină solidă

ü Cum se face o matriț ă: Puneț i plasticul în apă caldă pentru a-l îmbuna.
presionează degetul împotriva lui, obț inând amprenta.

ü Pregătirea materialului: Amestecaț i gelatina cu un lichid într-o

proporț ia de 50 %, adăugaț i apă clocotită (30cc) la gelatina solidă (30g)
într-osticlăș ialeamesteca.

ü Cum să faci o amprentă falsă: Toarnă lichidul în matri ț ă, introduce-l într-un

frigider pentru a răci ș ise obț ineamprenta.

Matsumoto a realizat testul pe 11 dispozitive biometrice de pe piaț ă. Nu

să uităm că există dispozitive cu biosenzor care garantează că cu un deget de
gelatinanuvaputearealizaintruziunea.

21
 Starea artei

În funcț ie de nivelul de securitate dorit, se poate opta pentru o soluț ie de

securitate mai eficientă, de exemplu, utilizarea biosenzorilor, camere de supraveghere,
combinatiidemaimultebiometrice,combinatiicucarduriinteligentesiPinPad,etc.

La fel ca în orice sistem de securitate, există vulnerabilită ț i ș i

soluț ii pentru acestea. Pentru prima dată se acordă o inteligenț ă unei
măș inile noastre prin intermediul recunoaș terii precise a utilizatorului care interacț ionează
cu sistemul, iar acest lucru îl putem obț inedoar cu recunoaș terebiometrică.

Dedo de gelatina a provocat un avans în rândul unor producători ș i pentru alț ii,
mai prevăzători, le-a confirmat ceva ce putea să se întâmple.

În orice caz, toț i aceș tia continuă zilnic să efectueze teste de alt tip de posibile.
vulnerabilită ț i pentru a crea o evolu ț ie ș i o apropiere asintotică de punct
limite de securitate de 100%.

22
 Starea artei

3.3 Algoritmi de amprente

Autentificarea înseamnă a verifica dacă un individ este cine spune că este. Algoritmul de
autentificarea care este utilizată în prezentul proiect este formată din două blocuri: în
în primul rând se extrag detaliile caracteristice ale amprentei „actuale” a utilizatorului
ceea ce se va autentifica (algoritmul de extragere a minutelor) ș i, în al doilea rând, se
compară aceste minuscule caracteristici ale amprentelor tale cu minusculele stocate
în baza de date sub formă de „ș ablon” (algoritm de comparare a minutelor).

Când vorbim despre amprenta „actuală”, ne referim la amprenta situată pe

lector de amprente digitale (de asemenea, amprentă „în viaț ă”), în timp ce „ș ablonul” se
corespunde cu caracteristicile extrase dintr-o amprentă anterior.
în mod normal pentru a fi stocată într-o bază de date.

Se spune că un utilizator a fost autentificat dacă caracteristicile extrase din amprentă

„actual” coincidă cu cele ale „ș ablonului” într-o limită de toleranț ă pentru
algoritm de comparaț ie a denumirilor.

3.3.1 Algoritm de extragere a minuțiilor

Una dintre cele mai importante sarcini într-un sistem de recunoaș tere a amprentelor este
extracț ia detaliilor dintr-o imagine capturată a unei amprente. Din cauza
imperfecț iuni ale imaginii obț inute, în unele cazuri algoritmul de extragere
se pot omite unele detalii, iar în altele pot fi adăugate detalii false. Cele
imperfec ț iunile imaginii pot genera de asemenea erori în determinarea
coordonatele fiecărei minute ș i orientarea lor relativă în imagine.

23
 Starea artei

To ț i ace ș ti factori contribuie la diminuare fiabilitatea sistemului de

recunoaș tere, având în vedere că recunoaș terea amprentelor digitale se bazează pe
compararea, în limitele unor toleranț e, a modelului biometric sau a setului
demenț i extrase, achiziț ionat "în direct" ș i stocat.

În continuare vom descrie în profunzime fiecare dintre fazele acestui algoritm.

ș i ceea ce se obț ine în acestea.

[Link] Normalizarea imaginii

Obiectivul acestei etape este de a diminua intervalul de variaț ie a nuanț elor de gri între văi ș i

lascrestasde la imagen pentru a facilita procesul în etapele următoare.

Figura 4. (a)Huella original (b) Huella normalizada

[Link] Calculul câmpului orientare

Câmpul orientare reprezintă orientarea locală a crestei pe care o conț ine.

amprentă. Pentru a o estima, imaginea este împărț ită în blocuri de 16x16 pixeli ș i se calculează
înclina ț ia pentru fiecare pixel, în coordonate x ș i y. Din cauza încărcăturii

24
 Starea artei

computational al procesului de recunoaș tere, este suficient să aplici o mască de

3x3pixelipentrucalcululînclinaț ieifiecăruipixel.

Figura 5. (a) Huella orientada (b) Campos realineados

Unghiul de orientare se calculează din informaț iile despre înclinaț ie.

Frecvent, în unele blocuri, unghiul de orientare nu este calculat
corect din cauza zgomotelor ș i daunelor în văile ș i crestele imaginii
capturată. Deoarece nu pot exista varia ț ii semnificative ale unghiului între
blocuri adiacente, se aplică un nou filtru „spaț ial” de 5x5 pixeli la câmp
orientare estimată pentru a reordona corect toate segmentele. Figura
5(a) arată câmpul de orientare obț inut din calculul înclinării. La
figura 5(b) arată câmpurile realiniate după aplicarea filtrelor „spatial”.

[Link] Selección a zonei de interes

Datorită faptului că imaginea conț ine „zgomot” de fond, algoritmul poate genera
minucias în afara zonei ocupate de amprenta. Pentru a evita această problemă, se
selectează zona de imagine, definită de toate blocurile de 16x16, în care
există o variaț ie mare a nivelului de griuri în direcț ia normală a crestelor
existente (câmpul de orientare normal al crestelor a fost calculat

25
 Starea artei

previamente). După aceasta, zona imaginii cu zgomot, care va fi exclusă în

urmează etapele, se defineș te prin variaț ii scăzute în toate direcț iile. În
figura 6 se arată variaț iile unei amprente ș i regiunea de interes obț inută la
începând de aici.

Figura 6. (a) Variaciones de la huella (b) Región importante

[Link] Extracția crestelor

Pentru a decide dacă un pixel aparț ine sau nu unei creste date, este necesar să filtrăm
imaginea amprentei cu două măș ti adaptabile, ambele capabile să crească
nivel de griș în direcț ia normală a crestei. Orientarea măș tii se
adaptează fiecare bloc de 16x16 pixeli, în func ț ie de unghiurile ob ț inute din
câmp de orientare realiniate ale figurii 5(b).

Ș i dacă nivelul de gri al unui pixel depăș eș te un prag în cele două imagini filtrate, se
consideră că pixelul aparț ine crestei; altfel se atribuie unui vale,
producând o imagine binară a amprentei. Dimensiunile măș tii sunt
LxLș i sunt definite prin ecuaț iile date în (1) ș i (2).

26
 Starea actuală a artei

ì 1 æu-u
-ç
0 ö2
÷

h(u,v)=
ï
í ×e è d ø
, si :u0=E[(vc-v )ctg(q ) +uc]
1 2Pd
ï 0 , în alt caz
î

ì 1 æv-v
-ç 0 ö
÷
2

h(u,v)=
ï
í 2Pd
×e è d ø
, si :v0 =E[uc(-u tgq+v
) c(] )
2
ï 0 în alt caz
î
u,vÎ L[,1 ]

unde se află coordonatele unui pixel în mască; (uc, v ) este centrul dec la
masca;q, este unghiul de orientare a crestei în fiecare bloc al imaginii, yd,
este un parametru pentru a ajusta funcț ia mascare la lăț imea crestei. Figura 7(a)
arată imaginea filtrată cu una dintre măș tile „spaț iale”. Figura 7(b)
reprezintă imaginea binară obț inută după aplicarea unui prag, producând
borduri de creste netede.

Figura 7. (a) Imagine filtrată (b) Imagine binară obț inută

27
 Starea artei

[Link] Profilarea crestelor

Pentru a simplifica procesul în etapele următoare, se filtrează imaginea pentru a profila

raza simplă a urmelor ș i eliminarea petelor din anumite zone. Pentru a realiza acest lucru,
se extrag mai întâi componentele de frecvenț ă joasă ș i apoi se elimină
la imaginea originală, furnizând componentele de înaltă frecvenț ă necesare
pentru a profila crestele, după cum se deduce din:

p[u,v] =f [u,v ] + l [ =f]

×fHu,v [u,v ] + l ×( f [u,v] -fL[u,v])

unde p[u,v], este rezultatul profilării imaginii; f[u,v], este imaginea binară;
fH[u,v] y fL[u,v] sunt, respectiv, imaginile de frecvenț ă înaltă ș i frecvenț ă joasă; ș i
un factor(l>0), care determină gradul de profilare. În figura 8(a) se arată
rezultatul amprentei după aplicarea primului filtru. Se poate aplica un
filtru nou pentru eliminarea crestelor false cauzate de petele din imagine. În acest
se utilizează o mască „spaț ială” capabilă să îș i adapteze orientarea localmente la
orientarea crestei.

Figura 8 . (a) Imagine după primul filtru profilator (b) Imagine

după al doilea filtru profilator cu mască spatială

28
 Starea artei

[Link] Simplificare

În acest pas se aplică două algoritmi consecutivi paraleli de simplificare, pentru

reducerea la un singur pixel a lă ț imii crestelor în imaginea binară. Aceste
operaț iunile sunt necesare pentru a simplifica următorul analiză structurală a
imaginepentruextragereadetaliiloramprentei.

Simplificarea trebuie efectuată fără a modifica structura originală a crestelor

de la imagine. În timpul acestui proces, algoritmul nu poate calcula gre ș it
începuturi,sfârș ituriș i,saubifurcaț iialecrestei,nicicrestelenusepotrupe.

[Link] Eliminarea imperfecțiunilor

După simplificare, în func ț ie de calitatea imaginii,

imperfecț iunile structurale ale amprentei originale rămân într-un anumit grad.
Aceasta implică creste rupturi, creste false ș i goluri; aș a că, este necesar să aplici un
algoritm pentru a elimina toate liniile care nu corespund acrestasy un
algoritm pentru a lega muchiile rute. Figura 9(a) arată imaginea subț iată
ob ț inută odată ce algoritmul de sub ț iere ș i eliminare a fost aplicat
imperfecț iuni.

Figura 9. (a) Imagine după simplificare ș i eliminarea imperfecț iunilor

(b) Patron de minucias după procesul de eliminare a seturilor

29
 Starea artei

[Link] Extracția deminuții

În ultima etapă, se extrag detaliile imaginii simplificate, obț inându-se

model biometric al amprentei (ș ablon). Acest proces implică determinarea:
(i) ș i un pixel aparț ine sau nu unei creste, (ii) dacă da, dacă este o bifurcaț ie,
început sau final decrestaobtenind astfel un grup de candidaț i aminunț ii. A
continuare, toate punctele de la marginea zonei de interes sunt ș terse. Atunci,
deoarece densitatea minutelor pe unitate de suprafaț ă nu poate depăș i un anumit
valoare, toate seturile de puncte candidate a căror densitate depăș eș te această valoare sunt
înlocuite de o simplă minucie localizată în centrul ansamblului. În figura
9(b) se arată modelul diminuărilor rezultate.

Odată ce procesul de extragere a detaliilor a fost finalizat, planifica conț ine între
70 ș i 80 de minucii. În figura 10 se arată modelul de minucii obț inut
suprapuspesteimagineaamprenteinormalizate:

Figura 10. Patrón de minucias

30
 Stadiul artei

3.3.2. Algoritm de comparare a demonetizărilor

Prin împerechere se determină dacă două amprente sunt de la acelaș i deget sau nu. Cele două
caracteristicile folosite în potrivirea amprentelor sunt capetele ș i
bifurcaț iilecrestelor (minuț ii).

În continuare, se explică în detaliu fiecare dintre etapele algoritmului de

comparaț iededetaliu:

Pentru fiecare cadaminuciă detectată, se stochează următorii parametri:

ü Coordonatele x ș i y ale laminuciei.

ü Orientaredefinităcaorientarealocalăacresteiasociate.

ü Tipuldeminuț ia,carepoatefifinalulcresteibifurcării.

ü Lacrestaasociada.

Pentru compararea detaliilor se vor utiliza coordonatele polare ale acestora.

[Link] Alinierea setului de minuscule

Ș i notăm prin P mulț imea M de minuni în imaginea ș ablonului avem că:

P= ((x ,y ,q
1
P
1
P
1
P
) ,..., (x
T P
M,yMP,qMP )T
)
ș i numind Q setul de N detalii din imaginea de „intrare” (cea care va fi
comparăcuimagineaș ablon)avem:

31
 Starea Artei

Q= ((x 1 ,y1Întrebare),q,...,
Întrebare T
1
Q
(Nxer,qNabÎe,yrNQtnÎ )
T
)
Pentru fiecare nimiceu(1££iM)yQ(1£j£N)
j în setul de măruntisuri
imaginea de "intrare" ș i a ș ablonului, denotăm rotate[i][j] ca unghiul de
rotación entre la imagen de “entrada” y la plantilla, tomando P y Q como el puntoeu j

de referinț ă a imaginii. Dacă putem lua P ș i Q ca un paireude minuscule,

j atunci
i Qjsunt egale într-un anumit grad rotate[i][j], care
crestasa asociată de P ș eu
vom presupune un val între 0 ș i 360, în alt caz vom pune rotate[i][j] ca 400
pentru a reprezenta faptul că Peuy Qjnu se coresponde cu o pereche de diminuiri.

Figura 11. Alinearea crestii de intrare ș i a crestii ș ablon

Si Peuy Qjnu sunt de acelaș i tip, se atribuie 400 la rotate[i][j]. Pe de altă parte
denotăm prin R ș i r creș terile care aparț in detaliilor P ș i Q. Se eu j

compara R cu r pentru a obț ine diferenț ele dintre aceste două creste conform cu
ecuaț iaurmătoare:
1 L

Lå
Diff_dist= eu=0
R(deu)-r(deu)

32
 Starea artei

1 L
R( a eu) -r(aeu )
Lå
Diff_ang= eu= 0

Unde L este numărul de puncte înregistrate. R(deu) este distanț a de la punctul i în

crestaR a la minucia Peu. R(aeu) este unghiul între linia care leagă punctul i
despre creasta R la minuciaPeuș iorientarea minuciei P;i r(di) y r(ai )
ausemnificaț iisimilare.

SiDiff_distes mai mare decât Tdodiff_anges mai mare decât To , se pune rotatează[i][j]a
400. În alt mod, calculăm rotate[i][j] ca:

Rotate[i][j] = dir_Temp – dir_in

Dondedir_tempes la orientarea lui Peuydir_ines la orientarea lui Qj.

Pentru a alinia setul de minutii de intrare cu setul de minutii de

în coordonatele polare, ceea ce trebuie făcut este să se translocheze detaliile
imaginea de intrare ș i cele ale ș ablonului coordonatelor polare în raport cu
minucii de referin ț ă Peuy Qj,ș i apoi adăugaț i unghiul rotate[i][j] la
unghiul radial al coordonatelor polare ale fiecărei minucii de „intrare”. Adică, pentru
y q)eu,Taplicăm
unaminucia(x, eu eu următoareaecuaț ie:

ær euö çç
æ
(xi- x r ) + (x
2
eu-yr ) 2 ö
÷
ç ÷ æy -yrö ÷
ç
ç eeu÷ =tan
-1
çç eu r ÷ ÷+roti [eu][ j ]÷
çqeu÷ ç è xeu-x ø ÷
è ø ç qeu- q r ÷
ç ÷
è ø

Unde (x, yr, qr)rTeste coordonata de laminuciade referinț ă, ș i (reu,e,qeu)Teste la eu

reprezentarea minuciei în sistemul de coordonate polare (reureprezintă la

33
 Starea artei

distanț a radială, eeureprezintă unghiul radial, yqeu; reprezintă orientarea

minuciacon în ceea ce priveș te laminucia de referinț ă).

[Link] Compararea detaliilor aliniate

Paș ii algoritmului de comparaț ie sunt următorii:

1) Pentru i(1£i£M) ș i j(1£j£N), sirotate[i][j]=400, se repetă acest pas ș i se

alege alt P ș i eu
Q, altfel
j se merge la pasul 2. Dacă s-a făcut pentru toate perechile de

minucii, se merge la pasul 5.

Poner Peuy Qjcomominuciade referencia. Convertir cadaminuciaen el

set de detalii ale ș ablonului ș i set de detalii de acces la
sistem de coordonate polare în raport cu corespunzătoarea minutelor de
referinț ă prin metoda descrisă la sfârș itul secț iunii 2.1.

3) Reprezentarea detaliilor ș ablonului ș i a intrării în sistemul de

coordonate polare ca ș iruri simbolice, concatenând fiecare detaliu
în ordinea crescătoare a unghiurilor radiale:

s
Peu
= ((r ,e ,q ) ,..., (r ,e ,q ) )
1
p
1
p
1
p T
M
p p
M M
p T

( r ,e = ,q ) ,..., (r ,e ,q ) )
Întrebare Î sÎntrebare
1 eu 1 1
QT
N
Întrebare Q
N
QT
N

4) Compara ț i firele rezultante Pisy Qjspentru a găsi nivelul de

coincidenț a Peusy QjsAsignar am_score[i][j] valoarea rezultatului.
Continuaț i în pasul 1.

34
 Starea artei

5) Găsi ț i valoarea maximă dem_score[i][j] ș i folosi ț i-o ca nivel de

coincidenț a setului de demnuri de intrare ș i a ș ablonului. Dacă nivelul
de coincidencia este mai mare decât un prag, se consideră că imaginea de
„entrada” a apărut din aceeaș i amprentă ca ș i ș ablonul, dar nu se
consideră că cele două imagini provin de la degete diferite.

35
4. Metodologie

Pentru dezvoltarea proiectului, vom urma o metodologie clasică, care va include

următorii paș i:

1. Modelare. Analiza domeniului aplica ț iei.

a. Studiul actorilor sistemului

b. Studiul cazurilor de utilizare
c. Studiul claselor domeniului
d. Studiu ș i dezvoltare a bazei de date

2. Selectarea uneltelor de dezvoltare

3. Proiectarea ș i dezvoltarea aplica ț iei/aplicaț iilor

4. Validarea arhitecturii rezultate

4.1 Modelare

În primul rând, se face o analiză a problemei, utilizatorilor, cerinț elor funcț ionale,
etc. Pentru aceasta, vom folosi Limbajul Uniuni de Modelare („Unified Modeling
Limbaj”, UML de acum înainte) deoarece constituie un standard utilizat pe scară largă
în dezvoltarea software-ului.

Având în vedere că acesta va fi limbajul pe care îl vom folosi pentru a modela noastră
aplica ț ie, vom face o scurtă introducere ș i vom eviden ț ia principalele sale
caracteristici:

36
 Limbaj Unificat de Modelare

4.1.1. Limbajul Unificat de Modelare

UML este un standard pentru a scrie 'planuri' de software. UML poate fi utilizat
pentru a vizualiza, specifica ș i documenta artefactele unui sistem care implică
o cantitate mare de software.

UML este potrivit pentru a modela de la sisteme de informaț ii în companii până la

aplicaț ii distribuite bazate pe web, cum este acest caz, ș i chiar pentru sisteme
de timp real.

Este un limbaj foarte expresiv, care acoperă toate perspectivele necesare pentru a dezvolta
ș iapoiadesfăș uraastfeldesisteme.

UML este un limbaj ș i, prin urmare, se constituie ca o metodă de dezvoltare de

software. UMLeste independent de proces, deș i pentru a-l utiliza
optimal ar trebui să fie folosit într-un proces care să fie dirijat de cazurile de utilizare,
centratpearhitectură,iterativș iincremental.

O limbă oferă un vocabular ș i regulile pentru a combina cuvintele acestuia.

vocabular cu scopul de a facilita comunicarea. Limbajul de modelare
este un limbaj al cărui vocabular ș i reguli se concentrează pe prezentarea conceptuală ș i
fizicaunuisistem.

Modelarea oferă o compresie a sistemului. Niciodată nu este suficient un singur

model. Mai degrabă, pentru a înț elege orice, adesea sunt necesare multiple
modele conectate între ele, cu excepț ia sistemelor mai triviale. Pentru sisteme cu
o cantitate mare de software, se necesită un limbaj care să acopere diferitele perspective
de la arhitectura unui sistem în timp ce evoluează prin ciclul de viaț ă al
dezvoltarea software-ului.

37
 Limbajul Unificat de Modelare

Vocabularul ș i regulile unei limbi precum UML indică cum să creezi ș i să citeș ti.
modele bine formate, dar nu spun ce modele trebuie create nici când se
ar trebui să creeze. Aceasta este sarcina procesului de dezvoltare a software-ului.

UML es un lenguaje para visualizar

UML este ceva mai mult decât un simplu teanc de simboluri grafice. Mai degrabă, în spatele

fiecare simbol în notaț ia UML are o semnificaț ie bine definită. În acest fel,
un dezvoltator poate scrie un model în UML, iar alt dezvoltator, sau chiar
o altă unealtă, poate interpreta acest model fără ambiguitate.

UML este un limbaj pentru a specifica

În acest context, a specifica înseamnă a construi modele precise, nu ambigue ș i
compleț i. UML acoperă specificarea tuturor deciziilor de analiză, design ș i
implementarea care trebuie realizată la dezvoltarea ș i desfăș urarea unui sistem cu
o cantitate mare de software.

UML es un lenguaje para construir

UMLnu este un limbaj de programare vizual, dar modelele sale pot fi
a te conecta direct cu o varietate mare de limbaje de programare, printre
cei care sunt Java. Această corespondenț ă permite inginerie directă, generarea de
codpebazaunuimodelUMLîntr-unlimbajdeprogramare.

UML este un limbaj pentru documentare

O organiza ț ie de software care func ț ionează bine produce tot felul de artefacte.
în plus faț ă de codul executabil: cerinț e, arhitectură, design, cod sursă, etc.
Aceste artefacte nu sunt doar livrabilele unui proiect, ci sunt ș i critice în
control, măsurarea ș i comunicarea de care are nevoie un sistem în timpul dezvoltării ș i
după desfăș urarea sa.

38
 Limbaj Unificat de Modelare

UML acoperă toată documentaț ia arhitecturii unui sistem ș i toate cele ale sale
detalii. UML oferă, de asemenea, un limbaj pentru a exprima cerinț e ș i teste.
În cele din urmă, UML oferă un limbaj pentru a modela activită ț ile de
planificarea proiectelor ș igestionarea versiunilor.

39
 Actori ai sistemului

4.1.2. Actori ai sistemului

Sistemul nostru are două tipuri de utilizatori, numiț i actori în UML.

Utilizator Administrator

Figura 12. Actori ai sistemului

ActorAdministrator: Este este responsabil cu menț inerea datelor din baza de date.
Munca sa constă în a face înregistrări, ș tergeri ș i modificări ale utilizatorilor în baza de date
date. Toată munca sa va putea fi realizată prin intermediul web-ului, după autentificare
biometrică, de care se ocupă serverul.

Actor utilizator: Reprezintă persoana care trimite imaginea amprentei sale astfel
cum datele referitoare la ea, prin intermediul web-ului, pentru a face parte din
bază de date. De asemenea, are posibilitatea de a se autentifica pentru a verifica că
amprenta ș i datele au fost incorporate în baza de date.

40
 Cazuri de utilizare

4.1.3 Casos de uso

Cazuri de utilizare ale Actorului Administrator

În figura 12 se arată diagrama cazurilor de utilizare pentru actor

Administrator

Al t a _ a d m i n
<<include>>
<<uses>>

<<include>> <<uses>>

Modificare Visualizare
Gestión
Ad m i n i s t r a t o r

(d e la A c t o r e s)
<<include>> <<uses>>
<<uses>>

Baja

Autent_admin

Figura 13. Cazuri de utilizare ale Administratorului

41
 Cazuri de utilizare

Cazul „Gestionare” este cel mai general, reprezintă interacț iunea administratorului cu
sistemul, atunci când realizează sarcinile de administrare. Foloseș te, de asemenea, cazul de
uso“Autenti_admin.”,carevaautentificaadministratorul.

Cazul „Autenti_admin” reprezintă autentificarea actorului în faț a sistemului, care

ne va permite să avem control asupra privilegiilor corespunzătoare fiecărui actor.

Pentru acest caz de utilizare, se va folosi autentificarea biometrică, care ne va asigura

accesul exclusiv, din partea administratorului, la paginile de pe care se
realizeazăsarciniledeadministrare(înregistrări,anulări,modificări).

Cazul de utilizare "Înregistrarea administratorului" (Alta_admin.) are ca scop introducerea unui

utilizator, care a solicitat anterior, în baza de date a noastră

aplicaț ie. Pentru aceasta, ceea ce face este schimbarea valorii unui câmp din tabelul de
utilizatori.

Este vorba de a schimba câmpul Alta din 'F' în 'T', adică din False în True. De acest
un utilizator cu câmpul Alta la 'T' va fi înregistrat în baza de date,
în timp ce unul care îl are pe 'F', se va afla în aș teptare.

Cazul de utilizare „Baja” va ș terge un utilizator din baza de date, atât datele
personale precum datele amprentelor trimise. În acest ultim punct se
vor elimina fizic imaginile amprentelor, precum ș i ș abloanele generate
începând de la acestea.

42
 Cazuri de utilizare

La „Modificare” se ocupă, aș a cum sugerează numele său, de modificarea

datele referitoare la un utilizator (cu excepț ia cheii primare), care a fost deja oferit
de alta în baza de date. Vor fi afiș ate, mai întâi, datele actuale ale unui
utilizator, ș i administratorului i se va permite să introducă modificările dorite, pentru
apoi actualizaț i aceste date în baza de date.

La “Visualización” consiste, în primul rând, în a oferi o listă a utilizatorilor

de la baza de date, pentru a arăta apoi toate datele care sunt prezente
referente la utilizatorul selectat.

Prin urmare, acest proces se va desfăș ura pentru înregistrări, eliminări ș i modificări în scopul
ca administratorul să ș tie în orice moment ce face. Astfel, mai întâi se
to ț i utilizatorii vor fi vizualiza ț i ș i, odată ce unul este selectat, i se va arăta
informaț ii complete referitoare la acesta, pentru a confirma operaț iunea care este la
punct de realizare.

43
 Casos de uso

Cazuri de utilizare ale Actorului Utilizator

Figura 13 reprezintă cazurile de utilizare ale actorului „Utilizator”.

Alta_nuevo_usu

Al t a _ u s u a r i o

folosi
Al t a _ e x i s t e n t e _ u s u
Ușor

( de la Actrițe )

generar_plantilla

Au t e n t i c a r

Figura 14. Cazuri de utilizare Utilizator

Cazul de utilizare „Înregistrare” realizat de utilizatori prin intermediul web-ului se specializează în două:

în primul rând sunt utilizatorii care solicită pentru prima dată înregistrarea în baza noastră de date

date, în al doilea rând avem utilizatorii care au solicitat deja înregistrarea la

unmomentș iulteriordecidsătrimităoaltăamprentă.

Pentru primul caz (Alta_nou_utilizator), utilizatorului i se va prezenta un formular pentru

să introducă atât datele personale, cât ș i posibilitatea de a trimite o imagine
de fiecare dintre urmele sale.

44
 Cazuri de utilizare

În al doilea caz (Alta_existenta_usu), utilizatorul a realizat déjà într-un anumit moment

caz anterior ș i decide să trimită mai multe amprente. Pentru acest caz, utilizatorul va trebui să

identifica ț i pentru a confirma că deja există în baza de date, ș i i se va da

posibilitateadeatrimiteimagininoi.

Cazul de utilizare „Autentificare” reprezintă validarea finală a sistemului, deoarece

constă în verificarea identităț ii unui utilizator care anterior a
a devenit parte a bazei de date.

Se autentifică la amprenta „în viu” a unui utilizator cu ș ablonul generat în

momentul eliberării. Dacă degetul care în acel moment este pe cititor aparț ine unui
utilizator care, anterior, trimisese amprenta degetului respectiv, aceasta
autentificarea va fi un succes. În caz contrar, vi se va indica motivul eș ecului: bine
deoarece nu este un utilizator înregistrat sau bine pentru că fiind în baza de date nu
coincide degetul pe care îl are pe cititor cu vreo imagine de amprentă care
haya enviado.

Cazul „Generaț i ș ablon” generează un ș ablon dintr-o imagine. Acest ș ablon

stochează caracteristicile (detaliile) extrase din amprentă, care o vor face
unică. În acest fel păstrăm informaț ii referitoare la persoană, dar care nu o
nucompromiteînniciunmoment,fiindutilizatăpentruaautentificaamprentaîn"vivo".

Utilizarea acestor ș abloane are ca principal avantaj dimensiunea acestora, deoarece

că în timp ce o imagine a unei amprente ocupă aproximativ 100 Kb, ș ablonul ne ocupă
aproximativ 1 Kb, ș i reuneș te toate informaț iile utilizate în algoritm de
autentificare, care ne va ajuta să diferenț iemunele amprente de altele.

45
 Limbaje și Unelte

4.1.4. Bază de Date

Aplicaț ia de gestionare a amprentelor digitale se bazează pe întreț inerea unei

bază de date care colectează toată informaț ia referitoare la utilizatori ș i amprentele lor
dactilare. Prin urmare, va trebui să creăm acea bază de date.

Baza de date va fi formată din trei tabele cu care menț inem

informaț ii despre utilizatori într-una dintre ele (tabel utilizatori), informaț ii despre
urme pe cealaltă (tabelul urmelor), ș i o ultimă în care vom men ț ine
informaț iicareprivescadministratorul(tabeluladmin).

În dezvoltarea acestei baze de date vom folosi o abordare entitate-relaț ie, pentru
ulterior, converti ț i modelul rezultat într-un model rela ț ional, care va fi
implementat direct în sistemul de gestionare a bazei de date ales.

Înprimulrând,vomrealizaoanalizăacerinț elorsistemuluinostru.

ü Referitor la persoană, ne interesează datele sale personale, adresa,

telefon,etc,fiindidentificatorulunicpentrufiecarepersoanănumărulsăudeidentificarepersonală(DNI).

ü Fiecare persoană va putea face o expediere între o ș i zece imagini cu amprente.

câte una pentru fiecare dintre degetele sale.

ü Amprentele vor fi asociate utilizatorilor prin intermediul CNP-ului acestora.

ü Urmele vor fi asociate cu o mână ș i cu un deget al persoanei care le-a

expediere.

46
 Limbaje și Instrumente

ü De la fiecare amprentă se va genera o ș ablon caracteristic al acesteia,

carevaagilizaprocesuldeautentificare.

ü Pentru autentificarea administratorului se va menț ine un ș ablon, extras

începând de la amprenta sa, în baza de date.

În cazul nostru, vom păstra în baza de date atât imaginile amprentelor.

cum sunt modelele generate. Aceasta nu este procedura obi ș nuită deoarece
precis pe avantajul de a stoca ș abloanele este acela de a nu salva informaț ii
relevante ale utilizatorului, cum ar fi amprentele sale. În plus, pe baza ș ablonului nu
există o modalitate de a reconstrui amprentele, a ș a că identitatea utilizatorului este
totalmente protejată.

O altă avantajă a sistemelor biometrice care stochează modelele caracteristice

de la persoanelor, este că aceste ș abloane sunt de ordinul a 100 de ori mai mici decât
imagini din care se generează. Prin urmare, baza de date va fi
considerabil mai mic.

Din cele expuse anterior, ob ț inem lista de candida ț i pentru entită ț i de

domeniu ș ialta cu relaț iileposibile.

Candidaț i la Entităț i Candidati pentru Relaț ii

S UTILIZATOR are:amprentă
AMPRINT PERTENECE:usuario
ADMINISTRATOR

Tabelul 1. Candidaț i pentru Entitate ș i Relaț ie

47
 Limbaje și Unelte

[Link]. Model Entitate-Relatie

Pentru un studiu al structurii elementelor domeniului, precum ș i al acestora

relaț ii, vom utiliza modelul Entitate-Relaț ie (ER). Figura 14 arată
modelul entitate-relaț ierezultant:

Persona id_persona

Direcț ie

CP Nume Nume
Plantilla

Provincia

Localitate Utilizator Administrator

Ț ară 1

email id_huella

http N
mână
Amprentă
deget

plantă

Figura 15. Model Entitate-Relatie

48
 Limbaje și Unele

[Link]. Dicționar de date

EntitateAdministrator

Persoană care, aș a cum îi sugerează numele, se va ocupa de administrarea bazei de date

deutilizatoriș iamprente.

Atributos:
ID_ADMINISTRADOR [Link]ă.
NOMBRE NumeleAdministratorului.
Ș ablon Șablongeneratdinamprentă.

Clave Principal: ID_ADMINISTRADOR

Cheiealternativă:NUME

EntitateAmprentă

Imaginedigitalizatăaamprenteitrimisedeunutilizator.

Atribute:
ID_HUELLA Clavăprincipalăaamprentei
ID_USUARIO Identificadordelusuarioalquepertenecelahuella.
MÂNA Mâna căreia îi aparț ine amprenta.
DEDO Dedo la cărui aparț ine amprenta.
Ș ABLON Șablonulcareseobț inedinimagine

Cheieprincipală:ID_HUELLA

49
 Limbaje și Instrumente

Entitate Utilizator

Persoana care ne trimite amprenta/ampe în format digital ș i care vor face parte din
de baza noastră de date.

Atributos:
ID_USUARIO [Link]ă.
NOMBRE Nombre del Usuario.
DIRECCIÓN Adresa unde locuieș te utilizatorul, va fi un ș ir de
text
C.P. Cod Poș talal locului de reș edinț ăal utilizatorului.
LOCALIDAD Localitatea de rezidenț ăa utilizatorului.
PROVINCIA Provinciaderezidenț ăautilizatorului.
Ț ARĂ Țara de reș edinț ă a utilizatorului.
EMAIL Dirección correo del usuario.
WEB Paginawebautilizatorului.

ALTA Starea în care se află (A/F).

ClavePrincipal:ID_USUARIO
Clavăalternativă:NUME

Relaț ia Amprentă – Utilizator

Rela ț ia „a avea”. O amprentă concretă apar ț ine unui utilizator, în timp ce un

utilizatorul are între una ș i zece amprente posibile în baza de date. Prin urmare,
suntem în faț a unei relaț ii 1:N.

50
 Limbaje și Unelte

[Link]. Modelul Relațional

Studiul modelului entitate-relaț ie ne conduce la următorul schelet de tabele, care

compuneunmodelrelaț ionalcompletaldomeniuluiaplicaț iei.

TabelaAdministratori

ID_ADMINISTRADOR Entero Nunul

NOMBRE Text Nunulo
Ș ABLON Text Nunul

Clave principal: ID_ADMINISTRADOR

Dependinț eFuncț ionale
ID_ADMINISTRADOR -> NOMBRE, PLANTILLA
3º Forma Normal

TabelaUtilizatori

ID_USUARIO Entero Nunul

NOMBRE Text Nunul
DIRECCIÓN Text Nunul
C.P. Entero
LOCALIDAD Text
PROVINCIA Text
Ț ARĂ Text
EMAIL Text
WEB Text
ALTA Text Nunul

51
 Limbaje și Instrumente

Cheieprincipală:ID_UTILIZATOR
Cheiealternativă:NUME

Dependencias Funcionales

ID_USUARIO -> NOMBRE, DIRECCIÓN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB

NOMBRE -> ID_USUARIO, DIRECCIÓN, C.P., LOCALIDAD, PROVINCIA ,

PAIS, EMAIL, WEB

3º Forma Normal

TabelaUrme

ID_HUELLA Text Nonulo

USUARIO Entero Nu nul, Cheie străină
MANO Text Nunul
DEDO Text Nunul
Ș ABLON Text Nunul

Cheieprincipală:ID_AMPRENTĂ
Cheie străină: UTILIZATOR referinț ă ID_UTILIZATOR în tabela Utilizatori.

Dependinț eFuncț ionale

ID_HUELLA -> USUARIO, MANO, DEDO, PLANTILLA.

3º Forma Normal

52
 Limbaje și Instrumente

4.2 Limbaje și unelte

4.2.1 Programare Web

Ideea de a folosi web-ul ca un mediu de aplicaț ii s-a dezvoltat odată cu

timp, astfel încât fiecare etapă de inovaț ii tehnologice a servit drept trambulină
pentru apariț ia de noi idei. Primul model operaț ional consta pur ș i simplu
pe un server Web care trimitea documentele care erau solicitate. În acest mediu,
conț inutul nu se schimba decât dacă cineva furniza o nouă versiune a
document. Figura 15 arată acest mediu.

Navigator Web Server web

GET/[Link]

<HTML>...<HTML>

Documente
HTML

Figura 16. Modelo de server pentru documente statice

53
 Limbaje și Unelte

HTTP (Protocollul de Transfer Hypertext) este un protocol simplu de cerere/răspuns în

când browserul web solicită un document, de obicei folosind comanda
GET, ș i serverul Web returnează documentul sub formă de un flux de date HTML
(Limbaj de Marcare Hypertext), precedat de câteva antete descriptive.

Rapid a devenit evident că, dacă o persoană putea verifica documentele

gestionate de serverul Web, de asemenea, putea face acest lucru un program de text
procesat ca un script Perl. Browserul Web nu apreciază
diferenț a deoarece rezultatul unei cereri HTTP rămâne un flux de date
în HTML. Mai mult, browserul poate trimite ceva mai mult decât o simplă cerere:
puteț i trimite parametrii, incluzându-i în URL (Univers Motiv Localizare) sau
trimiterea unui flux de date cu cererea. Aceasta sugerează că o cerere HTTP
poate fi interpretată ca o interogare a unei baze de date ș i rezultatele acesteia
consulta se pot folosi pentru a construi dinamic un document HTML. Cu
dezvoltarea serverului Web NCSA HTTPd a adus o nouă specificaț ie, CGI
(Interfaț a Comună de Acces)

Serverul Web invocă un program CGI ca răspuns la un anumit tip de

cereri, în general cereri de documente dintr-un director concret sau
nume de fi ș iere cu o extensie specifică, cum ar fi .cgi. Cei
parametrii cererii sunt transmi ș i ca perechi cheie/valoare ș i anteturile
răspuns ca variabile de mediu. Programul cite ș te ace ș ti parametru ș i le
cabeceras, realizează sarcina aplicaț iei cu care se lucrează, ș i atunci
generează un răspuns HTTP. Răspunsul este trimis browserului web solicitat
ca ș icum ar fi un document static obiș nuit.

54
 Limbaje și Instrumente

Figura16ilustreazăfluxulprocesului.

Navegator Web Server Web

GET/cgi-bin/pgm
<HTML>…</HTML>

Programa CGI

Bază
de date

Figura 17. Conț inut dinamic generat de un script CGI

CGI-urile generează în mod normal un nou proces pentru fiecare cerere HTTP. Aceasta
reprezintă o problemă atunci când traficul este rar, dar provoacă suprasarcină când
niveluldetraficcreș te.Înaceastăsituaț ie,CGI-urilenusepotrivesccunevoilenoastre.

nevoile.

A avut loc o îmbunătăț ire semnificativă odată cu apariț ia, în 1997, a API-ului Servlet.
Java, care a fost urmat rapid de APIJSP (acronim pentru Java Server Pages,
Java Pages pe server). Această tehnologie aduce tot poten ț ialul Java la
server Web, cu conectivitate la baza de date, acces la muncă în reț ea, operaț iuni
de subprocessuri ș i, mai ales, un model de proces diferit.

55
 Limbaje și Instrumente

Servleturile ș i paginile JSP operează dintr-un singur exemplar sau instan ț ă care
rămâne în memorie ș i utilizează multiple subprocese pentru a răspunde la diferite
cereri în paralel. Figura 17 ilustrează utilizarea acesteia
tehnologie.

Navegator Web Server Web

GET / requestURI
<HTML>…</HTML>

Motoare deservite

Servlet-uri Pagină JSP

Servicii J2EE

Altele
Baza servicii
de date

Figura 18. Aplicaț ii dinamice folosind servlete, JSP ș i J2EE.

56
 Limbaje și Unelte

Modelul de aplicaț ie web a evoluat pe măsură ce web-ul a evoluat

maturându-se ș i experienț a obț inută în fiecare fază a determinat cerinț ele pentru
valul iniț ial de Java pe client sub formă de applet-uri a fost foarte
popular, dar a dus la dezamăgire când a fost aplicat în practică. Utilitatea
appletul era limitat de numărul considerabil de incompatibilităț i între
navigatoare, din cauza perioadelor excesive de descărcare cu modemuri lente ș i din cauza

restricț ii de securitate. Din această cauză, dezvoltarea applet-urilor a fost mai

lento ș itehnologia Java pe server a devenit cea mai mare zonă de creș tere.

Java pe server nu suferă restric ț iile mediului applet. Nu apar

inconsecvenț e ale browserului pentru că nu este necesar să aibă o maș ină
Java virtual. Browserul trebuie să genereze doar HTML, iar acest lucru poate fi realizat
razoabil bine chiar ș i pentru cele mai vechi browsere. Nu este precisă
configurarea clientului nici descărcarea de la alte resurse de fiș iere extinse de
clase. În acelaș i mod, consideraț iile de securitate se limitează la cele deja
gestionate de serverul Web, care este de obicei într-un mediu închis cu
controles separate.

57
 Limbaje și Instrumente

4.2.2 Limbajul Java

Pentru utilizarea API-ului cititorului avem mai multe posibilităț i: una este utilizarea API-ului
C/C++ care vine cu documentaț ia dispozitivului de amprente digitale
disponibile ș i care ne-ar conduce la utilizarea tehnologiei CGI de partea
server; cealaltă posibilitate de care dispunem este utilizarea Java profitând de
clase Java (wrapper-e Java) care ne vin cu mediul de dezvoltare pentru
programator.

Utilizarea CGI ne-ar duce la utilizarea tehnologiei Microsoft ASP (Active Server
Paginile) pentru generarea dinamică a paginilor, ș i toate acestea lucrând sub
Server Microsoft (IIS). Pe de altă parte, utilizarea Java ca limbaj de server
ne-ar duce să folosim JSP (Java Server Pages) pentru generarea dinamică a
pagini; putând alege o serie de servere care func ț ionează ca
containere de servlets: JRun, Tomcat, etc.

Am optat pentru utilizarea Java ș i a tehnologiilor sale Servlets, JSP ș i Javabeans ca

limbaj pentru dezvoltarea diferitelor module ale aplicaț ieide
oseriedemotivepecarelediscutămmaijos:

Java prezintă o serie de avantaje în compara ț ie cu alte limbaje, printre care

evidenț iemurmătoarele:

ü Securitate

Modelul de securitate Java are trei componente

principalele: încărcătorul de clase, verificatorul de bytecode
Manager de securitate.

58
 Limbaje și Instrumente

Verificatorul de bytecode se asigură că programul a fost compilat

corect, să respecte restricț iile de acces ale VM (Mediu Virtual)
Ma ș ină, în spaniolă Maquina Virtual) ș i că programul să nu acceseze la
date private decât dacă trebuie să o facă.

Încărcătorul de clase, conform recuperării claselor din reț eaua de lucru, se

se stochează pe servere Web independente, astfel se evită că
am încărcat din greș eală o clasă care pretinde să fie un complement la clasă
principal ce interferează în procesul de încărcare a claselor provenite de la
alt server.

SecurityManagerul este responsabil de stabilirea politicii de ac ț iune a

[Link] de securitate determină activită ț ile pe care le poate efectua
laVMy sub ce circumstanț e.

ü CoreAPI

Interfaț a CoreAPI oferă un set de funcț ii comune pentru

toate platformele care pot lucra cu Java.

Interfaț a se împarte în pachete, care sunt grupuri de clase care pot

a dezvolta o serie de funcț ii. În unul dintre aceste pachete se află
las bases del lenguaje de programación, tales como el control de texto y
proceso de errores.

ü Standarde deschise

În prezent, VM-ul poate fi utilizat cu mai mult de o duzină de

combinaț ii de hardware ș i sisteme de operare. Fiș ierele scrise în
această limbă nu trebuie să fie compilată pe toate platformele.

59
 Limbaje și Unelte

Important este ca aceste platforme să lucreze cu VM. O

aplicaț ie în Java care este scrisă astăzi, se va rula pe toate platformele
să lucreze cu VM-ul, deș i acesta nu a fost încă creat.

ü Distribuitș idinamic

Încărcătorul de la VM caută fiș ierele class care se află pe o reț ea

o pe un hard disk, proces complet transparent pentru utilizator,
facând ca distribuț ia aplicaț iilor în Java să fie completă
transparente. Aceste proprietăț i permit browserului compatibil cu
Java se adaptează automat la protocoalele pe care le primeș te de la un
noul siteWeb.

ü Orientată pe obiecte

La Programarea Orientată pe Obiecte, sau Programarea Orientată pe Obiecte

(OOP) este o formă de a scrie un software care poate fi reutilizat ș i
cui între ț inerea este cu adevărat simplă. Java este un limbaj de
programare orientată pe obiecte. De fapt, CoreAPI este un set de
componente OOP care se cunoaș te sub numele de bibliotecă class. Bibliotecile class

permit să economisească mul ț i nervi programatorii

când trebuie să dezvolte noi proiecte.

ü Multitasking

O aplicaț ie monotasking are un fir de execuț ie (thread) care va fi responsabil de

se ocupă de a executa tot ce i se cere. Cu acest sistem numai

poate dezvolta o sarcină de fiecare dată.

60
 Limbaje și Unelte

Aplicaț iile multitasking pot utiliza mai multe fire de execuț ie simultan în timpul
execuț ie. Aceste thread-uri comunică între ele, astfel încât să poată coopera
între ei părea, din fa ț a utilizatorului, că programul o face
executând un singur fir, dar mai repede decât cu aplica ț iile
monotarea.

ü Administrarea memoriei ș icolectarea „gunoiului”

Sistemul recuperează memoria temporară în momentul după o anumită cantitate

de timp fără ca programul activ să o solicite. Astfel se eliberează la
dezvoltator al unei părț i plictisitoare a muncii.

Ingineria componentelor a făcut posibil să se realizeze a cabo mari

progrese în hardware ș i în tehnologia electronică. Programarea bazată pe
componentele aduc această idee în lumea software-ului. În domeniul Java, acesta este ceea ce
JavaBeans

JavaBean este un component elemental reutilizabil de software. Este vorba despre

blocuri de construcț ie care servesc pentru a crea aplicaț ii.
Pentru ca bean-urile să funcț ioneze, este nevoie doar de VM Java. Acest lucru permite ca

beans bine construite se utilizează în orice mediu Java: applet-uri, servlete,

pagini JSPsau aplicaț ii Java autonome.
Pe de altă parte, servleturile sunt clase Java care extind funcț ionalitatea unui server
Web prin generarea dinamică de pagini Web. Un mediu de execuț ie
denumit motor de servlets administrează încărcarea ș i descărcarea servletului ș i lucrează
cu serverul Web pentru a direcț iona cererile către servleturi ș i a trimite răspunsul la
clienț i.

Întrucât am optat pentru utilizarea servlet-urilor în detrimentul interfeț ei

CGI, vom explica unele dintre avantajele sale principale:

61
 Limbaje și Unelte

ü Performanț ă

Tehnologia CGI de obicei iniț iază un nou proces pentru a gestiona

fiecare cerere care le ajunge. Servletele, dimpotrivă, sunt încărcate atunci când se
solicitan pentru prima dată ș i rămân indefinit în memorie. El
motor de servlet descarcă un singur exemplar sau instanț ă a clasei Servlet
lansa solicitări folosind un set de subprocese disponibile
(threadso hilos). Îmbunătăț irea performanț ei cu acest sistem este
considerabil.

ü Simplicitate

Servleturile se execută într-o VM într-un mediu de server controlat ș i

au nevoie doar de HTTP-ul de bază pentru a comunica cu clienț ii lor. Nu este
precis că clientul are nevoie de un software special, nici măcar în
navigatoare antice.

ü Sesiuni http

Deș i serverele HTTP nu au capacitatea de a reț ine detalii de

o cerere prealabilă din partea aceluiaș i client, interfaț a APIServlet oferă
o clasă HttpSession care permite depăș irea acestei limite.

ü Acces la tehnologia Java

Fiind aplicaț ii Java, servletele au acces direct la întreaga gamă de

caracteristici Java, cum ar fi utilizarea subproceselor, accesul la re ț ele ș i

conectivitate la baza de date.

62
 Limbaje și unelte

ü Comunicare

Cum fiecare invocare a unui program CGI declan ș ează un proces

independent, comunicarea între ei trebuie făcută frecvent la
prin fiș iere, ceea ce poate încetini considerabil operaț iunea. Dacă aceste
programele aparț in aceluiaș i server, intercomunicarea lor este de obicei
deasemenea,problematică.

ü Securitate

Unele variante de CGI au probleme grave de securitate. Deș i se

utilizaț i cele mai recente standarde sau limbaje relativ sigure, sistemul
nu oferă garanț ii suficiente de protecț ie.

O pagină Java pe server, sau "Java Server Pages" (JSP), este un ghid pentru o
pagină Web care utilizează cod Java pentru a genera un document HTML
dinamic. Paginiile JSP se execută într-un component al serverului
cunoscut sub numele de container JSP, care le traduce în servleturi Java echivalente.
Din acest motiv, servlet-urile ș i paginile JSP sunt strâns legate.
se poate face cu o tehnologie, este, în mare măsură, de asemenea posibil cu cealaltă;
deș i fiecare are capacităț ile sale proprii. Cum sunt servletele, paginile JSP
au toate avantajele servletelor, dar au ș i avantaje proprii:

ü Se recompun automat atunci când este necesar.

ü Cum sunt în spaț iul comun al documentelor serverului Web, vă rugăm să vă adresaț i

aeleestemaiuș ordecâtateadresaservletelor.

ü Deoarece paginile JSP sunt similare cu HTML-ul, au o compatibilitate mai mare

cu uneltele de dezvoltare web.

63
 Limbaje și Unelte

JavaScript este un limbaj de programare creat de Netscape cu scopul de

a se integra în HTML ș i a facilita crearea de pagini interactive fără necesitate de
utilzarscriptsdeCGIsauJava.

Codul programului JavaSript, numit script, este introdus direct în

document HTML ș i nu trebuie să fie compilat, este propriul browser care se
se ocupă cu „traducerea” acelui cod.

Datorită JavaScript-ului, putem dezvolta programe care se execută direct în

navigatoarele (client) astfel încât să poată efectua anumite operaț iuni sau
a lua decizii fără a fi necesară accesarea serverului.

64
 Limbaje și Unelte

4.2.3 Instrumente

Apache a fost dezvoltat de diverș i utilizatori care au trebuit să-ș i repare

ai dat gre ș eli odată ș i au adăugat func ț ii la software-ul serverului web,
disponibil în primele zile aleWorldWideWeb.

Este unul dintre cele mai bune servere web utilizate pe reț eaua Internet de ceva timp.
mult timp, singura competiț ie este un server de Microsoft, IIS.
ce server este unul dintre cele mai mari triumfuri ale software-ului liber.

Configurarea ș i administrarea Apache se bazează pe un sistem de fiș iere,

editabil dintr-un editor de texte. Caracteristicile principale ale Apache sunt
următoarele:

ü Permite instalarea serviciilor de aplica ț ie CGI, Perl ș i Java.

Opț ional, ș i ca o măsură comună de acces la Internet pentru echipamente
de la companie, dispune de un serviciu proxy, permiț ând specificarea
securitate a accesului la Internet, precum ș i împiedicarea accesului nedorit
din exterior.

ü Implementa ultimele protocoale, chiar dacă se bazează pe HTTP/1.1

ü Poate fi adaptat la diferite medii ș i necesităț i, cu diferitele

module de suport ș i cuAPI-ul de programare a modulelor.

ü Încurajează realimentarea utilizatorilor, ob ț inând noi idei,

rapoartedeeroriș ipatch-uripentrualesoluț iona.

65
 Limbaje și Unelte

ü Func ț ionează pe un număr mare de platforme (Unix, Linux, Vms,

Win32, OS2).

ü Móduli încărcaț i dinamic.

ü Utilizarea SSL pentru tranzacț ii sigure.

ü Suport pentru gazde virtuale.

ü Performanț ă înaltă.

Pentru a face ca serverul nostru web să fie un server sigur, este convenabil
utilizaț itehnologiaSSL(SecureSocketLayer)pecareodetaliemmaijos:

SSL este o tehnologie dezvoltată de Netscape în 1994 împreună cu primul său

navigare, pentru a asigura confidenț ialitatea ș i fiabilitatea comunicaț iilor între două
aplica ț ii. Utilizează un sistem de criptare asimetric bazat pe chei
public/privat pentru a negocia o cheie de sesiune care va fi utilizată pentru a stabili
o comunicare bazată pe criptare simetrică. SSL este protocolul de criptare cel mai
utilizat pe Internet în aceste momente ș i este cel mai folosit pe serverele web unde
se solicită informaț ii confidenț iale, de asemenea este deschis ș i de domeniu public, iar acesta

implementareaestesimplă.

Securitatea SSL oferă în prezent servicii de criptare a datelor, server

de autentificare, integritate a mesajului ș i autentificare a clientului pentru o conexiune
TCP/IP.

66
 Limbaje și Instrumente

ü Cifrul de date

Informaț ia transferată este criptată folosind un algoritm cu cheie secretă,

capabil să cripteze volume mari de informaț ii într-un timp foarte scurt, pentru
ceea ce va fi ininteligibil în mâinile unui atacator, garantând astfel
confidenț ialitate.

ü Autentificarea serverelor

Utilizatorul îș i poate verifica identitatea serverului la care se conectează ș i la

că posibil să trimită informaț ii personale confidenț iale. În acest fel se
evită ca un utilizator să se conecteze la un server „impostor” care a copiat
pagini ale serverului pe care îl substituie. Aceste atacuri sunt cunoscute sub numele de Web

spoofing-ul ș i se utilizează pentru a obț ine parolele ș i numerele de carduri

de credit al utilizatorilor.

ü Integritatea mesajelor

Se împiedică ca modificările inten ț ionate să treacă neobservate sau

accidentaleîninformaț iiîntimpce"călătoreș te"peInternet.

ü Autenticareclient

Permite serverului să cunoască identitatea utilizatorului, în scopul de a decide dacă

poate accesa anumite zone protejate. În acest caz, clientul trebuie să aibă
instalând un certificat pe computerul său sau pe un card inteligent, care îi
va permite autentificarea în faț a serverului web. Astfel, se evită atacurile comune de
captarea parolelor prin utilizarea analizatoarelor de protocoale
(sniffers) sau atacul prin forț ă brută cu parole.

67
 Limbaje și Unelte

SSL poate avea o cheie de sesiune de 40 de biț i sau de 128 de biț i, această cheie este

generată în fiecare tranzacț ie. Lungimea cheii va face mai greu de spart
cifrat. Majoritatea browserelor suportă o cheie de 40 de biț i pentru sesiuni
SSL, în timp ce ultimele versiuni suportă chei de sesiune de 128 de biț i.

Funcț iilesunt:

ü Verificareaidentităț ii

Emiterea de către serverul clientului a unui Certificat Digital unic, asigurându-i

autenticitate pentru persoanele care vizitează serverul său web ș i permiț ând ca
comunicările sunt criptate pentru a ob ț ine o mai mare intimitate ș i
fiabilitate în tranzacț iilecomerciale sau în comunicaț ii.

ü Menț inereasecurităț ii

Un server SSL trebuie să menț ină securitatea ș i integritatea informaț iilor

prin metoda cheii publice/private.

ü Facilitatea de utilizare

În ciuda marii siguranț e pe care trebuie să o aibă, serviciul trebuie să fie uș or.
usopentruclienț ifărămaritraumecarepotprovocaconfuzii.

Vom utiliza Apache ca server pentru pagini web statice ș i îl vom lega cu
Tomcat, lucrând ca un container de servlets. Astfel eliberăm de
soport Tomcat, pe care îl utilizăm doar atunci când avem cu adevărat nevoie de putere
de Java, ș i vom folosi Apache pentru restul, profitând de robustea sa.

68
 Limbi și Instrumente

Tomcat, unul dintre proiectele de cod deschis condus de Apache Software

Foundation este o aplicaț ie web bazată pe Java creată pentru a executa servlet-uri
pagini JSP, fiind implementarea oficială de referinț ă a specificaț iilor
Servlet 2.3 ș i JSP 1.2.

AmdecisutilizareaTomcatdinurmătoarelemotive:

ü Este "gratuit" ș i de "cod liber".

ü VomfolosiJSPpentrugenerareadinamicăapaginilor.

ü Ne va permite utilizarea JavaBeans, ceea ce ne va facilita implementarea

logica aplicatiei pe baza de componente, cu ceea ce obtinem
programaț i aplicaț ia noastră orientată pe obiecte.

ü Oferă o integrare totală cu sistemul de operare Windows

NT/2000/XP.

În plus, pentru a realiza sarcina de a transfera un fiș ier pe server, de la noastre

pagini JSP, am folosit un modul dezvoltat în Java, complet gratuit ș i
disponibil pe reț ea,este JspSmartUpload.

JspSmartUpload este un pachet de clase Java, care ne va permite să transferăm fiș iere.
a serverul nostru. În cazul nostru, vom utiliza acest modul pentru ca utilizatorii
Ceicaredoresc,sănetransfereimaginiledigitalizatealeamprentelorlor.

69
 Limbaje și Instrumente

Vom explica câteva dintre caracteristicile acestui pachet:

ü Simpluș iComplet

Sunt necesare doar câteva linii de cod în aplicaț ia noastră JSP

pentru a efectua sarcina de transferare a fiș ierelor. Oferă toate caracteristicile
ce este nevoie pentru a transfera unul sau mai multe fiș iere pe serverul web folosind
un browser. La fel, toate fiș ierele pot fi înregistrate
într-o bază de date.

ü Control total asupra procesului de încărcare a fiș ierelor

Obiectele ș i metodele modulului jspSmartUpload permit accesul la

toate informaț iile despre fiș ierele transferate (dimensiune, nume, tip,
extensie,etc.),chiarș ifărăasalvafiș ierelepedisc.

ü Gestionareaformularelormixte

JspsmartUpload oferă un control total asupra formularelor mixte.

încărcând atât câmpuri de fiș iere cât ș i câmpuri de formulare.

ü Control total asupra fiș ierelor trimise

Caracteristicile restrictive ale jsSmartUpload permit men ț inerea unui

control total asupra fi ș ierelor transferate pe server. De exemplu, se
poate limita transferul de fiș iere în funcț ie de dimensiune ș i tipul acestora
mismo.

70
 Limbaje și Instrumente

Pentru a găzdui baza noastră de date avem o cantitate mare de sisteme de gestionare
de baze de date. Amestecând diferitele caracteristici ale fiecăruia, în cele din urmă
am ales utilizarea MySQL.

O caracteristică importantă este că consumă foarte puț ine resurse, atât de CPU
cum ar fi memoria. Au fost sacrificate unele caracteristici esenț iale în sisteme mai
"serios" cu acest scop

Avantaje

ü Performanț e [Link]ă mai mare atât la conectarea cu serverul.

cum să serveș ticereri.

ü Utilităț ideadministrare(backup,recuperareerori,etc).

ü Controlul accesului, în sensul căror utilizatori au acces la ce

tabele ș i cu ce permisiuni.

JDBC (Java Data Base Connectivity) oferă o interfa ț ă standard cu

server de baze de date. Oferă un API pe care îl putem folosi indiferent de ce bază
de date se foloseș te.

La conectividad de la base de datos de Java es un marco de programación para los

dezvoltatori Java care scriu programele care au acces la
informaț ii în baze de date, foi de calcul ș i fiș iere "plate". JDBC este utilizat
comun pentru a conecta un program cu o bază de date, fără a conta ce
software de administrare sau gestionare a bazei de date se utilizează pentru a-l controla. De
În acest fel, JDBC este o platformă multiplatformă. Figura 18 arată un schelet de
uso de la interfaz JDBC:

71
 Limbaje și instrumente

Interfaț ăJDBC

Ș ofer Ș ofer Ș ofer

ODBC Sybase Oracle

Bază Bază Bază

Acces Sybase Oracle

Figura 19. Interfaț ă JDBC

Indiferent de locaț ie, platformă sau program pilot al sursei de date

(Oracle, Microsoft etc.), JDBC se conectează la o sursă de date
furnizând o colec ț ie de extensii (clasă) care con ț in clasele
abstracte ale interacț iunii bazei de date. Ingineria software-ului în
programelecuJDBCconducdeasemenealareutilizareamodulară.
Pentru a putea accesa MySQL din aplicaț iile noastre, vom avea nevoie de un „driver”.
Vom utiliza cea mai recentă versiune disponibilă pe pagina oficială MySQL,
MySQL Connector/J 3.0.1

MySQL Connectores este un „driver” creat de MySQL AB care ne va permite să lucrăm cu

MySQL din programe scrise în Java. Spre deosebire de alte "driver-e", acesta este de
liber distribuț ie y tiene un bun performanț ă.

MySQL Connector/Jes este un „ driver” nativ de Java care converte ș te apelurile

generate de JDBC în protocolul de reț ea pe care îl foloseș te baza de date MySQL.
Permite dezvoltatorului să lucreze cu limbajul de programare Java ș i astfel

72
 Limbaje și Instrumente

forma construire programe ce interacț ionează con Mysql.

Analizândtoateacesteopț iuni,amdecissăfolosimurmătoarele
tehnologii în dezvoltarea acestui proiect:

ü Sistem de gestionare a bazelor de date MySQL.

ü JDBC pentru accesul la baza de date utilizând SQL.

ü Apache ca server de pagini web statice.

ü GenerareadinamicădepaginicuJSPpeserverulTomcat.

ü Javabeans pentru a implementa aplicaț ia noastră complet orientată către

obiecte, utilizând clase Java.

ü Pachetul Jspsmartupload pentru a transfera fiș ierele pe serverul nostru

aplicaț ie.

73
 Design și Implementare

4.3 Design și dezvoltare

4.3.1 Implementare

Figura19aratădiagramadedesfăș urareaaplicaț iei.

Terminal
del
Administrator
Server
Calculator
al utilizatorului
de la
aplicaț ie
Lector de
urme

Server
Web

Bază
de
Datos

Figura 20. Desfăș urarea aplicaț iei

74
 Design și Implementare

Aplicaț ia rezidă pe serverul aplicaț iei, cu acces direct la baza de date

Date. Atât sarcinile utilizatorilor, cât ș i cele ale administratorului vor putea fi realizate
de pe un simplu browser de pe calculatoarele lor personale, conectându-se prin
webalserveruluiaplicaț iei.

4.3.2 Gestionare

Figura 20 arată schema diferitelor pachete software dezvoltate, astfel

cum dependenț ele sale.

ClasesJava Clases
jspSmartUpload

Clases
Auxiliare

ClasesDominio ClasesInterfaz

Clases Clases
Amprenta digitală mySql-connector

Figura 21. Pachete ale aplicaț iei

75
 Proiectare și Implementare

[Link] Clase Java

Acest pachet reprezintă clasele native din Java. Printre ele se află
inclus în pachetele standard: [Link]., [Link]., [Link]., [Link]., etc.

[Link] Clase Auxiliare

Acest pachet conț ine clasele dezvoltate pentru a facilita aplicaț ia. La
figura 21 arată aceste clase.

TElemento Persoană Listați Mostrar

(dePerspectivaLogicala) (din punct de vedere logic)

ID sunt o persoană

Superclase
generică de
Claseparalistar Clasepara
orice clasă de
timagen elcontenidode mostră arto dos los
dominio
labasede datosreferentesa
(din punct de vedere logic)
datos unui său
id_imagen

recoger

Clasequenos
facilitaelmanejodel
valordeloscampos
delosformularios

Figura 22. Clase Auxiliare.

76
 Proiectare și Implementare

[Link] Clase Domeniu

Clasele de domeniu sunt rezultatul formulării problemei, în forma

de situaț ii extrase din lumea reală. Figura 22 arată diagrama claselor
aldomeniului.

tElemento

(din Punct de vedere Logic)

ID

Persona
timagen
(din punct de vedere logic) (d e l P u n c t d e V e d e r e L o g i c)

sunt o persoană
id_imagen

Huella
(dePerspectivaLogical)

Administrator Usuario
id_usu
( din punct de vedere logic ) ( din punct de vedere logic ) mano
conectare nombre dedo
parolă direcț ie plantilla
c.p.

alta_admin() localitate alta()

baja() provincia generar_plantilla()
autentificare() pais borrar()
estado inicializar()
recuperare
alta_usu()
autenticar()
actualizar()
recuperar()
inițializare()

Figura 23. Clase ale domeniului

77
 Design și Implementare

[Link] Clase Interfață

Acest pachet conț ine clasele specifice interfeț ei aplicaț iei, sunt clase care
sunt folosite pentru a arăta ș i a captura informaț ii referitoare la clasele domeniului. În
cazul aplicaț iei noastre se referă la pagini, atât html cât ș i jsp. Figura 23
aratădiagramadeclaseainterfetei.

Index

autenti_admin

usu_alta usu_huellas autentificare

ad_alta ad_borrar ad_modif

Figura 24. Clase Interfaț ă

Fiecare clasă reprezintă o pagină găzduită pe serverul nostru, care ne va arăta

informaț iile de care avem nevoie în fiecare moment în funcț ie de sarcina care urmează să fie
realiza.

Această clasă reprezintă pagina de început a aplicaț iei noastre ș i de unde

se va putea accesa fiecare pagină în funcț ie de ceea ce se doreș te să se facă.

78
 Design și Implementare

PAGINI ADMINISTRATOR

Autenti_admin: Pe această pagină se solicită administratorului să se identifice în fața

sistema, se utilizará autenticación biométrica para controlar el acceso a las páginas
de la care să efectuez sarcinile de administrare.

Opț iuneÎnaltAdministrator

ad_alta:Esta clase representa la página en la que se muestran los usuarios que estén
în baza de date, aș teptând să fie daț i în vileag, pentru ca administratorul să decidă
cine doreș te să se înregistreze.

Opț iunedescădereadministrator

ad_borrar:Lista los usuarios dados de alta, para que el administrador decida a quien
vrea să renunț e.

Opț iuneaModificareAdministrator

ad_modif.: Clasă responsabilă pentru a arăta utilizatorii care sunt înregistrați în

bază de date, pentru ca administratorul să aleagă pe cel pe care doreș tesă-l modifice.

PAGINAS USUARIO

Opț iuneÎnregistrareutilizatornou

Usu_alta: Afișați formularul pe care trebuie să-l completeze utilizatorul nou care dorește să treacă

a face parte din baza noastră de date, atât cu câmpuri pentru datele personale
ca să ne trimită fiș ierelecu imaginile.

79
 Proiectare și Implementare

Opț iuneadeatrimiteamprenteUtilizatorexistent

Usu_huellas: În caz că este gândit pentru acel utilizator care a solicitat deja să treacă la formă

parte de la baza de date, ș i că după o vreme decide să trimită noi amprente. Se

le solicită să se identifice ca utilizator existent ș i i se permite să trimită noi
urme.

OpciónAutenticarUsuario

Autentificare: Pe pagina de autentificare se va solicita identificarea utilizatorului,

mâna ș i degetul pe care se va realiza validarea. Odată introduse se
va captura amprenta utilizatorului ș i se va autentifica cu cea din baza de date.

80
 Design și Implementare

[Link] ClasesjspSmartUpload

La figura 24 muestra el diagrama de clases del módulo JspSmartUpload:

SmartUpload

Încărcare Inteligentă ()
getFiles()
getRequest()
obțineDateBinare()
getSize()
Cerere
setareListaFisierePermise()
setContentDisposition()
getParameter()
setDeniedFilesList()
getNumeParametrul()
setDenyPhysicalpath()
g e t P a r a m e t e r Va l u e s ( )
seteazăDimensiuneaMaximăARundefișier()
s e t e a z ă D i m e n s i u n e a M a x i m ă To t a l ă A L F i ș i e r u l u i ( )
downloadField()
downloadFile()
salvează()
încărcare()
uploadlnFile() Fișier

f i l e To F i e l d ( )
getBinaryData()
getContentDisp()
getContentString()
Fișiere
g e t C o n t e n t Ty p e ( )
getFieldName()
getCount() getFieldExt()
getFile() obțineNumeFișier()
getSize() getfilePathName()
getSize()
g e t S u b Ty p e M I M E ( )
g e t Ty p e M I M E ( )
sunt lipsă ()
salveazăCa()

Figura 25. Clasele JspSmartUpload

81
 Design și Implementare

[Link]. Clase mysql-connector

Aceste clase se conectează la gestionarul de baze de date din paginile jsp ș i beans.A
această clasă apar ț ine de exemplu clasei [Link] care permite crearea unei
instanț a driver-ului care ne va conecta cu mysql. Alte clase, de asemenea, importante
son:[Link],ResultSet, etc.

[Link]. ClasesFingerprint

Aceaste clase aparț ine API-ului Java care permite accesul atât la cititorul de amprente,
cum ar funcț iile proprii ale clasei Fpr, care facilitează autentificarea ș i
generareaunuiș ablondintr-oimagineauneiamprente.

82
 Design și Implementare

Diagramă de Secvență și Colaborare

În continuare vom arăta diagramele de secven ț ă ș i colaborare

corespunzătoare fiecăruia dintre cazurile de utilizare ale sistemului nostru:

DiagramadeSecvenț ă:AutentificareAdministrator

Interfață A p l i c a t i e Administrator
Administrator

Intrare

Pedirdatos

Identificare

A accepta

Pedirdedo

Ponerdedo

autenticar()

Figura 26. Secvenț a de Autentificare Administrator

83
 Design și Implementare

DiagramadeColaborare:AutentificareAdministrator

Intrare
4:Identificare 2:
A accepta 6:

Interfață Aplicație

3:Introduceredatos
Administrator 9:

7a:ue
tncita)r(
8:

Administrator

Figura 27. Diagrama de colaborare, caz Autentificare Administrator

84
 Design și Implementare

DiagramadeSecvenț ă:Vizualizare

Interfață Aplicație
Administrator

Pulsare

Listarusuarios

Selcatiț ziu
a
lio
tr
Așaifțziau
lotir

Așfiaiț dae
tel

Figura 28. Secvenț a de Vizualizare

85
 Proiectare și Implementare

DiagramadeColaborare:Vizualizare

Tarea
4:Selectarerusuario

Interfață

7:Mostrardatos
( Administrator )

3: 2:Listarusuarios
6: 5:Mostrarusuario

Aplicație

Figura 29. Diagrama de colaborare, caz Vizualizare

86
 Proiectare și Implementare

DiagramadeSecvenț ă:ÎnregistrareAdministrator

Administrator Interfață Aplicație Administrator

Puslaarta
l
zoa
ilo
rL
slta
iu
rtit

Seelccoinaursuao
ri

Așaifțziau
lotiu
rl

Afișați datee
l

Confirma

OK

aa
tl_admni)(

Figura 30. Secvenț a Administratorului de Înaltă

87
 Design și Implementare

DiagramadeColaborare:AltaAdministrare

1:Alta
4:Seleccionarusuario
9:OK

Interfață

7:șfiaț dae
A t
: (Administ rador) 8:Confirmar

2:Listarusuarios
5:șaiferzia
A u
lo
itr
3:
10:
6:
13:

12:

U s u a r i o Aplicație

11a:ta
l)(

Figura 31. Colaborare, caz Administrator Superior

88
 Proiectare și Implementare

DiagramadeSecvenț ă:Ștergere

Interfață Aplicație Administrator Amprentă

Administrator

PulsarBaja
Listarusuarios

Seleccionarusuario

izașța
A o
ifu
trlu
it

Mostrardatos

Confirmar

OK

baa
j)(

șterge( )

Șetrgeamprena
t

Figura 32. Secvenț ă de Reducere

89
 Proiectare și Implementare

Diagrama de Colaborare: Scăzut

2:Listarusuarios
Baja 5:Mostrarusuario
Selecționare rusă 10:
9:OK
I n t e r f a z a A p l i c a c i e

7:Mostrardatos 3:
(A d m i n i s t r a t o r)8 : C o n f i r m a r 6:
15:

11:baja()
12:
14:

13:borrar()
Borrarhuella

H u e l l a
Administrator

Figura 33. Diagrama de colaborare, cazul Baja

90
 Proiectare și Implementare

DiagramadeSecvenț ă:Modificare

Administrator Interfață Aplicație Ușor

Pulsarmodif.

Listarusuarios

Seleccionarusuario

Mostrarusuario

Mostrardatos

Modificareadatelor

Confirmare

OK

acu
tazila)r(

Figura 34. Secvenț a de Modificare

91
 Design și Implementare

Diagrama de Colaborare: Modificare

1:Modfi
4
S:elcatiț ziua
litor
8M
: odcifădae
tel
10O
:K
Interfață

7A
: fșiează dae
t
(Administrator) 9
C
:onrm
if are

2
Lsz:ia
tu
a
lio
tri
3: 5:șaiferzia
A u
lo
itr
6: 11 :
14:

13:

Ușor Aplicație

12a
:ctuazila()

Figura 35. Diagrama de colaborare, cazul Modificare

92
 Design și Implementare

Diagramadesecvenț ă:Creareutilizatornou

Interfață Aplicație :Usuario H u e l l a

Utilizator

Puslaara
tl

Așfiaiț o
frmualrul

n
o
rItdudcaeitl

Acceptă

aa
tl_usu)(

alta()

Aa
tlmprenă
t

Figura 36. Secvenț a de Înregistrare utilizator nou

93
 Proiectare și Implementare

DiagramadeColaborare:Utilizatornou

Pulsaralta
4:[Link] 2:Mostrarformulario
A accepta 6:

I n t e r f a z Aplicație

(U s u a r i o) 3:
11:

10: 7 :Al t a u s u a r i o
8:

Crearhuella
9a:a
tl)(

H u e l l a
Ușor

Figura 37. Diagrama de colaborare, cazul utilizator nou Alta.

94
 Proiectare și Implementare

Diagramadesecvenț ă:Înregistrareutilizatorexistent

A p l i c a t i e Ușor H u e l l a

Ușor

Pusla
A
ertxlsia
t.t
Mostrarformulario

n
o
rItducee
radae
otlr

A accepta

ata
l)(

altahuella

Figura 38. Secvenț a de înregistrare a utilizatorului existent

95
 Design și Implementare

DiagramadeColaborare:Utilizatorexistent

Pulsaralta
[Link] 2:Mostrarformulario
5 :Ac e p t a r 6:

Interfață A p l i c a t i e

3:
(U s u a r i o) 9:

8:

Crearhuella
7a:ta
l)(

H u e l l a

Figura 39. Diagrama de colaborare, caz utilizator existent

96
 Proiectare și Implementare

Diagramasecvenț ă:AutentificareUtilizator

Interfață Aplicație Ușurior

:Usuario

Puslarue
tcin
a
fite
r

Sociă
tld
iae
t

nIo
rtducee
ra
daetolr

OK

Pedirdedo

Ponerdedo

Autentificare

Figura 40. Secvenț a de Autentificare

97
 Proiectare și Implementare

Diagramadecolaborare:Autentificare

Puslaraue
tncitar
n
4
Iro
t:ducereadae
tolr C
2:ee
re
d
re
daet
5:OK A
c6e:e
d
regeutl
8:Ponerdedo 9:

Interfață Aplicație

3:
( U s u a r i o ) 7:
12:

11 : 1A
0:ucetiafne
irt

:Usuario

Figura 41. Diagrama de colaborare, cazul Autentificare

98
 Proiectare și Implementare

4.3.3 Visualización

În această secț iune vor fi prezentate funcț iile ș i interfaț a aplicaț iei luând în considerare
fiecare dintre ecranele acesteia.

Pagina principală

De pe pagina principal, se accede atât la sarcinile de administrare, cât ș i la

utilităț ideutilizator.

Figura 42. Pantalla página principal

99
 Design și Implementare

Alt utilizator nou

Pe această ecran se afiș ează un formular cu câmpurile pentru datele personale

cerin ț e pentru utilizatorii care doresc să se înscrie în sistem. De asemenea, se include
un câmp pentru fiecare dintre degetele ambelor mâini, gestionând expedierea...
imaginedigitalizatealeacestora.

Figura 43. Ecran înalt utilizator nou

100
 Design și Implementare

Alt utilizator existent

În această fereastră se afiș ează un formular cu câmpurile pentru datele personale

necesare pentru a-l identifica ca un utilizator existent. De asemenea, se include un
câmp pentru fiecare dintre degetele ambelor mâini, gestionând livrarea de la
imaginidigitalizatealeacestora.

Figura 44. Ecran Înalt utilizator existent

101
 Proiectare și Implementare

Autentificare utilizator

Pe această ecran verificăm că un utilizator care s-a înregistrat în baza de date

Date cu o imagine a amprentei, se autentifică corect. Comparăm
imagen “en vivo”, la que está sobre el lector, con la que está en la base de datos, y
prezentăm rezultatul.

Figura 45. Ecran Autentificare I

102
 Design și Implementare

După obț inerea datelor solicitate pe ecranul din figura 39, se iniț iază procesul
de autentificare. Dacă autentificarea are succes, se afiș ează imaginea degetului
utilizator, precum ș i diverse date referitoare la aceasta: calitatea imaginii, dimensiunea,

caracteristici dobândite în procesul de captură, nivel de coresponden ț ă cu

amprentă în baza de date, etc.

Figura 46. Ecran Autentificare II.

103
 Proiectare și Implementare

Autenticar Administrador

În această fereastră, administratorul este rugat să se autentifice pentru a controla

acces la paginile exclusive ale administratorului. Acest schemă de autentificare
utilizează propriul proiect despre dispozitivul de citire a amprentelor digitale.

Figura 47. Ecran Autentificare Administrator

104
 Design și Implementare

Administrator Superior

În această pagină, administratorul accesează lista utilizatorilor în aș teptare pentru

ser definitivate activate. Selectând un utilizator va fi activat
definitivînbazadedateaaplicaț iei.

Figura 48. Ecran AdministratorII

105
 Proiectare și Implementare

Următoarele sunt toate datele referitoare la utilizator, care constau în

bază de date, pentru ca administratorul, dacă doreș te,să confirme înregistrarea:

Figura 49. Ecran Înalt administrator II

106
 Proiectare și Implementare

Baja Administrator

Această pagină oferă o relaț ie a utilizatorilor înregistraț i în baza de date

date pentru ca administratorul să gestioneze posibile plecări. Procesul de plecare ș terge atât
datele personale, cum ar fi amprentele ș iș abloanelecare ar fi putut fi generate.

Figura 50. Ecranul de administrare scăzut

107
 Design și Implementare

Iată toate datele referitoare la utilizator, care sunt incluse în

bază de date, pentru ca administratorul, dacă doreș te, să confirme ș tergerea:

Figura 51. Ecranul redus Administrator II

108
 Proiectare și Implementare

Modifica Administrator

Pe această pagină se pot modifica datele personale ale unui utilizator înregistrat.
la baza de date, la apăsarea opț iunii de modificare de către administrator. În
Înprimulrând,sevizualizeazăopaginăcuutilizatoriiînregistraț i(figura49).

Figura 52. Ecran Modificare I

109
 Design și Implementare

Odată ce un utilizator este selectat, se accede la o pagină (formular) în care se

au toate datele lor. Pe această pagină se introduc modificările dorite, date
care ulterior vor fi actualizate.

Figura 53. Ecran Modificare II

110
 Validare

5. Validarea sistemului

Învalidareasistemuluinostrufolosimobazădedatecareconț ine50
imágenes de huellas dactilares, pertenecientes a 5 personas distintas de las que
vom avea o imagine pentru fiecare deget.

Fiecare imagine din baza de date este comparată cu propriul său ș ablon ș i cu celelalte.
49 ș abloane. Dacă compararea unei amprente cu un ș ablon al aceleaș i degete
rezultatul este de succes, se consideră o autentificare corectă, în caz contrar, suntem
ante un fals respingere. Dacă se obț ine o autentificare corectă comparând o
huellacuunaaltacarenuaparț ineaceluiaș ideget,neaflămînfaț aaceeacesenumeș te

o acceptare falsă.

Vomfolosivalorileprocentuluideautentificareș iprocentuluiderespingere
ca parametrii pentru estimarea fiabilităț iisistemului. Denotând la
numărul de respingeri false, ca număr respins, număr corect
autentificări corecte ș i numărul_fals al numărului de acceptări false
obț inem procentajul de autentificare ș i procentajul de respingere de la următoarea
forma

num_correctas
porcentaje de autenticación= 100
numărul corect + numărul fals

num_rechazadas
porcentaje de rechazo= 100
50

111
 Validare

Tabelul 2 prezintă valorile obț inute în sistemul dezvoltat în proiect:

%Autentificare % Rechazo
Utilizator 1 99.9 % 13,32 %
Utilizator 2 99.88 % 12.82 %
Utilizator 3 99,65 % 12,13 %
Utilizator 4 99,45 % 13,72 %
Utilizator 5 98,94% 10,41 %

Tabela 2. Procentajul de autentificare ș i procentajul de respingere

După cum se poate observa, valorile sunt optime (99.5 % medie).

112
 Concluzii

6. Concluzii

În acest proiect este inclusă o mică introducere în biometrie ș i în cadrul acesteia

al recunoa ș terea prin amprentă digitală. Poate că ar fi prea riscant să afirmi.
că în câț iva ani biometrea va fi implantată în atât de multe locuri încât ne va fi
familiarș ichiarcotidian.

De ș i pare ceva un pic futurist, mai ales gândindu-ne la alt tip de

recunoa ș tere precum cele bazate pe senzori de căldură sau geometrie facială,
tehnologia avansează cu paș i uriaș i, mai ales în ultimele decenii, ș i nu ar fi
rar să se înceapă prin implantarea în computere cu acces restricț ionat ș i cu
informaț ii foarte critice, cum ar fi în companii, bănci, etc. De atunci, cel care
oricine are un sistem biometric pe computerul său desktop există
un pas, sau un abis în funcț ie de unde avansează tehnologia.

În concret, pentru dezvoltarea acestui proiect, s-a achiziț ionat un cititor de amprente.
digitale cu mai puț in de 200 $.

În acest proiect a fost dezvoltată o aplicaț ie client-server care permite o

gestionarea eficientă a amprentelor digitale. Această aplica ț ie va permite realizarea
diverse studii despre această tehnologie într-un viitor apropiat, în special în
dezvoltalgoritminoideautentificarebiometrica.

113
 Manual de Administrator

ANEXA I: Manual de Administrator

Gestionarea amprentelor digitale

în format digital

Manual de Administrator
V1.0

Instalare

Bază de date

Pentru a instala baza de date pe sistemul pe care va lucra, trebuie să:

Instalarea MySQL

Primul pas este să obț ii o copie a unei distribuț ii MySQL.. Pentru dezvoltare
pentruprezentulproiects-autilizatceamairecentăversiunedisponibilăMySQL-3.23.49.

Pentru a instala distribuț ia, se dezarhivează într-un director gol ș i se execută

[Link]. Por defecto, MySQL pentru Windows este configurat să se instaleze în
'C:\mysql', ș i dacă se doreș te instalarea într-un alt director, se poate instala în
‘C:\mysql’primero, y luego moverla al destino deseado. Si se mueve a otro destino,
se va trebui să se indice localizarea fiecărui lucru adăugând o opț iune--bazat pe
demararea serverului.

114
 Manual de Administrator

De exemplu, dacă distribuț ia MySQL a fost mutată la 'D:\programas\mysql', se

deberá arrancarmysqldde la siguiente forma:

C:\> D:\programas\mysql\bin\mysqld –basedir D:\programas\mysql

‘ mysql – help’ arată toate op ț iunile care pot fi transmise lui mysql în cadrul
pornire.

În cele mai recente versiuni de MySQL, se poate crea un fiș ier 'C:\[Link]' care
configurează toate opț iunile implicite pentru serverul MySQL. Copiază fiș ierul
'\mysql\[Link]' ș i 'C:\[Link]' trebuie editate pentru a se adapta la configuraț ie.

Specificaț i toate „cărț ile” cu '/' în loc de '". Dacă se utilizează '", trebuie să
specifica de două ori, deoarece '\' este caracterul de evadare în MySQL.

Pentru a instala MySQL ca serviciu în Windows 2000, sistem de operare pe care

cesedezvoltăaplicaț ia,sevafaceurmătoarele:

C:\> C:\mysql\bin\mysql-nt –install

Pentru a porni ș i opri serviciul MySQL, se folosesc următoarele comenzi

respectiv

C:\> NET ÎNCEPE mysql (iniciar MYSQL)

C:\> NET OPRIRE mysql (parar MYSQL)

Odată instalat, se va putea "porni" utilizând SMC (Managerul de Servicii)

Control) care se află în panoul de control; sau folosind comanda NET START
[Link]ă se cere vreo op ț iune, aceasta trebuie specificată ca „ Startup
parameters”en la SMC antes de iniciar el servicioMySQL. Una vez que se esté

115
 Manual de Administrator

executând, mysqld-nt nu poate fi oprit folosind Mysqladmin, din utilitarul SMC sau
prin intermediul comenzii NET STOPmysql.

Dacă nu vrei să porneș ti mysql-nt ca un serviciu, se va porni în următorul mod

forma:

C:\> C:\mysql\bin\mysqld-nt --standalone

o
C:\> C:\mysql\bin\mysqld-nt –independent --debug

După ce a fost instalat corect MySQL, va trebui să adăugăm baza noastră de date pentru ca
poate fi utilizată de aplicaț ie. În mod concret, este vorba despre un director numit
basca se află în directorul data în locaț ia de instalare a MySQL:

D:\mysql\date\baza

Această bază de date conț ine cele trei tabele de care are nevoie aplicaț ia noastră pentru a-ș i

funcionamiento:usuarios,huellas,administradores.

Server Apache

Instalare Apache

Software-ul Server Apache este disponibil pe site-ul Grupului Apache ș i

în zeci de site-uri mirror din întreaga lume. Trebuie obț inută o distribuț ie
binaria gratuită de Apache, apache<versiune>, disponibilă pe pagina sa oficială
[Link]

116
 Manual de Administrator

Executăm fiș ierul binar ș i urmăm ecranele tipice de instalare a unei

aplicaț ie Windows, alegând în timpul acestui proces directorul de instalare care
maimultneinteresează.

Pentruaporni,opriș ireporniserverul,vomtastaurmătoarele:

C:\<dir_apache>\[Link] (începe apache)

C:\<dir_apache>\[Link] -k oprire (oprire apache)
C:\<dir_apache>\[Link] - k restart (reiniciază apache)

Vom folosi opț iunea de repornire pentru a avea efect orice modificare realizată în
fiș ierele de configurare Apache, fără a fi necesară oprirea ș i reluarea
serverul.

Pentru a testa că serverul nostru func ț ionează, vom scrie în browser-ul nostru
[Link] i vom verifica că ne afiș ează pagina de bun venit
de Apache. Parametrul port va fi implicit 8080, putând fi modificat în
fiș [Link].

Instalare SSL

În primul rând, trebuie să avem modulele mod_sslyOpenSSL, pe care le putem obț ine în
sitio[Link]

Pentru instalarea SSL pe Apache va trebui să introducem o serie de modificări în

fiș ierulsă[Link]îldescriemmaijos:

În primul rând, trebuie adăugate următoarele parametrii:

117
 Manual de Administrator

Portul 443
Ascultă 80
Ascultă 443
NumeServer [Link]

Pentru a verifica că portul 443 funcț ionează corect, trebuie să scriem în nostru
navegator[Link]

Trebuie să dezarhivaț i fiș ierulApache<versiune>modssl<versiune>.zipîntr-un

nuevo directorio. Copiar los [Link] directorio
Apache\openssl\bin în directorul Windows\System în cazul Win9x sau
WINNT/System32 în cazul WinNT/2000.

Pentru crearea certificatului de probă, trebuie urmate paș ii:

openssl req -config [Link] -new -out [Link]

Acesta creează un certificat de cerere de semnătură ș i o cheie privată. Când întrebi
pentru "Numele comun (de exemplu, numele tău de domeniu)" trebuie să se ofere exact

nume de domeniu (de ex. [Link]). Certificatul aparț ine numelui

de la server ș i browserele emit un avertisment de neconformitate dacă numele nu
coincide.

openssl rsa -in [Link] -out [Link]

Aceasta elimină parola cheii private. Trebuie să înț elegi ce înseamnă.
esto; [Link] trebuie să fie doar lisibil de serverul Apache ș i de
administrator. Trebuie ș ters fiș ierul .rnd deoarece conț ine informaț ii entropice
pentru crearea cheii ș i ar putea fi folosit pentru atacuri criptografice împotriva cheii tale
privată.

118
 Manual de Administrator

openssl x509 -in [Link] -out [Link] -req -signkey [Link]

Acestlucrucreeazăuncertificatcusemnăturăproprie(să-lnumimuncertificatdecasă)care

poț ifolosi până obț iiunul de valabilitate oficială provenit de la o autoritate

certificată..

Apoi creaț i directorul <dir-apache>\conf\ssl ș i mutaț i fiș ierele

[Link] el. Copiaț i toate fiș ierele distribuț iei de
Apache_mod_sslen directorul de instalare original al Apache.

Localiza directivele LoadModule în fiș ierul [Link] ș i adaugă următoarele la

finalulcelorexistente:

LoadModule ssl_module modules/mod_ssl.so

Adăugaț i modul mod_ssl.c

Înplus,trebuieadăugaturmătorullucrulasfârș itulfiș [Link]:

SSLMutex sem
SSLRandomSeed startup builtin
SSLSessionCache niciunul

SSLLog logs/[Link]
SSLLogLevel informaț ii

<VirtualHost [Link]>
SSLEngine Activat

SSLCertificateFile conf/ssl/[Link]
SSLCertificateKeyFile conf/ssl/[Link]
</VirtualHost>

119
 Manual de Administrator

Porniț i serverul din linia de comandă cu scopul de a vedea mesajele de

eroare care împiedică pornirea Apache. Dacă ceva nu funcț ionează, Apache scrie mesaje
semnificative pe ecran ș i, sau în fiș ierele [Link] ș i [Link] din director
Apache\logs.

Server Tomcat

Instalare Tomcat

Instalarea Tomcat necesită să aveț i instalat anterior JRE (Java Runtime)

Mediu) conform JRE 1.1 sau superior, inclusiv orice sistem cu
platforma Java2. Se necesită un compilator Java, cum ar fi cel inclus în JDK (Java
Kit de dezvoltare)1.1 sau superior.

După instalarea acestui software pe computerul nostru, trebuie să obț inem fiș ierul binar
de versiune potrivită dejakarta-tomcat<versiune>. În proiect se utilizează
jakarta-tomcat3.3.1.

Se execută binarul ș i se instalează serverul în directorul dorit. Apoi

se adaugă variabilele de mediu java, pentru ca Tomcat să le poată utiliza. În
cazul nostru se va face următoarele:

Pc-ul meu -> Proprietăț i -> Avansat -> Variabile de mediu

în variabilele sistemului se adaugă variabilele:

JAVA_HOME - d:\jdk
TOMCAT_HOME - d:\jakarta-tomcat

120
 Manual de Administrator

Pentru a porni ș i opri serverul, se va deschide o fereastră DOS ș i se va continua cu

următoareaformă:

D:\jakarta-tomcat\bin\[Link] (iniț iere Tomcat)

D:\jakarta-tomcat\bin\[Link] (opreș te Tomcat)

Pentru a verifica că func ț ionează, se poate accesa [Link]

verificând că pagina de bun venit Tomcat este afiș ată. Parametrul port
va fi implicit 80, putând fi schimbat în fiș ierul de configurare Tomcat
[Link],pentruanuaveaconflictecuserverulwebApache.

Având serverul instalat corect, se află în situaț ia de a găzdui

aplica ț ie. Pentru desfă ș urarea sa, aplica ț ia trebuie să fie situată într-un singur fi ș ier

denominadoWeb archive (war). În cazul nostru, aplica ț ia este "împachetată"

înfiș ierul'[Link]'.

Tomcat permite ca fiș ierul .war să rămână pur ș i simplu în director.

<directorio_de_inicio_tomcat>/webapps. Când se reporneș te Tomcat, fiș ierul .war
se „desempaqueta” ș i se validează, iar aplicaț ia noastră devine disponibilă. Aceasta este ceea ce

se trebuie făcut [Link].

Următorul pas este să indicăm aplicaț iei noastre locul unde am instalat
Tomcat, pentru asta vom adăuga contextul în fiș ierul nostru [Link], care se
găseș te în directorul WEB-INF al aplicaț iei noastre.

Aplicaț ia foloseș te directorul unde avem instalat Tomcat, din acest motiv
introducând o variabilă care să indice acest directoriu, obț inând o aplicaț ie
independentdeloculundeseinstalează.

121
 Manual de Administrator

Cu parametrul 'director', indicăm calea completă de la directorul de

instalarea Tomcat-ului, până la directorul unde vor fi stocate amprentele ș i
ș abloane(încărcaț i).

Vom introduce parametrul 'directorio' în [Link] ș i îl vom ini ț ializa la

directorul instalaț iei noastre, terminându-se în directorul upload, unde se
vorstocaamprenteș iș abloane,înurmătoareaformă:

<context-param>
<param-name>directorio</param-name>
<param-value>D:/<dir_tomcat>t/webapps/proyecto/upload/
</param-value>
</context-param>

Înlănț uirea Apache cu Tomcat

Pentru a lega serverul web Apache cu containerul de servleturi Tomcat

trebuiesăinstalămmodululmod_jkîndirectorulcorespunzătoralApache.

Am descărcat fiș ierul mod_jk.dll de la adresa [Link]

copiamos subdirectorul modules în directorulApache.

Când executezi Tomcat, se creează automat fi ș ierul c:\<dir-

tomcat>\conf\[Link], îl copiem cu un alt nume p.e.c:\ <dir-
tomcat>\conf\[Link].
Aceasta este necesară pentru că o vom modifica, dar Tomcat o suprascrie de fiecare dată.
ce ar începe cu ceea ce am pierde modificările dacă nu le redenumim.

122
 Manual de Administrator

Din noul fiș ier trebuie să eliminăm toate referinț ele la JServMounty ș i să le schimbăm cu
JkMount (nu se pot amesteca JServymod_jk). De asemenea, la începutul fiș ierului
trebuiesăpunemurmătoarelelinii:

LoadModule jk_module libexec/mod_jk.dll

AdaugăModul mod_jk.c
JkWorkersFile c:\<dir-tomcat>\conf\[Link]
JkLogFile c:\<dir_apache>\logs\mod_jk.log
JkLogLevel avertizare

JkMount /*.jsp ajp13

JkMount /servlet/* ajp13
JkMount /otherworker/*.jsp remoteworker

Înceledinurmăadăugămlasfârș itulfiș ieruluideApacheconf\[Link]:

include c:\<dir_tomcat>\conf\[Link]

prin aceasta indicăm luiApache noile directive pentru servlete.

Deja avem instalat modulul. Pornim mai întâi Tomcatul.
continuareApache; în acest din urmă moment, la pornire, trebuie să apară un mesaj care să indice

cefolosimmod_jk.dll(cevasimilarcumod_jk.dllînfuncț iune).

Trebuie să avem în vedere că Tomcat trebuie să fie întotdeauna pornit înainte de Apache, ș i dacă

se opreș te, trebuie să opreș ti Apache ș i să reporneș ti Tomcat mai întâi.

În continuare se descrie ceea ce conț ine fiecare director din aplicaț ia noastră:

Directorul Raiz
Conț ine paginile .html ale aplicaț iei noastre, printre care se află pagina
deinicio.

123
 Manual de Administrator

Director JSP
Aș a cum sugerează ș i numele său, conț ine paginile .jsp, care împreună cu paginile
.htmlformeazăinterfaț aaplicaț ieinoastre.

Director de Resurse
Aici se păstrează fiș ierele (imagini, butoane, iconiț e etc.) care vor fi folosite în
paginialeaplicaț iei.

DirectoriiÎncărcare
Aici este locul unde se transferă imaginile amprentelor utilizatorilor. În plus
menț ineț i ș abloanele generate de aplicaț ie pe baza imaginilor de amprente
digitalizate.

DirectorAdmin
Acesta este un subdirectoriu al Uploady în care vom păstra ș ablonurile de
administratoricareauprivilegiipentruagestionaaplicaț ia.

Directoriu WEB-INF
Aici este fiș ierul descriptor de desfăș urare [Link], care este utilizat pentru configurare
losservletsy alte resurse care fac parte din aplicaț ia web.
În plus, include două subdirectoare, ellibyclasses:

Directoriolib
Conț ine fiș ierele .jar. Clasele din orice fiș ier .jar care se află în
acest director este pus automat la dispoziț ia încărcătorului de clase fără
trebuie să fie enumerate explicit în calea claselor.

Aici este locul unde vom plasa bibliotecile de clase pentru accesul la cititorul de amprente
([Link]) ș i clasele care ne vor permite să accesăm MySQL din paginile
([Link]).

124
 Manual de Administrator

Directorioclaselor
Acest director conț ine servlets ș i alte clase. Aici se pot găsi pachetele
ce utilizat în aplicaț ie, în cazul nostru pachetuljspSmartUpload(com) ș i
claseledezvoltatepentruamodelaaplicaț ia:utilizator,amprentăș iadministrator.

JspSmartUpload

Toate fi ș ierele jspsmartUpload vin într-un fi ș ier comprimat

[Link]. Se descarcă fiș ierul comprimat ș i se decojeș te într-un
directoriu temporar asigurându-ne că structura directorilor este intactă. Dacă
de exemplu, se extrage fiș ierul în '/temp', ar trebui să avem următoarele:

Pentru a putea folosi acest pachet în paginile JSP ale aplicaț iei noastre, va trebui
ce să localizezi în directorul aplicaț iei. În concret, structura directorului
deTomcatnos indică că trebuie să-l situăm în directorulWEB-INF\classe.

Lector de amprente

Pentru a instala hardware-ul de captură a amprentelor care este utilizat în proiect se

introduce CD-ROM-ul care vine cu cititorul ș i continuăm cu meniul de instalare,
selectând opț iuneaToolkit de dezvoltare.

125
 Manual de Administrator

Instalarea va copia fiș ierul '[Link]' în directorul d:\winnt\system32

hard disk-ul nostru, care corespunde cu directorul de Windows 2000. Aceasta
fiș ierul este cel care conț ine codul care implementează tot ce se poate face cu
ellector:capturarhuella,salvarhuella,compararhuella,generarplantilla,...

API-ul Java care este utilizat în aplicaț ia noastră se află în fiș ierul jar '[Link]',
ce nu fiul mai multce un ansamblul de cursuri împachetate

126
 Comenzi de creare a tabelelor

Anexa II: Comanda de creare a tabelelor

Pentru crearea tabelelor bazei de date, se include mai jos o serie

de comenzi SQL, utilizând comenzile SQL92 (ANSI SQL) acceptate de
MySQL, s-ar decide să migreze aplicaț ia la o altă bază de date aceste comenzi ne
ar facilita lucrurile. Pe de altă parte, MySQL suportă SQL92, deș i îi adaugă câteva
extensii.

În cazul utilizării unui sistem de gestionare a bazelor de date relaț ionale, la comenzile
de crea ț ie se va trebui să se alăture comenzile de autorizări ș i vizualizări
pertinente, care vor fi specifice mediului de lucru.

Pentru a garanta integritatea referenț ială, se ț ine cont că nu se pot

schimbaț icheileprincipale.

Tabela Administratori

CREAȚITABELAADMINISTRATORI
(
ID_ADMINISTRADOR INTEGER PRIMARY KEY,
NUME VARCHAR(15) NOT NULL
PLANTILLAVARCHAR(15) NOT NULL
);

127
 Comenzi de creare a tabelelor

Tabel Utilizatori

CREAȚITABELULUTILIZATORI

(
ID_UTILIZATOR INTEGER CHEIE PRIMARĂ,
NUME VARCHAR(50) NOT NULL,
DIRECCION VARCHAR(50),
CP ÎNTEGER
LOCALITATE VARCHAR(20)
PAIS VARCHAR(15),
ALTĂ CHAR(1)
);

Tabla Urme

CREAȚITABELULHUELLAS
(
ID_HUELLAINTEGER PRIMARYKEY,
MANO CHAR(1) NOT NULL,
DEDO CHAR(1) NOT NULL,
PLANTILLAVARCHAR(15) NOT NULL,
Id_usuario INTEGER,
CONSTRÂNGERE CHEIE EXTERNĂ (Id_usuario) REFERINTE
USUARI(ID_UTILIZATOR) LA Ș TERGERE CASCADĂ,
);

128
 Bibliografie

Bibliografie

Damon Hougland,Aarón Tavistock. “Ghid esenț ial JSP”. Pearson Educaț ie

S.A, Madrid, 2002.

[2] Phil Hanna. “JSP. Manual de referinț ă”. McGraw-Hill, Madrid, 2002.

John Zukowski.”Programare în Java 2”. EdicionesAnaya Multimedia,

Madrid, 1999.

[4] Rich Bowen & Ken Coar, ServidorApache al Descubierto. Pearson Educación,
S.A. Madrid, 2000.

[5] Lemay, Laura, “Învăț ând HTML4 pentru web într-o săptămână”. Prentice Hall,
Mexic, 1998.

Juan Carlos Orós, “Design de pagini web interactive cu JavaScript”. RA-MA

Editorial, Madrid, 1998.

[7] Graham Hamilton, Rick Cattell, Maydene Fisher, „Acces la baza de date JDBC cu
Java - Un tutorial ș i referinț ă annotată”. Addison-Wesley, Massachusetts,
1997.

Herbert Schidt, “Java 2 - Manual de Referinț ă”. McGraw-Hill, Madrid, 2001

Agustín Froure Quintas, “Java Server Pages – Manual de utilizare ș i tutorial”. RA-
MA, Madrid, 2002

129
 Bibliografía

Fundamentele dezvoltării web cu

JSP”.Anaya Multimedia, Madrid, 2002

[11] [Link], J. Rumbaugh, I. Jacobson, “Limbajul Unificat de Modelare.

Addison Wesley, Madrid, 1999.

130
 Direcții web

Direcț ii web

[Link] web

[Link] în spaniolă. Forumuri de dezbatere

[Link] în Spaniolă

[Link] salvadoriană de programatori

MySQL

[Link] oficial despre Java ș itehnologii

[Link] iere

[Link]

[Link] iadeBiometricăInformaticăSpaniolă

[Link]
Comunitatea de Biometrie

131
 Indice de Figuri

Indicele figurilor

Figura 1. Diagrama Sistemului de Recunoaș tere Biometrică .............................. 13

Figura 2. Relaț ia între FAR, FRR ș i ERR ...................................................... 14
Figura 3. Amprentă digitală cu minucii ............................................................ 16
Figura 4. Amprenta originală ș i amprenta normalizată ................................................ 24
Figura 5. Amprenta orientată ș i câmpuri realiniate ............................................ 25
Figura 6. Variaț ii ale amprentei ș i regiunii importante ...................................26
Figura 7. Imagine filtrată ș i imagine binară .................................................... 27
Figura 8. Imagine după primul filtru profilator ș i imagine
după al doilea filtru profilator cu mască spaț ială ......... 28
Figura 9. Imagine după subț iere ș i eliminare de
imperfecț iuni ș i model de detalii după procesul de
eliminarea seturilor ................................................................... 29
Figura 10. Patron de minucii ........................................................................... 30
Figura 11. Alinearea crestei de intrare ș i a crestei ș ablon ................. 32
Figura 12. Actori ai sistemului ........................................................................... 40
Figura 13. Cazuri de utilizare a Administratorului ...................................................... 41
Figura 14. Cazuri de utilizare Utilizator ....................................................................... 44
Figura 15. Model Entitate–Relaț ie ............................................................... 48
Figura 16. Model de server pentru documente statice ................................ 53
Figura 17. Conț inut dinamic prin scripturi CGI ................. 55
Figura 18. Aplicaț ii dinamice folosind servlete, JSP ș i J2EE .................. 56
Figura 19. Interfaț a JDBC .................................................................................. 72
Figura 20. Despliegue de la aplicación ............................................................. 74
Figura 21. Pachete ale aplicaț iei ................................................................. 75
Figura 22. Clase Auxiliare .............................................................................. 76
Figura 23. Clase de domeniu ............................................................................ 77
Figura 24. Clase Interfaț ă .................................................................................. 78

132
 Indice de Figuri

Figura 25. ClasesJspSmartUpload................................................................... 81

Figura 26. Secvenț a de Autentificare Administrator ....................................... 83
Figura 27. Diagrama de colaborare, cazul Autentificare Administrator ...... 84
Figura 28. Secvenț a de Vizualizare ............................................................. 85
Figura 29. Diagrama de colaborare, caz Visualizare ............................. 86
Figura 30. Secvenț a de Administrator Superior ................................................... 87
Figura 31. Colaborare, caz Administrator Superior ....................................... 88
Figura 32. Secvenț a de Ieș ire ............................................................................ 89
Figura 33. Diagrama de colaborare, cazul Baja ............................................ 90
Figura 34. Secvenț a de Modificare .............................................................. 91
Figura 35. Diagrama de colaborare, cazul Modificare ............................. 92
Figura 36. Secvenț a de Alta utilizator nou
Figura 37. Diagrama de colaborare, caz utilizator nou .................... 94
Figura 38. Secvenț a de înregistrare utilizator existent .............................................. 95
Figura 39. Diagrama de colaborare, cazul utilizator existent .............. 96
Figura 40. Secvenț ă de Autentificare .................................................................. 97
Figura 41. Diagrama de colaborare, caz Autentificare ................................. 98
Figura 42. Pagina de start a ecranului ................................................................ 99
Figura 43. Ecran Înalt utilizator nou ............................................................ 100
Figura 44. Ecran Înalt utilizator existent ........................................................ 101
Figura 45. Ecran Autentificare I ................................................................. 102
Figura 46. Ecran Autentificare II ................................................................ 103
Figura 47. Ecran Autentificare Administrator ............................................... 104
Figura 48. Ecran înalt administrator I ......................................................... 105
Figura 49. Ecran Înalt administrator II ...................................................... 106
Figura 50. Ecran jos administrator I ........................................................ 107
Figura 51. Ecran josAdministrator II.................................................... 108
Figura 52. Ecran Modificare I ........................................................................ 109
Figura 53. Ecran Modificare II

133
 Indice de Tabele

Índice de Tablas
Tabela 1. Candidaț i pentru Entitate ș i Relaț ie ....................................................... 47
Tabela 2. Procentajul de autentificare ș i procentajul de respingere ...................... 110

134