Proiectarea Unei Aplicatii Informatice a Unei Activitati Bancare Privind Sistemul de Plati

Proiectarea Unei Aplicatii Informatice a Unei Activitati Bancare Privind Sistemul de Plati

Byadmin ianuarie 1, 2024

Introducere

În lumea contemporană este o permanentă confruntare a băncilor cu schimbările majore pe care le implică dezvoltarea rapidă a tehnologiei informatice și a telecomunicațiilor, iar rețelele de calculatoare fac posibilă extinderea căilor de acces la serviciile bancare în orice zonă, indiferent de moment.

Relația dintre bancă și clienți a fost afectată de evoluția tehnologiei bancare, ceea ce poate fi evidențiat și prin modelul home-banking (bancă la domiciliu), care recurge la folosirea unei serii de instrumente bazate pe tehnologie și informatică, prin care este posibilă efectuarea, în principal a trei categorii de operațiuni bancare: gestionarea mijloacelor de plată, distribuire de credite si gestionarea economiilor.

Banca la domiciliu (home-banking) cuprinde în aria de acțiune serviciile financiare efectuate din exteriorul unității bancare.

Avantajele oferite, legate de facilitate și conveniență în derularea legăturilor, rapiditate, securitate și cost determină ca acest serviciu să fie agreat și solicitat de un număr tot mai mare de clienți.

În contextul încercărilor băncilor de a îmbunătăți standardul relației bancă-client, internetul ocupă, actualmente, locul central. El asigură, pentru toți clienții băncii, proximitatea geografică și contactul direct, caracteristici definitorii pentru sistemul bancar tradițional.

Internet-banking permite clienților aflați la distanță să realizeze operațiuni precum cele cu ordine de plată, vânzări, cumpărări de valută, creare și alimentare sau retragere de depozite, precum și autorizări sau verificări ale operațiunilor deja efectuate etc.

Principalele atu-uri ale internet-ului constau în: confort, cost scăzut, accesibilitate și posibilitatea comparării ofertelor. Acestea sunt elementele ce îl vor impune, în viitor, în domeniul bancar. Unul dintre argumentele ce pot fi aduse în sprijinul acestei afirmații este acela că, între cele mai utilizate produse bancare, pe internet este cartea de credit, care a devenit instrumentul uzual în marea majoritate a tranzacțiilor.

Pe fundalul dezvoltării informaticii și telecomunicațiilor, inclusiv a implementării acestora în mediul bancar, s-a ajuns la crearea unei noi tehnologii denumită generic „ tehnologia de transfer a informațiilor”.

Conceptul de „electronic banking” are un conținut mai larg, incluzând preluarea și procesarea informației bancare, ca și efectuarea operațiunilor de tipul decontărilor.

Între avantajele oferite de electronic banking se pot enumera următoarele:

efectuarea de plăți în conturi de la bănci aflate în străinătate;

vizualizarea rapidă a tranzacției;

un sistem de comunicare performant;

obținerea extraselor de cont și a altor documente justificative;

transmiterea plăților prin rețeaua de calculatoare;

securitate a tranzacțiilor prin criptare și compresie date;

posibilitatea realizării de plăți interne sau externe periodice, respectiv standard

posibilitatea preluării datelor fie manual, fie automat, din alte aplicații ale clientului;

autorizarea plății prin acces ierarhizat la program.

Problema dificilă pusă de folosirea tehnologiei „ electronic banking” se leagă însă, de asigurarea securității informațiilor și a elementelor ce tranzitează rețeaua.

Astfel trebuiesc avute în vedere cele trei elemente definitorii legate de securitate: autentificarea electronică, confidențialitatea electronică și integritatea datelor.

Autentificarea electronică este un proces de verificare a identității deținătorului sistemului de deservire bancară la distanță și a autenticității tranzacțiilor electronice transmise/primite prin intermediul acestuia printr-o metodă care asigură un nivel adecvat de siguranță privind identitatea utilizatorului și autenticitatea tranzacțiilor (ex. semnătură digitală, identificator și parolă, criptare simetrică, utilizarea cheilor de sesiune de o singură dată, metode biometrice etc.)

Confidenialitatea datelor implică in mod automat ascunderea lor, acestea neputând fi ușor accesibile (sau chiar deloc) de către alți utilizatori neautorizați ai sistemului de plată respectiv.Pentru a se respecta integritatea datelor, acestea trebuie să fie complete, corecte și actualizate.

1.Descrierea activității bancare privind sistemul de plăți

Sistemul de plăți este definit ca fiind un set de aranjamente care privesc descărcarea unor obligații ce sunt asumate de către agenții economici (incluzând chiar și persoanele fizice) ca urmare a tranzacțiilor economice cu bunuri (inclusiv a tranzacțiilor cu active financiare) sau cu servicii.[1]

Sistemele de plăți au o funcție dublă de intermediere a operațiunilor de plăți dar și de garantare a operațiunilor privind plățile. Sistemele de plăți constituie o parte a sistemului financiar. Elementele componente care aparțin unui sistem de plăți sunt reprezentate de instituțiile care se ocupă cu furnizarea de servicii de plată, de multiplele forme de creanțe care sunt transferate, de tipurile și mijloacele de transfer și de mesajele și canalele prin care se realizează comunicația.

Activele care circulă în cadrul sistemului de plăți (mai exact „banii”) sunt reprezentate de creanțe asupra guvernului (moneda metalică) și asupra băncii centrale (bancnotele) sau asupra instituțiilor bancare (depozitele bancare). Aceste active mai sunt cunoscute și sub denumirea generică de mijloace de decontare. Moneda poate fi o creanță pentru cel ce o deține dar și o datorie pentru cel ce a emis-o.[2]

Absolut toate tranzacțiile, fie că vorbim despre achiziția bunurilor sau despre achiziția activelor financiare și a serviciilor, (însa presupunem că acestea nu includ trocul) care se bazează atât pe transferul de bunuri, de active financiare sau de servicii cât și pe transferul de fonduri care pot fi numerar (bancnote precum și monedele confecționate din metal) sau depozite la instituțiile de credit.[3]

Sistemele de plăți au reprezentat un factor foarte important în special în ultimele decenii, datorită creșterii valorii tranzacțiilor comerciale și celor financiare dar și a volumului lor (pe piețele monetare și valutare), in contextul globalizărilor si a circulației libere a capitalurilor.

Și la nivel național, concomitent cu aderarea României la Uniunea Europeană și cu creșterea economiei, s-a înregistrat o importantă creștere a volumului de tranzacții de plată, precum și a interesului operatorilor economici pentru existența unor sisteme de plăți eficiente și sigure.

În fundamentul Memorandumului de finanțare PHARE 2000, încheiat de Guvernul României și Comisia Europeană la data de 6 noiembrie, anul 2000, s-a dat startul la Proiectul RO 0005.02 – Sistemul Electronic de Plăți, s-a derulat cu sprijinul atât financiar cât și tehnic al Uniunii Europene, iar finanțarea a fost asigurată din surse PHARE și din surse interne. Acest proiect fiind finalizat la data de 14 martie 2005.[4]

Sistemul Național Electronic de Plată (SNEP), fiind cunoscut și sub numele de www.ghișeul.ro, reprezintă sistemul prin care românii pot să-și achite taxele și impozitele online.

Sistemul Ghișeul.ro este administrat, întreținut și folosit de Centrul Național de Management pentru Societatea Informațională (CNMSI), instituție care se află în subordinea Ministerului Comunicațiilor și Societății Informaționale (MCSI). Platforma de plăți online este gratuită și pusă la dispoziție de către Asociația pentru Plăți Electronice din România (APERO). Aceasta fiind o asociație ce promovează plățile electronice și care este formată din 14 cele mai importante bănci, scheme internaționale de card-uri VISA precum și MaterCard si procesatori și furnizori de tehnologie.[5]

Putem spune că în istoria sistemului financiar-bancar românesc, un moment de referință îl reprezintă chiar implementarea sistemului electronic de plăți.

1.1 Descrierea activității bancare privind sistemul de plăți

Pentru realizarea îndeplinirii obiectivului de modernizare a infrastructurii sistemelor de plăți în anul 2004, eforturile Băncii Naționale a României au fost îndreptate în direcția finalizării proiectului de implementare a sistemului electronic de plăți, structurat pe următoarele componente :

Sistemul de decontare pe bază brută în timp real-ReGIS;

Casa de compensare automată-SENT;

Sistemul de înscriere și decontarea operațiunilor cu titluri de stat-SaFIR ;

Sistemul de salvare și recuperare a pierderilor în caz de dezastre, introdus după evenimentul din SUA din data de 11 septembrie 2001.

Banca Națională a României este proprietar și administrează sistemul ReGIS precum și sistemul SaFIR, sistemul SENT fiind administrat de TRANSFOND-S.A. Banca Națională a României are control absolut asupra sistemelor ReGIS si SaFIR, stabilește regulile sistemului și procedurile necesare care asigură funcționarea acestora, și supraveghează în același timp participanții acestor sisteme. Operarea tehnică a sistemului a fost transmisă de Banca Națională a României către TRANSFOND-S.A., care trebuie să asigure în principal funcționarea tehnică fără perturbări a sistemelor și mentenanța acestora.

O dată cu aceste sisteme s-a urmărit implementarea celor mai avansate standarde internaționale în domeniu, astfel încât, la momentul aderării, sistemul românesc de plăți să fie pe deplin compatibil cu cele existente în zona comunitară.

Sistemul ReGIS – sistemul de decontare cu bază brută în timp real

Sistemul de decontare brută în timp real, denumit ReGIS, a intrat în funcțiune la 8 aprilie 2005. Acesta procesează plățile de mare valoare și pe cele urgente. În prima lună de operare, media zilnică a operațiunilor procesate s-a ridicat la peste 3800 de operațiuni, reprezentând peste 90% din totalul fondurilor care tranzitează sistemele de plăți românești.

PrinReGIS se derulează on-line :

instrucțiuni de plată inițiate de bănci, în numele clienților sau în nume propriu;

pozițiile nete rezultate în cadrul altor ședințe de compensare;

transferul de fonduri aferent tranzacțiilor cu titluri de stat.

Sistemul de decontare brută în timp real al TransFonD funcționează astfel:

Clientul prezintă ordinul de plată la bancă;

Banca îl introduce în sistemul de plăți electronice;

Dacă banca are suficiente lichidități în cont la BNR, ordinul de plată este procesat, fiind creditat contul băncii beneficiare;

Banii intră în același timp în contul beneficiarului.

Există trei opțiuni posibile pentru rețeaua de interconectare a băncilor participante la ReGIS :

utilizarea rețelei SWIFT;

Swift este sigla unei societăți care și-a propus încă de la început modernizarea sistemelor de plăți internaționale și a relațiilor bancare în general prin implementarea unor programe informatizate.

utilizarea unei rețele interbancare existente;

dezvoltarea unei noi rețele interbancare.

Avantajul alegerii rețelei SWIFT este că interfețele există deja în băncile comerciale, deci nu necesită cheltuieli în plus și nici eforturi de instruire a personalului. De altfel, multe dintre băncile românești și-au integrat propriile aplicații informatice cu serverul SWIFT, pentru a asigura prelucrarea (semi)automată a tranzacțiilor.

Sistemul SENT – casa de compensare automată

În mai 2005 a intrat în funcțiune și cea de-a doua componentă a sistemului electronic de plăți, respectiv casa de compensare automată, denumită SENT. Acest sistem, al cărui proprietar este TransFonD S.A.., procesează zilnic aproximativ 200 000 de plăți interbancare de mică valoare. Deși în privința volumului tranzacțiilor, casa de compensare automată procesează un număr de plăți incomparabil mai mare față de ReGIS, valoarea fondurilor, atât cea cumulată, cât și cea netă se ridică la doar câteva procente din totalul fondurilor care tranzitează sistemele de plăți românești.

Practic, o dată cu intrarea în funcțiune a casei de compensare automată, toate operațiunile interbancare tip transfer credit sunt efectuate electronic. Singurele instrumente care sunt procesate în continuare pe suport hârtie sunt cele de debit, respectiv cecurile, cambiile și biletele la ordin. În fiecare zi bancară se derulează trei ședințe de compensare ACH.

Sistemul SaFIR – sistemul de înregistrare și decontare a operațiunilor cu instrumente financiare

Ultima componentă a Sistemului Electronic de Plăți, este reprezentată de sistemul SaFIR, implementat începând luna August a anului 2005.

Sistemul se ocupă cu ținerea evidenței emisiunilor de titluri care se află în circulație (funcție de registru), și garantează decontarea tranzacțiilor cu titluri de stat cu asigurarea normei "livrare contra plată", aceasta va realiza funcțiuni complementare, de exemplu evaluarea zilnică a emisiunilor sau calculul automat al comisioanelor etc.[4]

Prin intrarea în funcțiune a sistemului electronic de plăți, România a reușit, din punct de vedere tehnologic, să recupereze diferențele față de sistemele europene similare, performanțele fiind primite cele mai bune în domeniu. Sistemul implementat răspunde nu numai unor cerințe de performanță deosebite, dar și celor de securitate ridicată a tranzacțiilor și datelor.

În ceea ce privește card-urile, ca în fiecare țară, și în România procesul de emitere și acceptare a acestora a creat un cadru tranzacțional în care, în ciuda unor dificultăți logistice, toate părțile au avut de câștigat: clienți, comercianți, bănci. Decontările între bănci și cele între agenții economici au pășit într-o fază de performanță care contrastează cu maniera greoaie și învechită în care se derulează plățile pe suport hârtie

Anul 2005 a reprezentat un an bun pentru băncile emitente de card-uri. Putem vorbi de creșteri spectaculoase la nivelul numărului și valorii tranzacțiilor. Ceea ce este cel mai important în opinia noastră reprezintă faptul că putem observa, fără îndoială, o schimbare pozitivă a deținătorilor de card-uri bancare în sensul creșterii utilizării acestora pentru plăți la comercianți. În plus, am fost martori la apariția primului card inteligent românesc și la prima tranzacție în România a card-urilor cu microcip.

Figura 1.1.Evoluția comerțului electronic cu plată online(euro).[7]

În figura de mai sus avem o reprezentare a evoluției comerțului electronic cu plată online începând din anul 2009 până în anul 2012.

După cum putem vedea și în figura acesta a crescut de la 50 de milioane de utilizatori până la 250 de milioane de utilizatori in doar 3 ani, lucru îmbucurător pentru cei care implementează aceste sisteme de plată online.

Procedeele de plată

Modalitățile de plată alcătuiesc un ansamblu de metode proprii, precizate de însușirile unor tranzacții, cu rolul de a asigura crearea transferurilor de fonduri și stingerea îndatoririlor dintre parteneri, în clauzele cu care aceștia au căzut de acord. Procedeele de plată pot fi împărțite în 2 categorii: transferul de credit și transferul de debit.

1.Transferul de credit – este modalitatea de schimb de fonduri, săvârșit prin intermediul băncilor, dintr-un cont în altul, folosind instrumente caracteristice ce fac parte dispoziția debitorului (cumpărătorului), în avantajul creditorului (vânzătorului):

viramentul;

Este operațiunea de plată realizată de către o instituție bancară prin care se realizează transferul unei sume de bani din contul clientului respectiv în contul unui beneficiar pe care acesta îl desemnează prin debitarea contului clientului și creditarea contului beneficiarului.

acreditivul.

Acreditivul este un instrument de plată des utilizat in schimburile economice internaționale. Prin această modalitate de plată cumpărătorul rezervă o anumită sumă de bani în numele furnizorului, în vederea achitării bunurilor sau a serviciilor prestate, conform clauzelor contractuale.

2.Transferul de debit – este modalitatea de schimb de fonduri, ce are loc prin intermediul băncilor, dintr-un cont în altul, folosind instrumente caracteristice din dispoziția creditorului (vânzătorului), nedepinzând de decizia debitorului (cumpărătorului):

cecul – instrument de plată prin care titularul unui cont dă o instrucțiune de plată instituției bancare de a pune la dispoziție o anumită sumă de bani unei alte entități;

direct debit – tranzacție financiară este operațiunea prin care o persoană retrage fonduri din contul bancar al unei alte persoane;

standing order – operațiune prin care un plătitor acordă băncii sale un interval de timp până când aceasta trebuie să plătească o sumă de bani beneficiarului;

procesul cambial – instrument de plată ce exprimă obligația asumată de un debitor de a plăti la vedere sau la scadență o sumă de bani în favoarea unui beneficiar;

incasso-ul – ordinul pe care îl dă exportatorul unei băncii sale de a încasa (de aici denumirea de incasso) contravaloarea unei tranzacții comerciale și de a o vira în contul său.

Prin decontare se percepe schimbul de fonduri între instituțiile bancare și încărcarea și descărcarea de gestiune a băncilor care participă la acest schimb sau transfer, precum și finalizarea plății prin intermediul descărcării de gestiune a platnicului față de beneficiarul plății.

În funcție de forma în care se creează, decontările pot fi divizate în:

decontări pe bază brută;

Decontările pe bază brută sunt cele ce se efectuează operațiune cu operațiune, astfel schimburile sunt încheiate pentru fiecare client sau pentru fiecare tranzacție. Ele sunt caracteristice transferurilor de fonduri de valorilor mari.

Decontarea pe bază brută semnifică faptul că fiecare schimb este decontat individual și nu pe bază netă.

decontări pe bază netă.

Prin opoziție, decontările pe netă implică plata doar a soldului net debitor sau primirea doar a soldului net creditor. Ele sunt caracteristice schimburilor de fonduri de valori mici. Decontările pe bază netă implică confruntarea în cadrul unui interval dat, a tuturor drepturilor de încasare și a tuturor îndatoririlor de achitare între două instituții de credit și transferarea doar a diferenței, la sfârșitul perioadei.

Prin plată se percepe schimbul de fonduri care are ca rezultat încheierea obligațiunilor financiare dintre părțile participante la o tranzacție economică și schimbul de proprietate a activului, în timp ce schimbul de fonduri are un cuprins mai larg și fără un obiectiv economic. Transferurile de fonduri pentru realizarea plăților se mai numesc și transferuri interbancare dacă se realizează între instituții de credit distincte sau transferuri intrabancare dacă schimburile de fonduri se realizează între unitățile aceleiași instituții de credit.

Instrumentele de plăți

Instrumentele de plăți sunt așa numitele monede și anumite acte bancare operaționale pe suport hârtie, magnetic sau electronic, care se realizează pe fundamentul unor tehnicii proprii de operare, circuite și securizare în scopul realizării schimbului de fonduri de la ordonator la beneficiar.

Aceste instrumente sunt trimise de banca centrală și instituțiile bancare comerciale cu consimțământul băncii centrale pentru a se garanta o forma tipizată și un conținut economic și juridic care să aprobe schimbul de fonduri în siguranță absolută și delimitarea sarcinilor celor care participă la schimbul bancar.

Instrumentele de plăți pot fi împărțite în două categorii: instrumente cu numerar și instrumente fără numerar. Cele cu numerar sunt redate prin moneda metalică și bancnotele sunt elaborate de către instituția bancară centrală în general, în unele țări anumite instituții bancare comerciale emit bancnote.[6]

1.2 Prezentarea sistemului de plăți

Aplicația informatică bancară va avea drept scop plata facturilor către furnizorii de utilități și servicii, de la distanță.

Achitarea facturilor de la distanță, implică mari dificultăți indiferent dacă ele se realizează către furnizorii de utilități sau către furnizorii de servicii de telefonie mobilă. Este nevoie de foarte multă răbdare pentru plata facturilor, mai ales pentru că, ni se întâmplă uneori să credem că parcă în aceeași zi în care ne-am decis să plătim o factură, foarte multe persoane s-au decis să facă acest lucru. De foarte multe ori, nu oamenii sunt cei vinovați pentru că doresc să-și plătească facturile, ci spațiile insuficiente și neadecvate pentru astfel de operațiuni, la care mai putem adaugă numărul redus de ghișee și, uneori, chiar indiferența funcționarilor care refuză să fie amabili. În astfel de circumstanțe, modalitățile alternative de plată se dovedesc a fi eficiente. Internetul și telefonul dar și un cont la o instituție bancară se află printre opțiunile preferate ale celor care știu că timpul este foarte important.

Din păcate, în România, plățile la distanță nu sunt atât de populare că în alte țări și sunt practicate doar de companii, puține fiind persoanele fizice care consideră aceste servicii ca fiind o opțiune. Cei care nu folosesc serviciile de plată la distanță aleg mai degrabă să plătească la sediul unei bănci decât la cel al furnizorului.

Persoanele care dețin un cont la o anumită bancă își pot plăti facturile foarte ușor. Prin completarea unui formular standard de autorizare, banca poate să efectueze plata facturilor. Bineînțeles, achitarea facturilor se va face la o dată fixă, în funcție de disponibilul existent în cont și în funcție de valoarea facturii. Direct Debit, așa cum este numit, este un serviciu care se desfășoară, automat, fără drumuri inutile la furnizorul de utilități și servicii sau la bancă. Întârzierea plăților fiind astfel imposibilă, iar extrasele de cont includ informații integrale despre tranzacția desfășurată. Beneficiarul plății, însă, va trebui informat despre acest mod de plată, deoarece factura va fi livrată, în cazul acesta, la adresa instituției bancare. Practic, pentru a se putea folosi de serviciul “Direct Debit”, cei care sunt interesați trebuie să-și facă un cont la o instituție bancară care să conțină serviciul acesta, și să încheie cu banca o “Convenție de Plata” prin “Direct Debit” astfel, puteți avea siguranța că până la data scadentă din factură dispuneți de lichiditățile de care aveți nevoie pentru achitarea facturilor. În cazul în care în cont nu sunt bani disponibili suficienți până la data scadentă a facturii, banca nu va fi capabilă să achite factura, iar furnizorul nefiind plătit va face apel la penalizări.

Servicii alternative

E-banking sau Electronic fund transfer se bazează pe utilizarea tehnologiilor electronice moderne și a calculatorului pentru achitarea facturilor. Pentru serviciile online Internet banking și Home banking sunt necesare o conexiune la internet și un calculator, iar pentru “Mobile banking”,este nevoie doar de un telefon mobil. De acasă sau de la serviciu, achitarea facturilor poate fi ușor de realizat când există o conexiune la internet și un abonament de internet banking. Serviciul aprobă realizarea unor plăti automate sau redundante.

Accesul rapid și în siguranță la propriile conturi prin intermediul internet-ului face posibilă plata facturilor în doar câteva momente. Sunt puține momentele unei zile în care omul stă departe de telefon. Intuind că timpul și mobilitatea sunt de bază, instituțiile bancare au realizat, pentru clienți, serviciul de “Mobile Banking”. Cei care sunt în permanentă mișcare își pot verifica și administra conturile din diferite locuri folosind telefonul mobil echipat cu serviciul WAP (Wireless Application Protocol).

Serviciul de Mobile permite achitarea de plăti de către o lista de beneficiari, lista pe care se pot descoperi diferiți furnizori de servicii. Legătura cu banca este permanentă, adică, 7 zile pe săptămână, 24 de ore, astfel se pot realiza plăți către furnizorii de servicii cu care o anumită bancă a finalizat contracte. Pentru a ajunge un utilizator de “Mobile Banking”, este nevoie de un cont la o bancă, și de un contract încheiat de “Mobile Banking” cu instituția bancară dar și să aveți un telefon mobil care este echipat cu WAP. Însă dacă nu puteți deschide un cont bancar și nici serviciile de e-banking nu va sunt la îndemână, plata utilităților și serviciilor poate fi săvârșită și la ghișeul unei instituții bancare, nu doar la cel al furnizorului. Oricine are posibilitatea de a merge la ghișeul unei bănci să-și achite facturile, mulți preferând această opțiune deoarece, se desfășoară cu o rapiditate mai mare decât la sediul furnizorului.

E-facturile

Inițiate în 2002 și utilizate încă la un nivel destul de redus, soluțiile de plată online sunt o alternativă la posibilitățile clasice de plată a obligațiilor către stat sau către furnizorii de utilități. Achitarea facturilor la utilități se execută direct din contul de utilizator, oricând și de oriunde se poate realiza o conexiune la internet. După ce se deschide un cont de utilizator se trece la completarea datelor ce privesc factura respectivă urmând că utilizatorul să fie transferat pe pagina Romcard, unde va completa datele card-ului și unde se va executa efectuarea propriu-zisă a plății, iar în scurt timp va primi mesajul de confirmare a plății în contul sau de utilizator dar și pe adresa de e-mail.

Avantajele utilizării unui astfel de sistem de plăti online a utilităților și serviciilor se efectuează în timpul infim necesar pentru efectuarea plății. Un alt avantaj este acela că sistemul oferă facilități suplimentare cum ar fi: arhivarea facturilor, posibilitatea vizualizării rapide a istoricului plăților, dar și a statusului unei plăti, precum și confirmarea rapidă pe e-mail a operațiunilor.

Serviciul e-facturi.ro este adresat tuturor persoanelor care pot realiza o conexiune la internet și care dețin un card la o instituție bancară, el fiind foarte apreciat de cei cu programul de lucru între orele 9 și 17 care nu au timp să ajungă să-și plătească facturile.[8]

Sistemul electronic ce urmează a fi implementat asigură o accelerare semnificativă a circuitelor de plată și impune o operativitate sporită titularilor de cont în luarea deciziilor cu privire la trezoreria lor, și nu numai.

Marea majoritate a informațiilor privind operațiunile bancare se vor înregistra în memoria calculatoarelor. Dispariția unor informații poate aduce prejudicii considerabile clienților.

Plata online a facturilor se va realiza cu ajutorul unor conturi virtuale. Metoda de plată prin conturile virtuale funcționează exact ca un cont bancar doar că totul se realizează electronic.

Astfel, contul virtual se alimentează prin utilizarea unui card bancar compatibil cu plățile on line, cu o anumită valoare, banii urmând a fi transferați din contul bancar în cel electronic prin intermediul serviciilor de tip internet banking sau prin depunerea acestora la casieria băncii.

În România, serviciile de tipul contului virtual sunt oferite de societăți precum Pay-Pal.com, Neteller.com, Mondopay.com și Wallet.librapay.ro societăți care intermediază atât plățile și transferurile electronice către utilizatorii aceluiași site, cât și plățile produselor achiziționate online de la magazinele care acceptă contul virtual că metodă de plată.

Aplicația care va fi creată pentru plata facturilor va face posibil acest lucru prin introducerea manuală a datelor aferente facturii, după care urmează o acțiune de confirmare a datelor aferente plății, urmează plata propriu-zisă a facturii care utilizează portofelul virtual și apoi o posibilitate de a vedea starea comenzilor în „istoricul plăților”.

Contul portofelului virtual se va face pe baza email-ului și a unei parole pe care utilizatorul o setează și imediat contul se va activa prin vizitarea linkului care va fi trimis pe adresa de e-mail introdusă anterior. Imediat după ce parola a fost setată utilizatorul va putea beneficia de toate funcționalitățile serviciului de plată:

– lista tranzacțiilor;

– lista card-urilor;

– posibilitatea de a plăti cu oricare dintre card-uri fără a mai introduce datele din nou (numărul card-ului, dată expirării, numele titularului).

1.3 Beneficiile implementării unui sistem de plată online

În era vitezei, în care vânăm timpul liber și încercăm să îl valorificăm la maxim, cine mai vrea să piardă zeci de minute la cozi că să își plătească facturile? Mă întreb câți dintre oamenii grăbiți pe care îi vedem zilnic apelează la tehnologie pentru a-si achita datoriile sau pur și simplu pentru a face cumpărături într-un mod mult mai eficient?

Tehnologia informatică a făcut posibilă plata online ca o alternativă la metodele de plată tradiționale, care ne “mănâncă” timpul și ne transformă în numere într-un șir de oameni îngrămădiți într-o încăpere mică, eventual fără sistem de ventilație. Relicva sistemului comunist, așteptatul cu orele la cozi inepuizabile, trebuie scoasă definitiv din viața omului modern.

Cu siguranță ni s-a întâmplat până acum să uităm complet la un moment dat să plătim cablul tv, telefonul, internetul, factura la ENEL sau alte facturi la utilități fără un motiv anume. Soluția e ca atunci când îți amintești de o factură neplătită să o achiți pe loc! Dacă amânăm sunt mari șanse să ne trezim cu telefonul restricționat, fără internet în miez de noapte, sau Doamne-ferește fără curent electric! Dacă nu vrem asta, ar fi timpul să luăm în calcul singura metodă de plată pe care o putem efectua și noaptea târziu, plata online.

Plata online a facturilor. Avantaje

Iată câteva avantaje pentru plata online sau de ce trebuie să uiți de funcționarele încruntate care te așteaptă la ghișeu …

1. Metoda e simplă – chiar confortabilă

Nu mai trebuie să te învoiești în timpul programului de muncă pentru a putea plăti la ghișeu. Poți plăti la orice ora, din fotoliul propriu, iar în fața ta nu va fi altcineva decât PC-ul prietenos.

2. Plata rapidă!

Procedura durează în medie 3 minute. Din acesta cauză, nu există termeni de comparație cu metodele clasice de plată a unei facturi.

3. Mediu securizat!

Majoritatea site-urilor care au ca opțiune plata online se realizează pe un sistem securizat de procesare a tranzacțiilor online. Oricum, pentru siguranță, cel mai bine ar fi să citești toate detaliile legate de metoda de plată și să fii foarte atent la detaliile legate de securitate care marchează o metodă de plată sigură.

4. Și să nu uităm – metodă ieftină!

Plata online te scutește de drumuri inutile și implicit de costurile de deplasare. Ghișeul virtual e doar „la un click distanță” – expresie care deja a devenit clișeu.

Am vorbit de plata online că o alternativă la metodele tradiționale de plată a facturilor. Dar plata online se folosește și că metodă de plată a produselor cumpărate din magazinele online care, deși au cunoscut un început timid în România, la momentul actual se bucură de o notorietate în continuă creștere.

Înlocuirea numerarului cu „banii electronici” vine cu avantaje multiple și pentru economie, cele mai importante fiind: reducerea costurilor de emitere a monedelor și bancnotelor și menținerea în circulație a numerarului.

O previziune acceptată de mulți: Plata online – această metodă comodă, rapidă și sigură, va lua locul, în timp, metodelor tradiționale de plată.[9]

Desigur ca așa cum acest sistem are avantajele sale, exista printre acestea și câteva dezavantaje:

1. Dacă avem nevoie de factură pe suport de hârtie suntem nevoiți să o scoatem la imprimantă;

2. Dacă nu există acces la internet atunci plata facturilor sau chiar verificarea lor este practic imposibilă;

3. Dacă uităm contul de utilizator și parola iarăși nu putem plăti sau verifica facturile;

4. Există și posibilitatea că cineva să spargă contul și să modifice parola, lucru care iar ne-ar pune în mare dificultate și bineînțeles vom pierde mult timp până rezolvăm problema.

5. Există și dezavantajul instituțiilor care fac posibilă plata facturilor la distanță, și acela este ca se pierd fonduri în vederea întreținerii și implementării sistemelor care fac posibilă operațiunea de plată la distanță

6. Că ultim dezavantaj am ales să specific faptul că mediul înconjurător este afectat deoarece se consumă puțin mai multă electricitate pentru funcționarea sistemelor de plată online.

2.Tehnologii informatice utilizate

In acest capitol sunt prezentate tehnologiile informatice utilizate pentru a dezvolta aplicația cu baza de date Oracle, capabilă să efectueze plata unei facturi online, fără a fi nevoie ca utilizatorul să se deplaseze la o anumită bancă pentru a-și putea plăti facturile la utilități.

Așadar pentru dezvoltarea baze de date a fost folosit programul SQL Developer care lucrează cu scripturi SQL prin care se pot crea tabelele cu atributele necesare, dar și legăturile dintre tabele și stabilirea cheilor primare si externe.

Aplicația informatică este realizată în programul Jdeveloper care folosește limbajul de programare Java cu ajutorul căruia a fost creata aplicația propriu-zisă cu funcționalitățile necesare dar și design-ul acesteia.

2.1 Programarea orientată pe obiecte

Programarea cu obiecte (POO – programarea orientată pe obiecte) s-a impus atenției prin limbajul C++ (în 1987 apare cartea lui Bjarne Stroustroup) deși limbajul pur obiectual Smalltalk fusese inventat și folosit încă înainte de 1980, iar limbajul cu clase Simula (din care s-a inspirat si Stroustroup) este chiar și mai vechi (în jurul lui 1970).

Specificul programării cu obiecte

În programarea procedurală, accentul cade pe fluxul operațiilor de prelucrare a datelor, pe succesiunea lor în timp. Proiectarea unui program C (Pascal, Fortran, Cobol) înseamnă în principal stabilirea funcțiilor (subprogramelor) din componenta programului și a relațiilor dintre aceste funcții (cine pe cine apelează și în ce ordine). Datele prelucrate se transmit acestor funcții ca argumente (parametri) sau (mai rar) se definesc ca variabile externe, globale. Progresele realizate de la programarea cu instrucțiuni de salt (Fortran 66) la programarea structurată (Pascal, C, Fortran 90) au fost mai ales în sensul exprimării mai clare și mai sigure a succesiunii operațiilor de prelucrare (blocuri de instrucțiuni, decizii si cicluri).

În programarea cu obiecte accentul se mută pe obiectele de date care intervin într-o aplicație, iar prelucrările sunt în general asociate cu diferite obiecte (sub formă de "metode" de tratare a obiectelor). Obiectele pot fi mai simple (de exemplu, numere sau șiruri de caractere) sau mai complexe (o structură de date, un document etc. ). Obiectele pot corespunde unor noțiuni din universul aplicației sau unor concepte abstracte. Proiectarea unui program Java înseamnă stabilirea claselor (obiectelor) ce contribuie la realizarea aplicației, a relațiilor dintre ele și a modului în care aceste obiecte interacționează (comunică între ele prin mesaje).

Așa cum nu există o soluție unică pentru definirea subprogramelor dintr-un program procedural, tot așa nu există o singură soluție pentru definirea și alegerea claselor dintr-un program orientat pe obiecte.

Ca orice nouă tehnologie, programarea cu clase prezintă avantaje și dezavantaje față de abordările anterioare, iar raportul dintre plusuri și minusuri depinde mult de specificul problemelor rezolvate.

Astfel, cei care programează aplicații algoritmice vor fi greu de convins să renunțe la un limbaj simplu cum este limbajul Fortran pentru limbaje mai complexe ca Java sau C++, deoarece problemele numerice nu beneficiază semnificativ de abordarea cu obiecte, care poate părea doar o complicație inutilă, care conduce la programe mai lungi și mai puțin "naturale" (mai depărtate de formularea matematică a problemei).

Pe de altă parte, programatorii care realizează aplicații în care interfața grafică a programului cu operatorul uman are o pondere importantă, apreciază simplificarea adusă prin utilizarea unor biblioteci de clase care încapsulează structuri de date si funcții.

Pentru un număr mare de aplicații, de dimensiuni relativ mici, nici una din cele două abordări (procedurală sau obiectuală) nu este în mod evident superioară, dacă aplicația respectivă este privită separat de altele și nu se consideră aspectul reutilizării claselor în mai multe aplicații.

Trebuie avut în vedere și faptul că însușirea unui nou mod de abordare a programării necesită un efort inițial de adaptare, studiul unor aplicații existente și acumularea unei experiențe în definirea și utilizarea de obiecte.

Avantajele programării orientate pe obiecte

Programarea orientată pe obiecte este o tehnică de programare capabilă să reducă efortul de realizare a unor aplicații complexe, cu interfață grafică, cu baze de date și cu structuri de date mai complexe.

Principala cale de stăpânire a complexității programelor este modularizarea lor, combinată cu reutilizarea unor module în mai multe programe. Modulele program pot fi scrise și verificate separat înainte de a fi asamblate într-o aplicație unică.

Mult timp, noțiunea de modul (funcțional) a însemnat un subprogram (funcție, procedură). În multe limbaje, inclusiv în C, mai există și module de compilare (unități de traducere), care sunt de fapt fișiere sursă ce pot conține una sau mai multe funcții.

Aplicațiile mari pot conține zeci și sute de funcții, iar numărul funcțiilor apelate este mult mai mare: funcții standard ale limbajului, funcții din biblioteci, funcții pentru interfața grafică, ș.a. S-a mai observat că o parte din aceste funcții realizează operații asociate unor structuri de date folosite de aplicații sau operații legate de dialogul cu utilizatorii și sunt relativ independente de logica aplicației. Această observație sugerează că este posibil și un alt nivel de modularizare al programelor, cu module mai complexe decât funcțiile.

O clasă poate fi privită ca un modul de program mai cuprinzător deoarece grupează mai multe funcții în jurul unor date (sau chiar fără date comune). Avantajul utilizării unor module de program mai mari este însoțit, în cadrul POO, de posibilitatea reutilizării acestor module în diverse aplicații.

Un alt avantaj care rezultă din gruparea funcțiilor și datelor este reducerea numărului de argumente al funcțiilor (și, mai ales, al argumentelor modificabile, de tip pointer sau referință), deoarece metodele unei clase se pot referi la datele clasei ca și cum ar fi variabile globale (ele nu mai trebuie transmise ca argumente). De exemplu, metodele "push" și "pop", care pun sau scot ceva dintr-o stivă nu trebuie să mai aibă ca argumente variabila ce reprezintă stiva (un vector, de exemplu) și nici indicele vârfului stivei ("stack pointer").

Principala provocare a POO este chiar definirea de clase reutilizabile în cât mai multe aplicații. Deja există biblioteci de clase (de componente) reutilizabile pentru anumite domenii, cum sunt cel al realizării de interfețe grafice cu utilizatorii (GUI-Graphical User Interface), al structurilor de date, al accesului la bazele de date ș.a.

POO a adus și alte metode de adaptare a modulelor reutilizate la specificul aplicațiilor: crearea de clase derivate sau doar modificarea proprietăților unor componente. O componentă (software) este o clasă utilizabilă ca atare (fără crearea de subclase) și care poate fi cuplată cu alte componente într-o aplicație fără programare sau cu un minim de programare, folosind un mediu vizual (un editor vizual de componente).

Derivarea de subclase dintr-o clasă de bază (superclasă) este o metodă mai sigură de a face ajustări importante în funcționalitatea unui modul, față de modificarea unor subprograme existente, deoarece nu se fac modificări în clasele preluate iar metodele moștenite nu mai trebuie testate.

Un alt avantaj al POO poate fi considerat și posibilitatea de definire a unor noi tipuri de date, de orice complexitate dar cu o utilizare similară tipurilor predefinite. De exemplu, o clasă de tip "stivă" va conține un vector (sau o listă înlănțuită) dar și operațiile asociate stivei: pune o valoare în stivă, scoate valoarea din vârful stivei, test dacă stiva este goală și inițializarea stivei. După ce s-a definit clasa "stivă" se pot declara variabile, parametri și chiar funcții de tip stivă.

Clasele (obiectele) din programe pot corespunde unor obiecte fizice, concrete din aplicație (cărți, automobile, piese mecanice, componente electronice, persoane umane, facturi, etc.) sau unor noțiuni abstracte, mai generale (om, animal, dată calendaristică, interval de timp, activitate).

Unii autori recomandă chiar extragerea părților de vorbire din descrierea aplicației și transformarea substantivelor în clase, adjectivelor în datele clasei și transformarea verbelor în funcții ale claselor (metodele clasei).

Această corespondență dintre componentele programului și noțiunile specifice aplicației este văzută ca un avantaj al POO, comparativ cu programarea tradițională, care înlocuiește universul problemei cu numere, șiruri de caractere, liste și operații cu variabile de aceste tipuri.

Avantajele principale ale POO le-am sintetizat in cele ce urmează:

Utilizarea unor module de program mai cuprinzătoare (clasele), organizate de multe ori ierarhic în familii (ierarhii) de clase; de aici, reducerea numărului de linii sursă care trebuie scrise pentru o nouă aplicație. Utilizarea unei clase C se face nu numai prin preluarea ei ca atare ci, mai ales, prin derivarea altor clase din C, cu adăugarea de funcții (și /sau date) necesare aplicației respective.

Reducerea posibilităților de eroare (programare mai sigură) datorită pe de-o parte faptului că toate clasele folosite au fost testate în prealabil și, pe de altă parte, verificărilor realizate de compilator asupra operațiilor cu obiecte (sunt permise numai operațiile prevăzute la definirea clasei respective).

Înțelegerea și întreținerea programelor mari este mai simplă datorită dimensiunii lor mai reduse și apropierii dintre elementele programului și noțiunile aplicației (problemei de rezolvat).

POO nu înseamnă doar folosirea altor construcții și tehnici în programare, ci presupune un alt mod de gândire și de abordare a programării (o proiectare orientată pe obiecte). În POO rezolvarea unei probleme se concentrează pe identificarea obiectelor, proprietăților și comportamentului lor și nu pe determinarea succesiunii operațiilor cu numere sau șiruri de caractere care conduc la soluția problemei. Ca și în cazul programării clasice, dificultatea cea mai mare o constituie analiza problemei și proiectarea (concepția) programelor și nu exprimarea proiectului în termenii unui anumit limbaj de programare.

Dezavantaje ale programării orientate obiect

Programarea orientată pe obiecte apărută începând din anii 90’ este avantajoasă dar exista și dezavantaje ca de exemplu dependența de software și uneori un cost mai ridicat. Din punctul meu de vedere acestea sunt singurele dezavantaje pe care le-am găsit in timpul studierii acestui nou tip de programare.

Unitatea elementară a programării orientate pe obiecte este obiectul. Limbajele care respectă întocmai conceptele programării orientate obiect reprezintă și detaliază relațiile dintre obiecte. Toate obiectele au o stare și un comportament.

Starea unui obiect face referire la datele conținute de obiect, caracteristicile și la valorile asociate acestora. Tot ceea ce cunoaște obiectul despre aceste elemente și despre valorile aferente lor realizează starea obiectului. Elementele de date care le sunt asociate obiectelor se numesc variabile de instanță.

Comportamentul unui obiect depinde de acțiunile pe care obiectul poate să le execute asupra variabilelor de instanță definite în cadrul său. În programarea procedurală, o astfel de construcție se numește funcție. În terminologia specifică programării orientate pe obiecte, această construcție se numește metodă. O metodă aparține clasei a cărei membră este.

Starea unui obiect depinde foarte mult de lucrurile pe care le cunoaște obiectul, iar comportamentul lui depinde de acțiunile pe care le poate executa.

Obiectele încapsulează variabile de instanță și metode înrudite într-o singură unitate identificabilă. Ca urmare, obiectele sunt ușor de refolosit, de actualizat și de întreținut. Un obiect poate apela una sau mai multe metode pentru derularea unei operațiuni. Metodele sunt inițiate prin transmiterea unui mesaj către obiectul respectiv. Un mesaj trebuie să conțină numele obiectului către care este trimis, numele metodelor care vor fi apelate și valorile necesare metodelor respective. Obiectul care recepționează mesajul folosește informațiile pe care le-a primit pentru a apela metodele corespunzătoare cu valorile specificate.

Avantajul încapsulării variabilelor de instanță și a metodelor constă în faptul că putem trimite mesaje unui obiect, fără să cunoaștem modul de lucru al obiectului respectiv.

Clasele încapsulează obiecte. O singură clasă poate fi folosită pentru instanțierea mai multor obiecte. Aceasta înseamnă că putem avea mai multe obiecte active sau mai multe instanțe ale aceleiași clase.

Noțiunea de "clasă" poate fi privită ca o generalizare și o abstractizare a unui grup de obiecte care au în comun anumite proprietăți (atribute) ai acțiunii (operații). Un obiect este, în acest caz, o "instanțiere" a unei clase, deci un caz particular concret de clasă.

În C++ și în alte limbaje de programare orientate obiect, o colecție de clase sau de funcții înrudite formează o bibliotecă. Java pune o amprentă proprie asupra bibliotecilor, folosind termenul de pachet pentru a descrie o colecție de clase înrudite. Așa cum clasele încapsulează obiecte, pachetele încapsulează clase.

Moștenirea este o caracteristică importanta a limbajelor de programare orientate pe obiecte, care permite să refolosim codul și să extindem funcționalitatea claselor existente. Folosind acest aspect al programării orientate pe obiecte, putem crea o nouă clasă care moștenește funcționalitatea unei clase existente. Putem apoi să extindem funcțiile vechii clase, astfel încât să corespundă necesităților curente.

O (sub)clasă derivată dintr-o clasă instanțiabilă moștenește de la aceasta date și metode (operații), pe care le poate modifica sau la care poate adăuga alte date și /sau metode proprii.

Există însă și clase abstracte, care nu pot fi instanțiate, dar care pot fi folosite pentru obținerea prin derivare a unor clase instanțiabile. O clasă abstractă este o clasă cu sau fără date, dar pentru care o parte din metode (sau toate) sunt metode abstracte. O metodă abstractă este declarată (anunțată) ca rol, tip și parametri, dar nu este definită printr-o secvență de instrucțiuni. Pentru o metodă abstractă se știe ce trebuie să facă dar nu se știe (încă) cum trebuie să facă. Subclasele derivate dintr-o clasă abstractă vor trebui să precizeze metodele abstracte moștenite.

O subclasă a unei clase abstracte moștenește doar obligația de a implementa metodele abstracte [10].

Figura 2.1 Evolutia limbajelor de programare

Schema reprezentată mai sus are rolul de a prezenta evoluția limbajelor de programare începând de la primul, Assembly, apărut în anii 50’ și terminând cu cel mai nou limbaj apărut în anii 90’, Java. Se pot observa de asemenea și rădăcinile fiecărui limbaj în parte,mai exact din ce limbaj s-a dezvoltat și pe parcursul a căror ani.

In aplicația dezvoltată s-a folosit programarea orientata pe obiecte pentru a crea ferestrele aplicației, funcționalitățile ei precum si design-ul.

2.2 Introducere în Jdeveloper

Oracle Jdeveloper 10g este un mediu integrat de dezvoltare (IDE) pentru dezvoltarea de aplicații și servicii web, folosind standarde în domeniile Java, XML și SQL. Începând cu versiunea 9.0.1, Jdeveloper este scris complet în Java, versiunile anterioare fiind un hibrid capabil să ruleze numai pe platforme Windows. Pentru a maximiza productivitatea software, Oracle Jdeveloper permite aplicației pe toată durata ciclului de dezvoltare, folosind instrumente integrate pentru modelarea, scrierea codului sursa, depanarea, testarea, profilarea, ajustarea și implementarea acesteia.

Printre noile facilități oferite de Jdeveloper se numără abordarea declarativă și vizuală a dezvoltării precum și inovativa Oracle Application Development Framework (Oracle ADF), ce contribuie la simplificarea procesului de dezvoltare și reduce semnificativ timpul alocat codului sursa, oferind o productivitate mare și o multitudine de posibilități în privința alegerii tehnologiilor cu care se lucrează.

Oracle Jdeveloper se axează pe dezvoltarea de aplicații Java folosind JEE (Java Enterprise Edition), JSE(Java Standard Edition) sau JME(Java Mobile Edition). JEE este un set de specificații folosit în construirea de aplicații multi-nivel folosind limbajul Java. JEE este o platformă robustă, securizată și scalabilă ce constituie fundația pentru multe din aplicațiile de astăzi.

Jdeveloper pune la dispoziția dezvoltatorilor de aplicații XML facilități puternice precum XML Schema Modeler, accesul direct la codul XML precum și inspectorul de tag-uri XML.

Ajungând la concluzia că fiecare programator Java are un nivel de experiență și cunoștințe diferit cât și propriul stil de abordare a dezvoltării, Oracle Jdeveloper oferă o multitudine de abordări de dezvoltare, ce includ Model Driven Architecture (MDA – Arhitectură bazată pe modele), dezvoltare declarativă sau pur și simplu programare manuală, programatorii putând opta pentru metoda ce se potrivește cel mai bine stilului lor.

Oracle Jdeveloper oferă posibilitatea programatorilor de a folosi ultimele standarde tehnologice în dezvoltarea aplicațiilor ce pot rula pe platfome hardware și software multiple. Aplicațiile construite cu Oracle Jdeveloper pot fi implementate pe orice server compatibil J2EE și pot accesa orice bază de date compatibilă JDBC.

În aceeași direcție, Oracle încurajează instrumentele și platformele open-source, oferind funcționalități pentru Struts, Ant, Junit. Această integrare dă posibilitatea programatorilor de a folosi instrumentele open-source, optimizând astfel procesul de dezvoltare.

Jdeveloper pune de asemenea la dispoziție un SDK (Software Developer’s Kit) de extensie ce lasă programatorii să adauge posibilități noi și să-și personalizeze mediul de dezvoltare.

Oracle Jdeveloper 10g include Oracle Application Development Framework (Oracle ADF). Acest cadru de lucru simplifică dezvoltarea în JEE prin minimizarea necesității de a scrie cod sursa ce implementează tipare de proiectare sau infrastructură a aplicației. Oracle ADF le pune la dispoziție ca parte a cadrului de lucru și conține atât servicii în timpul execuției cât și funcționalități de dezvoltare. Este un pas evolutiv, o îmbunătățire și o extensie a cadrelor de lucru existente în versiunile anterioare de Jdeveloper.

Oracle ADF este bazat pe tiparul de proiectare Model-View-Controller (MVC). MVC separă arhitectura unei aplicații pe 3 niveluri:

Model – se ocupă de interacțiunea cu sursele de date și de logica afacerii,

View – se ocupă de interfața aplicației cu utilizatorul,

Controller – se ocupă cu mersul fluent al aplicației și acționează ca interfață între nivelurile Model și View.

Independența fiecărui nivel față de celelalte rezultă într-o arhitectură cuplată lejer, fapt ce ajută la o mentenanță mai ușoară și crește reutilizabilitatea codului. Oracle ADF pune la dispoziție o metodă ușoară de a implementa arhitectura MVC.

Oracle Jdeveloper include o diagramă de clase UML care ajută la modelarea și generarea de clase Java simple, servicii Web, componente de afaceri pentru Oracle ADF etc. Programatorii pot aduce tabele din baza de date în diagramă, generând în același timp și acele servicii ce vor realiza interfața Java către aceste tabele.

Oracle Jdeveloper pune la dispoziție un editor vizual atât pentru aplicațiile bazate pe HTML cât și pe cele clasice bazate pe componente Swing. Programatorii pot folosi paleta de componente pentru a adăuga componente vizuale la interfața aplicației cu utilizatorul. Paleta de componente poate fi extinsă cu orice JavaBean standard sau librărie de tag-uri JSP. Inspectorul de proprietăți poate fi folosit pentru a defini în mod declarativ atributele componentelor vizuale. Editorul vizual este sincronizat în orice moment cu codul sursă, lăsând modul de editare preferat la alegerea fiecăruia.

Paleta de control a datelor oferă o perspectivă a nivelului Business Services, oferind programatorilor posibilitatea de a lega la acest nivel diversele componente ale aplicației printr-un drag-and-drop.

Pentru aplicațiile bazate pe pagini Web există ADF UIX, un set de componente pentru definirea de interfețe cu utilizatorul avansate, folosind HTML.

Jdeveloper ajută programatorii să construiască aplicații de afaceri și comerț electronic utilizând Java, XML, HTML, SQL și PL/SQL și pune la dispoziție diverse editoare și instrumente grafice pentru fiecare din aceste limbaje.

Oracle XML Developers Kit (XDK) este integrat în Jdeveloper, oferind multiple moduri de a manipula, crea și transforma codul XML. Oracle Jdeveloper are un nou editor de XML asistat de scheme. O schemă XML definește structura unui document XML. O nouă facilitate denumită Code Insight folosește schema XML pentru a valida codul XML și oferă o listă de alternative valide pentru atribute sau elemente XML pe măsură ce programatorul tastează.

Alte facilități pentru lucrul cu XML se referă la colorarea sintaxei, verificarea sintaxei, o vizualizare arborescentă a structurii și manipularea prin intermediul Property Inspector.

Oracle Jdeveloper 10g oferă facilități extinse pentru managementul conexiunilor și vizualizarea elementelor componente ale unei baze de date, la toate acestea adăugându-se suport îmbunătățit pentru secvențele PL/SQL și un SQL Worksheet încorporat.

Managementul conexiunilor. Jdeveloper permite crearea de conexiuni reutilizabile, menținându-se detaliile unei conexiuni precum: utilizator, parolă, numărul portului, calculatorul gazdă și identificatorul bazei de date. Aceste conexiuni pot fi refolosite în diverse stadii ale ciclului de dezvoltare atunci când:

– se vizualizează obiectele bazei de date ;

– se editează și se compilează cod PL/SQL (proceduri, funcții, pachete, declanșatoare);

– se execută și se modifică instrucțiuni SQL;

– se implementează cod Java în server.

Vizualizarea obiectelor bazei de date.

Conexiunile din Connection Navigator oferă o vizualizare schematică a mai multor obiecte din baza de date:

– tabele și tabele virtuale;

– secvențe;

– sinonime;

– cod sursa PL/SQL și clase Java implementate;

– obiecte Oracle.

Jdeveloper permite vizualizarea acestor tipuri de obiecte, inclusiv detalii despre obiectul selectat.

Aceasta facilitate permite folosirea informatiilor din baza de date direct din Jdeveloper fara a mai deschide programul in care a fost creata baza de date.

Editorul de cod PL/SQL.

Editorul de cod din Jdeveloper 10g permite programatorului să editeze obiecte PL/SQL precum proceduri, funcții și pachete, fiind ajutat de facilități precum colorarea sintaxei și capacitatea de a rula sau depana aceste secvențe direct din Jdeveloper. Editorul PL/SQL permite lucrul direct asupra codului sursă din baza de date. Pentru a compila codul sursă PL/SQL, Jdeveloper trimite noul cod sursă către baza de date și lasă serverul să se ocupe de compilare. Când apar eventuale erori, acestea sunt afișate în Jdeveloper.

Cu ajutorul acestui editor de cod PL/SQL se poate modifica baza de date direct din Jdeveloper, folosind astfel un singur program pentru dezvoltarea aplicației dar si pentru modificarea bazei de date.

SQL Worksheet.

Incepând cu versiunea 10g, editorul de SQL este înlocuit de un SQL Worksheet încorporat. În afara afișării rezultatelor execuției unei secvențe de comenzi SQL, editorul SQL poate afișa și planul de execuție al secvenței, ajutând astfel la optimizarea accesului la baza de date lucru foarte util in procesul de dezvoltare al sistemului informatic ce urmeaza a fi implementat.

2.3 Introducere în limbajul SQL

Limbajul SQL (Structured Query Language) a fost implementat în produse comerciale începând cu sfârșitul anilor 70’ când s-a lansat prima versiune Oracle și SQL/DS de la IBM.

SQL este un limbaj declarativ; utilizatorul descrie informațiile pe care vrea să le obțină în urma interogării, fără a preciza algoritmii necesari pentru obținerea rezultatelor dorite. Faptul că este un limbaj standard a condus la recunoașterea principalelor sale instrucțiuni de către majoritatea sistemelor de gestiune a bazelor de date relaționale (Oracle, Access, Visual FoxPro, INFORMIX, DB2.).

În ultimii ani, comitetele ANSI și ISO pentru standardizarea limbajului SQL au adăugat noi facilități pentru gestiunea bazelor de date relațional-obiectuale. S-a ajuns astfel la o versiune SQL3, pe cale de a deveni un standard în domeniu. Aceste facilități se pot structura:

– facilități orientate obiect ce propun definirea la nivel de utilizator a tipurilor de date abstracte;

– structuri de control specifice programării structurate: IF, FOR, WHILE ;

– facilități de comunicare în rețea;

– facilități de prelucrare distribuită;

– facilități multi-media, înglobate în modulul Multi-Media SQL.

Limbajul SQL permite o comunicare complexă și rapidă a utilizatorului cu bazele de date, în funcție de cerințele și restricțiile acestuia. Pe lângă manipularea datelor, se efectuează și operații complexe privind administrarea bazei de date.

S-a utilizat limbajul SQL în aplicație la crearea tabelelor bazei de date împreuna cu atributele și tipul atributelor, deasemenea cu ajutorul limbajului SQL s-a realizat legătura dintre tabele stabilind cheile primare și cele externe și s-au inserat și selectat date în/din baza de date.

2.4 Tehnologia UML

UML (Unified Modeling Language) este un limbaj de modelare visual, dar el nu este încă și un limbaj vizual de programare, din cauza faptului ca nu dispune în totalitate de sprijinul semantic și vizual pentru a substitui limbajele de programare. Limbajul ajută în procesul vizualizării, specificării, construirii și documentării sistemelor de aplicații informatice și are anumite limite în ceea ce privește generarea codului sursa.

UML reunește cele mai folositoare practici și tehnici din ingineria programării, care și-au arătat eficiența în realizarea sistemelor complexe.[13]

Limbajul de Modelare Unificat (UML) este orientat obiect și considerat standard de către dezvoltatorii software din toata lumea.

UML este succesorul celor mai eficiente trei limbaje de modelare anterioare orientate pe obiecte (Booch, OMT, OOSE) care au fost unite, și astfel s-a obținut în final un limbaj superior și mult mai expresiv.

Ilustrarea se face folosind elementele standard din UML: notațiile și diagramele.

Notațiile sunt elemente folosite în cadrul fiecărei diagrame și pot fi de tipul: conectori, simboluri, valori etc., iar Diagramele sunt reprezentările aferente unui proces, sistem sau componentelor lor.

UML propune o abordare descendentă. Diagramele furnizează suport pentru materializarea unui demers progresiv, de la global la detaliu, de trecere de la un sistem informațional la un sistem informatic.

Modelele se bazează pe un număr determinat de diagrame, în funcție de complexitatea imaginii asupra sistemului. Datorită stereotipurilor, diagramele se pot adapta la cerințele firmei.

În UML, avansarea în proiect este măsurată prin numărul cazurilor de utilizare, a claselor, a elementelor implementate, și nu prin documentația produsului. Deasemenea în UML, gestiunea riscului este un element esențial pentru gestiunea proiectului, iterațiile constituie instrumente de gestiune a riscului și servesc și pentru integrări și testări în timpul ciclului de dezvoltare.

UML propune utilizarea prototipizării în demersul pentru un nou proiect, pentru a reduce riscurile, validarea produsului final și acceptul utilizatorului față de noul sistem.

Principalele componente ale limbajului UML sunt:

Vederile (View) – abstractizări ale sistemului, la a cărui construire se folosesc un număr de diagrame.

Diagramele – sunt grafuri care reprezintă conținutul unei vederi.

Elementele de modelare – sunt conceptele utilizate în diagrame care au corespondență în programarea orientată pe obiecte, cum ar fi: obiecte, mesaje, clase și relațiile dintre ele adică: asocierea, dependența, generalizarea.

Mecanismele generale – fac posibilă adăugarea de comentarii sau alte informații despre un element anume.

Modelarea unui sistem poate fi o sarcină destul de dificilă. Cel mai bine ar fi să se folosească un singur graf pentru descrierea sistemului, însă de cele mai multe ori este imposibil ca acesta să poată surprinde toate informațiile folositoare pentru descrierea sistemului. Un sistem poate fi descris daca respecta anumite condiții:

Funcțional: este ilustrata structura statică și comportamentul dinamic;

Non-funcțional: timpul necesar pentru dezvoltarea sistemului;

Organizatoric: organizarea activităților, maparea modulelor de cod.

Fiecare vedere în parte este descrisă utilizând un număr de diagrame care conțin informații relative la un aspect particular al sistemului. Aceste vederi se acoperă unele pe altele, așadar se poate să existe situații când o anumită diagramă face parte din mai multe vederi.[13]

Diagramele sunt grafuri care conțin simboluri ale elementelor de modelare (model

element) aranjate în așa fel încât să reprezinte o anumită parte sau un anumit aspect al sistemului. Un model conține în general mai multe diagrame de același tip. O diagramă este o parte a unei vederi specifice, dar există și posibilitatea, așa cum am mai spus, ca o diagramă să facă parte din mai multe vederi, în funcție de conținutul ei. În UML sunt nouă tipuri de diagrame ce urmează să fie prezentate în continuare, acestea sunt: diagrama cazurilor de utilizare, de clase, obiectelor, de stare, de secvență, de colaborare, de activitate, componentelor și de desfășurare.

Diagrama cazurilor de utilizare ajută la stabilirea ariei de cuprindere a sistemului. Ea documentează interacțiunile sistemului cu mediul, respectiv interacțiuni cu factorul uman sau cu alte sisteme. Tot cu ajutorul diagramei cazurilor de utilizare sunt identificate utilizările solicitate, este determinat comportamentul necesar pentru a susține aceste utilizări și sunt conturate cerințele sistemului.

Diagrama claselor reprezintă gruparea fizică a claselor care sunt identificate în sistem. Clasele ilustrează “lucruri” administrate de sistem; clasele pot fi grupate în mai multe feluri: asociate (legate între ele), dependente (o clasa utilizează o altă clasă), specializate (o clasă este specializarea unei alte clase) sau împachetate (grupate împreună în cadrul unei unități). Toate aceste relații se definesc în structura internă a claselor în atribute și operații. Diagrama este considerată a fi statică, adică este validă în orice moment din ciclul de viață al sistemului.

Diagrama obiectelor se trage din diagrama de clase numai ca in locul unei clase sunt reprezentate mai multe instanțe ale acesteia. Se aseamănă cu diagrama de clase chiar și la notațiile folosite existând doua diferențe mici: scrierea obiectelor se face subliniat și vizualizarea se face la toate instanțele relației. Digrama obiectelor este folosită pentru a explica mai detaliat o diagrama de clase care are o complexitate mare.

Diagrama de stare exemplifica toate stările, după cum este specificat și în numele ei, prin care trece un obiect al unei clase dar și evenimentele datorita cărora el se schimbă. Aceste modificări ale stărilor se numesc tranziții. Diagramele de stare se construiesc numai pentru acele clase care au un număr de stări bine definite și nu pentru toate clasele din sistem.

Diagrama de secvența este folosita pentru a arata colaborarea dinamica între un număr de obiecte, adică mesajele care se trimit între acestea pe parcursul timpului.

Diagrama de colaborare se trage bineînțeles din diagrama de stare și acționează exact ca aceasta însa pe lângă acel schimb de mesaje ea mai arata și obiectele cu relațiile dintre acestea.

Diagrama de activitate reprezintă secvențele de activități și este folosită bineînțeles pentru a reda activitățile în ordinea în care aceste au loc folosind decizii și condiții.

Diagrama componentelor reprezintă structura fizica a codului, realizând o mapare de la vederea logica la vederea de componente. O componenta poate conține fie cod sursa, fie se poate afla într-o stare executabila sau chiar binara. În cadrul acestei diagrame vor fi reprezentate și detaliate legăturile dintre componente, ceea ce permite totodată și vizualizarea componentelor ce vor fi afectate la modificările altor componente din sistem.

Diagrama de desfășurare va reprezenta arhitectura fizica a sistemului împreuna cu legăturile dintre componentele sistemului. Fiecare obiect și componentă este alocată în interiorul unui nod și astfel putem observa unitățile care se vor executa pe fiecare nod.[13]

Având în vedere ca Oracle Jdeveloper are instrumentele necesare creării digramelor UML, se va folosi aceasta facilitate pentru a genera diagramele necesare fazei de analiza a sistemului informatic ce urmează a fi implementat.

2.5 Tehnologia Java

Rădăcinile limbajului Java se află într-un proiect de cercetare (proiectul “Green”) al firmei Sun. Coordonator de proiect era James Gosling, unul din veteranii software-ului de rețea.

Java este o tehnologie care oferă suport dezvoltării de aplicații distribuite, independente de platformă. Programele Java pot rula pe diferite tipuri de platformă, cu condiția să existe instalată o mașina virtuală Java deasupra platformei respective.

Cea mai mare parte a sintaxei de programare Java este moștenită din C++, dar multe din conceptele de programare obiectuală prezentate în Java își au rădăcinile în SmallTalk, Lisp etc. Arhitecții de la Sun au inclus în acest limbaj cele mai noi concepte de programare făcându-l o unealtă puternică și ușor de manevrat.

De ce Java?

Un prim argument în favoarea folosirii limbajului Java este simplitatea lui, conceptele fundamentale ale limbajului fiind foarte simple. Fără a pierde din puterea limbajului, s-a renunțat la părțile redundante ale unui limbaj, păstrând doar părțile strict necesare. Tot în ideea simplității, tehnologia Java conține așa numitul Garbage Colector, care eliberează programatorul de grija dezalocării zonelor de memorie alocate. Faptul că respectă o mare parte a gramaticii, sintaxei de programare C/C++ face să poată fi ușor de învățat de cei care au lucrat în limbajul C/C++ .

Un alt argument este faptul că spre deosebire de C++ limbajul java este în întregime bazat pe obiecte. Gradul de intercomunicare între echipele de programatori se mărește considerabil, depanarea, modificarea codului se face într-un timp mult mai scurt rezultând o eficiență mult crescută a dezvoltării sistemelor software, deci în ultimă instanță un preț mai scăzut.

Java mărește gradul de siguranță al codului sursa. Există doua nivele de verificare: unul la compilare (prezent în marea majoritate a limbajelor) și unul la rulare. Ca urmare, un program este mai puțin supus erorilor. Comparativ cu C++, multe din trăsăturile acestuia care de foarte multe ori erau surse de erori, au fost eliminate (pointerii de exemplu au fost eliminați). Accesul la tablourile Java este verificat și la rulare, eliminând astfel posibilitatea accesului accidental sau malițios în afara domeniului tabloului. Conversiile între tipurile de date sunt limitate, evitându-se astfel scrierea nepermisă a unor zone de memorie.

Intr-o lume în care calculatoarele nu mai pot exista ca entități solitare, fără a fi conectate în rețea, problema securității este una din cele mai stringente. Se pune problema existenței unui nivel de securitate în cadrul limbajului. Gradul de securitate mărit este unul din principalele avantaje ale limbajului Java care l-au făcut atât de utilizat. Programele Java sunt făcute să ruleze în sisteme distribuite, calculatoarele pe care ele lucrează nu pot fi sigure de proveniența programelor. Ca urmare, trebuie oprit accesul acestor programe la unele resurse locale pentru a preveni eventualele acțiuni malițioase. În vederea acestui lucru există mai multe proceduri de verificare. Pe lângă verificările de la compilare există verificările de la execuție. Programele Java sunt verificate pas cu pas în timpul rulării prevenind accesul în zonele nepermise. Acest lucru însă nu este fezabil dacă nu era rezolvată problema accesului în afara tablourilor sau problema conversiilor nepermise. Ca urmare există mai multe nivele de securitate în Java[12].

Un alt argument ar fi acela că Java este un limbaj dinamic prin faptul că multe decizii privind evoluția programului se iau în momentul rulării, la momentul execuției. Dat fiind faptul că multe din aplicațiile Java sunt preluate de pe Internet sub formă de module tip applet chiar în momentul execuției lor, deci în rețea, aceste programe pot fi actualizate să facă față noilor cerințe, utilizatorul dispunând în orice moment de cea mai nouă variantă.

Unul din marile avantaje ale limbajului Java este faptul că este independent de platformă. Într-o lume în care fiecare mare companie de software încearcă să monopolizeze piața forțând o dependență de sistemele hardware, de sistemele de operare, de propriile standarde, Java aduce un aer proaspăt de cooperare, de limbaj viabil pentru toate platformele. Această independență de platformă se impunea, ținând cont de ideea de lucru în sisteme distribuite. De fapt un program Java lucrează pe o singură mașină: mașina virtuală Java (Java Virtual Machine-JVM). Aceasta este o platformă virtuală transpusă în realitate prin intermediul interpretorului, mai exact a emulatorului Java. Este un emulator pentru că se emulează execuția unui program în cadrul unei mașini Java, și nu se transformă codul Java pur și simplu în cod mașină ca în cazul unui interpretor. Programele executabile Java, numite și bytecodes sunt rezultatul compilării unui program text. Pentru a putea fi executate pe o anumită platformă (Windows, Unix) acestea au nevoie de un emulator Java Virtual Machine specific respectivei platforme. Emulatorul convertește bytecod java în cod executabil pe mașina reală pas cu pas, instrucțiune cu instrucțiune. Ca urmare a utilizării emulatorului un program Java poate rula pe orice platformă pentru care există un emulator Java. Problema utilizării emulatorului este însă cu două tăișuri. Partea negativă este că atunci când se folosește emulatorul se mărește și timpul de execuție. Soluția este compilarea JIT (just-in-time) care modifică programul Java în întregime în cod mașină chiar înainte de execuția lui. Compilatoarele JIT acționează la fel ca și interpretoarele însa conversia nu se va face la nivel de instrucțiune ci doar la nivel de program, astfel crescând notabil și viteza de execuție a programului Java[12].

Java are și suport pentru multithreading (fire de execuție multiple) ceea ce constituie un avantaj: permite ca un program să execute mai multe sarcini aparent în același timp, utilizând mai multe fire de execuție (thread). Java oferă suport pentru multiple fire de execuție la nivel de limbaj deci la cel mai jos nivel (clasa Thread) oferindu-i astfel utilizatorului posibilitatea de a crea un nou fir de execuție ca și cum ar crea oricare alt obiect. Mai mult, Java permite comunicarea între fire de execuție precum și sincronizarea lor.

Unul din principalele avantaje care a făcut limbajul Java atât de utilizat este interconexiunea cu browsers www. Multe din firmele care dezvoltă browsers www au implementat mașina virtuală Java în interiorul acestor browsere. Un browser compatibil Java permite ca o categorie specială de aplicații, numite applet să fie transformate de la server-ul www pentru a fi executate la client, adică pe calculatorul unde se execută browser-ul www. Conexiunea browser-ului cu modulele applet se face prin intermediul etichetelor html (Hyper Text Mark-up Language), acesta fiind limbajul în care se scrie o pagină web[12].

Arhitectura sistemului Java

Mediul de execuție al limbajului Java, numit și Java Runtime Environment (JRE), reprezintă cadrul de execuție al unui program Java, al unui bytecode Java. Pentru a executa un program Java se trece prin mai multe etape. În primul rând este nevoie de un program sursă (cu extensia java). Acesta este compilat (utilizând un compilator Java, de exemplu Javac) obținându-se un fișier executabil Java, un bytecode Java. Acesta poate fi executat doar în contextul unui mediu de execuție Java, un JRE, prin apelul unui emulator-interpretor (exemplu: mediul JDK).

Mediul de execuție Java, JRE, conține două componente importante, fără de care un program Java nu poate să se execute. Aceste două componente sunt pe de-o parte bibliotecile (package) Java și pe de altă parte mașina virtuală Java (JVM).

Structura mașinii virtuale Java (Java Virtual Machine – JVM) este prezentată în figura 2.5.

Figura 2.5 Structura mașinii virtuale Java[12]

Class Loader – este utilizat pentru a aduce fișierele bytecode (.class) necesare execuției programului. Aceste fișiere se pot găsi pe orice calculator dintr-o rețea.

Bytecode Verifier – este componenta JVM care se ocupă de verificarea fișierelor bytecode pentru ca acestea să respecte setul de reguli Java. Dacă un fișier nu se conformează acestor reguli este respins.

Odată verificat, programul Java este gata de execuție. Execuția se poate face prin intermediul unui interpretor-emulator sau prin intermediul unui compilator Just In Time (JIT). Prin emulator execuția fiecărei instrucțiuni Java este emulată într-o JVM, ceea ce impune un nivel suplimentar deasupra platformei de lucru. Acest lucru se întâmplă în momentul execuției programului ceea ce duce la un consum mare de timp de procesare. În cazul utilizării compilatorului JIT, acesta transformă, din primul moment, întreg programul Java în instrucțiuni procesor ceea ce duce la mărirea vitezei de execuție a programului.

Garbage Colectărul – este componenta ce se ocupă de eliberarea zonelor de memorie alocate și care nu mai sunt utilizate de program. Acest lucru ia de pe capul programatorului grija eliberării zonelor de memorie. Specificațiile mașinii virtuale Java nu impun însă un anumit algoritm de eliberare, lăsând la latitudinea celui ce implementează JVM stabilirea lui.

Security Manager – Este componenta ce asigură respectarea unor restricții de securitate impuse de lucrul în sistemele deschise. Lucrează împreună cu mai toate celelalte componente ale JVM.[12]

Limbajul de programare Java va fi folosit în Jdeveloper în scopul dezvoltării ferestrelor aplicației, funcționalităților acesteia dar și interfeței grafice a aplicației.

3.Analiza și proiectarea aplicației informatice cu baza de date

Înainte de a proiecta arhitectura unui sistem software este important să se obțină o imagine clară asupra cerințelor care influențează arhitectura. De obicei aceste cerințe sunt cerințe non-funcționale ce fac referire la calitatea aplicației software.

Procesul care constă în identificarea cerințelor care produc schimbări la nivelul arhitecturii are două feluri de intrări: pe de o parte arhitectul trebuie să analizeze cerințele funcționale, iar pe de altă parte el trebuie să țină cont și de cerințele venite din partea celor care vor interacționa cu aplicația. În urma analizei efectuate asupra celor două tipuri de cerințe rezultă cerințele care influențează arhitectura sistemului software. Procesul de analiză a cerințelor în vederea izolării cerințelor care influențează arhitectura este ilustrat în Fig. 3.1

Figura 3.1.Analiza cerințelor[14]

Unele cerințe pot acționa ca și constrângeri astfel ele limitând opțiunile arhitectului. În tabelele care urmează am dat câteva exemple de cerințe care influențează arhitectura precum și exemple de cerințe care acționează sub forma de constrângeri.

Tabelul 3.1. Exemple de cerințe care influențează arhitectura[14].

Tabelul 3.2. Exemple de cerințe care acționează sub forma de constrângeri[14].

Un alt aspect care trebuie avut în vedere vis-a-vis de cerințele care influențează arhitectura unui sistem software, este faptul că aceste cerințe nu sunt egale, unele fiind mai importante decât altele. De aceea este necesară o prioritizare a acestor cerințe. De obicei se folosesc trei niveluri de prioritizare:

Ridicată – sistemul software trebuie să implementeze cerințele cu această prioritate. Aceste cerințe au un cuvânt greu de spus în ceea ce privește arhitectura.

Medie – cerințele cu această prioritate vor trebuii implementate la un moment dat, dar nu sunt absolut necesare pentru prima versiune.

Scăzută– funcționalități dorite, dar care se pot implementa în măsura posibilităților.
Prioritizarea cerințelor se complică atunci când apar conflicte între cerințe, de ex.: timp scurt până la terminarea aplicației vs. dezvoltarea de componente generice și reutilizabile. De cele mai multe ori rezolvarea acestor conflicte nu este ușoară, dar este sarcina arhitectului să le rezolve.[14]

3.1 Stabilirea intrărilor în concordanță cu ieșirile

Pentru definirea structurii generale a unui sistem informatic trebuie să pornim de la funcția sistemului care se ocupa cu prelucrarea datelor disponibile în scopul obținerii informațiilor care sunt necesare pentru luarea deciziilor în procesul de conducere.

Cele trei componente principale care formează un sistem informatic sunt: intrările, prelucrările, ieșirile.

Intrările alcătuiesc ansamblul datelor care au fost încărcate, stocate și prelucrate în cadrul sistemului în scopul obținerii de informații.

La nivelul fiecărui subsistem informatic în parte trebuie ca intrările sistemului să presupună anumite condiții de ieșire ale acestuia.

Planul logic – fiecare ieșire rezultatul aplicării unuia sau mai multor operatori asupra unui ansamblu de date de intrare.

Planul tehnologic – caracteristicile aferente ieșirilor sistemului informatic condiționează caracteristicile cerute intrărilor sistemului informatic.

Prelucrările, cel de al doilea element care definește sistemul informatic, formează un ansamblu omogen de proceduri automate care realizează:

• Crearea inițială precum și actualizarea bazei de date;

• Exploatarea bazei de date;

• Reorganizarea bazei de date;

• Salvarea și restaurarea bazei de date.

Ieșirile sistemului informatic sunt definite de rezultatele care reies în urma prelucrărilor desfășurate.

Aceste ieșiri, în funcție de natura prelucrărilor care le-au generat, sunt de două categorii:

Ieșiri obținute în urma unor operații de transfer al datelor, care nu și-au modificat valoarea față de momentul introducerii lor în sistem. De exemplu numărul și data unei facturi;

Ieșiri obținute ca urmare a unor operații de calcul pe baza unor algoritmi prestabiliți (valoarea produsului factura etc.).[15]

Având în vedere toate aceste aspecte generale prezentate anterior putem începe să stabilim datele de intrare ale sistemului de plată online.

Date necesare creerii unui cont care va fi folosit pentru înregistrarea utilizatorilor : nume, prenume, data nașterii, localitate, județ, adresă, număr de telefon, adresa de email, parola.

Datele necesare înregistrării clientului sunt: adresa de email, parola.

Date necesare pentru a începe plata unei facturi: număr factură, suma.

Pentru a putea plăti efectiv factura este nevoie de următoarele date de intrare necesare : număr card, data expirare, nume posesor de card, cod de securitate(CVV).

Conform acestor date se generează automat de către sistemul informatic datele de ieșire după completarea tuturor rubricilor și după trecerea prin toate etapele necesare generării unei situații de ieșire.

3.2. Diagrama generală a cazurilor de utilizare

O diagramă a cazurilor de utilizare (use case diagram) prezintă o colecție de cazuri de utilizare si actori care:

oferă o descriere generală a modului în care va ﬁ utilizat sistemul;

furnizează o privire de ansamblu a funcționalităților ce se doresc a ﬁ oferite de sistem;

arata cum interacționează sistemului cu unul sau mai mulți actori;

asigură faptul că sistemul va produce ceea ce s-a dorit.

Un actor este un stereotip al unei clase. Actorii sunt reprezentați de utilizatori sau entități care pot interacționa cu sistemul. Un actor se reprezintă sub forma unui ”omuleț” sub care se trece numele acestuia.

Identiﬁcarea actorilor se face răspunzând la următoarele intrebări:

Cine dorește sau este interesat de informațiile aﬂate in sistem?

Cine modiﬁcă date?

Cine interacționează cu sistemul?

Un caz de utilizare reprezintă o colecție de scenarii posibile, referitoare la comunicarea între sistem si actorii externi, caracterizate de anumite scopuri.

Cazurile de utilizare arată ce trebuie sa facă sistemul si nu cum. Un caz de utilizare se reprezintă sub forma unui oval în care se trece numele acestuia.

O asociere reprezintă o conexiune semantică între cazurile de utilizare și actori. Asocierile se reprezintă printr-o linie plasată între entitățile asociate.

În continuare este reprezentată diagrama generală a cazurilor de utilizare, a sistemului de plată online a facturilor.[17]

Actorul este clientul, adică utilizatorul sistemul care dorește să efectueze o plată prin intermediul sistemului informatic, iar cazurile de utilizare, reprezentate prin cerculețele pe fond albastru deschis, reprezintă acțiunile pe care utilizatorul, clientul nostru, le face pentru a finaliza plata online a unei facturi. Toate aceste lucruri sunt evidențiate în figura 3.2.1.

Pentru a beneficia de facilitățile oferite de sistemul informatic de plată online, clientul trebuie să se înregistreze în baza de date și să se logheze în sistem, urmând ca apoi să vizualizeze meniul și să aleagă opțiunea de plată a facturii la un anumit furnizor.

Figura 3.2 Diagrama generală a cazurilor de utilizare

3.2.1 Diagrame detaliate ale cazurilor de utilizare

Pentru a putea vedea toate acțiunile implicate în derularea procesului de plată online, este nevoie de diagrame detaliate ale cazurilor de utilizare, cu ajutorul cărora se va înțelege mai bine întregul proces, deoarece acesta va fi împărțit în 3 subprocese fiecare fiind reprezentat printr-o diagrama a cazurilor de utilizare. .

Figura 3.2.1 Diagrama detaliată a cazurilor de utilizare: Autentificarea.

Primul subproces exemplifică autentificarea în sistemul informatic de plată online.

Astfel după deschiderea aplicației pentru ca logarea să se poată efectua trebuie să se efectueze înregistrarea înainte, dacă datele introduse sunt corecte și înregistrarea s-a efectuat se poate efectua și logarea în sistem prin introducerea datelor de log-in introduse mai înainte la etapa de înregistrare, dacă și aceste date sunt corecte și are loc validarea lor atunci utilizatorul poate vizualiza meniul principal al aplicației.

Al doilea subproces reprezentat prin diagramă detaliată din figura 3.2.2, reliefează alegerea furnizorului și inițierea plății unei facturi.

Clientul trebuie mai întâi să aleagă din meniul principal opțiunea de realizare a unei plăți aferente unei facturi, să aleagă serviciul și furnizorul, imediat după trebuiesc introduse datele facturii, mai exact codul facturii și suma care trebuie plătită și dacă acestea sunt corecte se poate trece la etapa următoare.

Figura 3.2.2 Diagrama detaliată a cazurilor de utilizare: Inițierea acțiunii de plată a unei facturii.

Ultimul subproces evidențiază plata efectivă a facturii și terminarea întregului proces, după cum se poate observa în figura 3.2.3. Utilizatorul introduce datele card-ului cerute, codul cvv, numărul cardului și data expirării cardului, daca acestea sunt valide se efectuează plata și detaliile acestei plați vor fi afișate în fereastra „istoric plați”, același lucru se întâmpla și cu datele card-ului cu care s-a efectuat plata, însemnând că și acestea vor fi afișate în fereastra „carduri”.

Dacă se decide să se unească aceste trei diagrame detaliate ale cazurilor de utilizare obținem diagrama generală a cazurilor de utilizare, ea conținând toate acțiunile necesare derulării procesului și nu numai cele mai importante așa cum au fost prezentate în diagrama generală de la subcapitolul precedent.

Figura 3.2.3 Diagrama detaliată a cazului de utilizare: Plata facturii.

3.3 Diagrama de activități

Diagramele de activități se folosesc pentru modelarea aspectelor dinamice ale unui sistem, la diferite nivele: începând de la nivelul „business process”, până la nivel de operație a unei clase. Din acest motiv, în diagramele de activitate se folosesc un număr mare de simboluri.

O acțiune reprezintă un singur pas într-o activitate: un calcul, găsirea unor date, verificarea unor date, etc. O acțiune se reprezintă printr-un dreptunghi rotunjit în care este înscris text (numele acțiunii) în format liber.

Figura 3.3.1 Diagrama de activitate

În figura 3.3.1 este prezentată diagrama de activitate a sistemului informatic de plată a facturilor. Se pleacă de la acțiunea de verificare a existenței unui cont și se încheie cu actiunea de ieșire din sistemul informatic.

3.4 Diagrama de clase

Diagrama claselor este cea mai importantă diagrama în cadrul analizei și proiectării orientate obiect. Scopul diagramei claselor este de a structura natura statică a claselor în termeni de atribute, operații și asocieri. Majoritatea instrumentelor de modelare orientate obiect generează codul sursă numai din diagrama claselor.

Celelalte diagrame UML furnizează diferite puncte de vedere din care să fie identificate atributele, operațiile și asocierile dintre clase. Ele ajută la validarea diagramei claselor, putând servi la clarificarea unei probleme specifice pentru o audiență specifică. Celelalte diagrame din UML există, în principal, pentru a alimenta creșterea și modificarea diagramei claselor, fiecare cu o intenție diferită.

Diagrama claselor conține clase și asocieri între clase. O clasă este un model pentru obiecte cu structură, comportament și relații similare. Fiecare clasă are un nume, atribute și operații. În general numele claselor se scriu cu litere mari.

În figura 3.4.1 este reprezentată diagrama claselor pentru sistemul informatic de plată a facturii online. Se pot observa clasele corespunzătoare tabelelor din baza de date împreună cu atributele aferente și tipul de date asociat dar și legăturile existente dintre clase.

Astfel clasa Factura se leagă de clasa Clienți legătura fiind unu la mai mulți, clasa Furnizori se leagă de clasa Factura cu legătura de tipul unu la mai mulți iar clasa Carduri se leagă de clasa Clienți printr-o legătura tot de tipul unu la mai mulți.

Figura 3.4.1 Diagrama claselor

3.5 Identificarea entităților și proiectarea bazei de date

Entitățile modelează clase de obiecte concrete sau abstracte despre care se colectează

informații, au existența independentă și pot fi identificate în mod unic. Ele definesc de obicei persoane, amplasamente, obiecte sau evenimente cu importanță informațională.

Membrii unei clase care formează o astfel de entitate poartă numele de instanțe ale acelei entități. De remarcat este faptul că întreaga literatură de specialitate definește întâi conceptul de mulțime de entități (sau tip de entități) pentru ca apoi să adopte pentru ușurința exprimării prescurtarea de entitate pentru acest concept. Deci entitatea este un obiect generic care reprezintă mulțimea tuturor instanțelor sale.

Entitățile sunt de două feluri:

1. Entități independente (sau tari) sunt cele care au existență independentă de alte entități.

2. Entități dependente (sau slabe) sunt formate din instanțe care își justifică încadrarea în clasa respectivă doar atâta timp cât într-o alta entitate (tată) există o anumită instanță de care sunt dependente.

Atributele modelează proprietăți atomice distincte ale entităților. De exemplu entitatea CLIENT poate avea că atribute Cod client, Nume, Prenume, Vârstă, Adresă, Telefon etc.

În procesul de modelare vor fi luate în considerare doar acele proprietăți ale entităților

care sunt semnificative pentru aplicația respectivă. Din acest motiv, la entitatea CLIENT nu vom luă în considerare caracteristici că Talia sau Culoarea părului, acestea nefiind necesare pentru bază de date a sistemului de plată online (astfel de atribute ar putea există de exemplu într-o bază de date privind personalul militar).

Atributele unei entități sunt de două feluri:

a) atributele de identificare (formând împreună identificatorul entității) reprezintă

acea mulțime de atribute care permit distincția între instanțele aceleiași entități;

b) atributele de descriere (sau descriptori) sunt folosiți pentru memorarea caracteristicilor suplimentare ale instanțelor.[16]

În exemplul de mai sus Cod client este atribut de identificare (deoarece nu pot exista doi clienți cu același cod) pe când celelalte atribute sunt descriptori.

În aplicația informatică de plată online vor exista următoarele entități:

Client care conține următoarele atribute:

cod client de tip întreg cu lungimea de 20 de caractere, va avea o valoare unică pentru fiecare client, va fi cheie primară și se va autoincrementa;

nume de tip varchar cu lungimea de 20 de caractere;

prenume de tip varchar cu lungimea de 20 de caractere;

telefon de tip întreg cu lungimea de 15 caractere, stochează numărul de telefon al clientului pentru a putea fi căutat în funcție de caz;

adresa de tip string cu lungimea de 100 de caractere, stochează denumirea străzii și a numărului la care locuiește clientul;

email de tip varchar cu lungimea de 80 de caractere, unde se va salva adresa de email a clientului respectiv.

Cont, entitate folosită pentru posibilitatea de înregistrare a clienților.

cod cont, tip întreg cu lungimea de 10 caractere, cheie primară, proprietate de autoincrementare si valoare unică pentru fiecare cont în parte;

username, tip varchar cu lungimea de 30 de caractere, stochează numele de utilizator cu care clientul dorește să se înregistreze;

parola, tip varchar cu lungimea de 10 caractere, reprezintă parola pe care userul o va folosi pentru înregistrare.

Factura conține:

cod factură, tip întreg cu dimensiunea de 10 caractere, cheie primară, valoare unică și proprietatea de a se autoincrementa;

suma, de tip float cu lungimea de 30 de caractere, salvează suma pe care o are de plătit clientul în factura respectivă.

Plată factură este entitatea care reprezintă acțiunea de plată a unei facturi primite de un client, ea conține următoarele atribute:

număr card, tip întreg cu dimensiunea de 20 de caractere;

data expirării, este de tip date și reprezintă data la care va expira cardul respectiv;

cod de securitate(CVV) este de tip întreg cu dimensiunea de 20 de caractere și reprezintă codul CVV al cardului cu care se va achita factura.

3.5.1 Proiectarea bazei de date

Activitățile principale care intra in procesul de formare al ciclul de viață al unei baze de date sunt: proiectarea schemei logice, proiectarea fizică a bazei de date precum și alocarea datelor în rețea și implementarea și întreținerea bazei de date.

Prin procesul de modelare conceptuală a datelor se urmărește crearea unui model al datelor care să poată asigura o transpunere a realității exactă, din domeniul analizat, fără a mai lua în considerare cerințele specifice unui model de organizare a datelor (de exemplu modelul relațional), criteriile de calitate care privesc organizarea datelor, cerințele nefuncționale ale sistemului și criteriile de performanță privind stocarea și accesarea datelor. Astfel, se construiește diagrama entitate-relație, care evidențiază entitățile de date din sistem, atributele acestora, precum și legăturile dintre entități. Modul în care vor fi implementate legăturile dintre entități, de exemplu, nu ne interesează în acest moment deoarece atenția trebuie sa fie îndreptată numai spre identificarea și descrierea lor.[18,19]

Figura 3.5.1 Schema conceptuală a bazei de date

După cum se poate observa din figura 3.5.1 baza de date va fi formata din patru tabele, fiecare continand atributele și tipul atributelor corespunzatoare. Aceste patru tabele vor fi legate între ele prin folosirea cheilor primare și a cheilor externe.

Tabela “Carduri” și tabela “Facturi” se vor lega de tabela clienți prin atributul “CODCLIENT” conținut în aceste două tabele și care este de asemenea cheia primară a tabelei “Clienți”, iar tabela “Furnizori” se va lega de tabela “Factura” prin atributul “COD_FACTURĂ” care este cheia primară a tabelei “Factură”.

4.Implementarea și utilizarea sistemului informatic

Implementarea reprezintă realizarea unei aplicații sau execuția unui plan, unei idei, unui model, etc. În știința calculatoarelor, implementarea reprezintă realizarea unui algoritm sub formă de program.

Implementarea unui sistem informatic trebuie să se facă practic după specificațiile de proiectare a sistemului, definite înainte de etapa de implementare.

Pentru a începe la construirea interfețelor grafice ale aplicației informatice de plată online a unei facturi trebuie mai întâi să fie construită baza de date după specificațiile date la proiectarea bazei de date.

4.1 Crearea bazei de date

Pentru a putea crea o bază de date trebuie mai întâi să se creeze o conexiune cu un server local sau cu un server la distanță. După introducerea datelor se face un test al conexiunii și dacă în dreptul statusului apare mesajul „Succes”, după cum se poate observa și în figura 4.1.1, ne putem conecta în continuare fără probleme.

În reprezentarea ce urmează, conexiunea este făcută la o bază de date locală, și anume Oracle 11 g, în programul SQL Developer.

Figura 4.1.1 Crearea conexiunii

Baza de date care conține tabelele „Clienți”, „Carduri”, „Furnizori”, „Facturi” a fost creată în programul SQL Developer cu ajutorul scripturilor SQL.

Astfel pentru tabelul „Clienți” a fost folosit următorul script în care sunt specificate coloanele tabelului reprezentate prin atribute, tipul atributelor și cheia primară a acestuia: CREATE TABLE "CLIENȚI"

( "CODCLIENT" NUMBER NOT NULL ENABLE,

"NUME" VARCHAR2(20 BYTE),

"PRENUME" VARCHAR2(20 BYTE),

"ADRESǍ" VARCHAR2(200 BYTE),

"TELEFON" NUMBER,

"CNP" VARCHAR2(20 byte),

"E_MAIL" VARCHAR2(50 BYTE),

"PAROLǍ" VARCHAR2(20 BYTE),

CONSTRAINT "CLIENȚI" PRIMARY KEY ("CODCLIENT"));

După rularea acestui script se obține tabela „Clienți” care conține coloanele: CODCLIENT, NUME, PRENUME, ADRESA, TELEFON, CNP, E_MAIL, PAROLA, după cum este prezentată în figura 4.1.2.

Figura 4.1.2 Tabela Clienti

Se poate observa în această figură numele coloanelor tabelului, tipul de dată aferent fiecărei coloane, putem observa de asemenea ce coloane pot fi nule sau nu, dar și care dintre ele este cheia primară a tabelului.

Tabela Factură a fost realizată rulând următorul script SQL:

CREATE TABLE "FACTURǍ"

(COD_FACTURǍ NUMBER NOT NULL ENABLE,

CODCLIENT NUMBER,

SUMA VARCHAR2(20 BYTE),

STATUS VARCHAR2(20 BYTE),

CONSTRAINT "FACTURǍ" PRIMARY KEY ("COD_FACTURǍ"),

FOREIGN KEY(CODCLIENT) REFERENCES CLIENȚI(CODCLIENT));

Se poate observa în acest script, față de scriptul aterior că este făcută o referire către tabela Clienți și atributul CODCLIENT prezent în tabela factură este cheia externă a tabelei.

Rezultatul scriptului este:

Figura 4.1.3 Tabela Factură

Scriptul pentru crearea tabelei „Carduri” este:

CREATE TABLE CARDURI

( COD_CARD NUMBER(20,0) NOT NULL PRIMARY KEY,

CODCLIENT NUMBER(20),

CVV NUMBER(20,0),

DATA_EXPIRARE DATE,

NR_CARD NUMBER(20,0),

FOREIGN KEY(CODCLIENT) REFERENCES CLIENTI(CODCLIENT));

Iar rezultatul acestui script este reprezentat în figura 4.1.4.

Figura 4.1.4 Tabela Carduri

În continuare tabela Furnizori a fost creată pe baza scriptului:

CREATE TABLE "FURNIZORI"

(COD_FURNIZOR NUMBER NOT NULL ENABLE,

COD_FACTURA NUMBER NOT NULL ENABLE,

DENUMIRE VARCHAR2(20 BYTE),

CONSTRAINT "FURNIZORI" PRIMARY KEY ("COD_FURNIZOR"),

FOREIGN KEY(COD_FACTURA) REFERENCES FACTURA(COD_FACTURA));

În figura 4.1.5 putem vedea rezultatul rulării scriptului.

Figura 4.1.5 Tabela Furnizori

Acum că baza de date a fost creată, se poate trece la dezvoltarea aplicației în Jdeveloper cu ajutorul limbajului de programare Java. Însă pentru a putea folosi această bază de date împreună cu aplicația care urmează să fie dezvoltată trebuie să se creeze o legătură între baza de date și aplicație. Legătura va fi prezentată în subcapitolul ce urmează.

4.2 Legatura aplicației cu baza de date

Pentru a se putea face inserări în baza de date și selectări, este de nevoie ca aplicația în care va fi dezvoltată în Jdeveleoper să fie legată de baza de date creată anterior în SQL Developer. Pentru această legătură a fost creată o clasă care se numește DbHelperLocal și face parte din pachetul Controller. În anexa 1 este prezentat codul sursa complet al acestei clase.

Controller-ul reprezintă creierul aplicației. Aceasta face legătura între model și view, între acțiunile userului și partea decizională a aplicației. În funcție de nevoile utilizatorului, controllerul apelează diverse funcții definite special pentru secțiunea de site în care se află userul. Funcția se va folosi de model pentru a prelucra (extrage, actualiza) datele, după care informațiile noi vor fi trimise către view, ce le va afișa apoi prin template-uri.

Așadar arhitectura aplicației va fi model-view-controller.

În clasa DbHelperLocal am definit o instanță de Connection pentru a putea face conexiunea la baza de date după cum se poate observa și în codul ce urmează:

public class DbHelperLocal {

Connection conn;

private static DbHelperLocal singleton;

public DbHelperLocal()throws Exception{

DriverManager.registerDriver(

new oracle.jdbc.driver.OracleDriver());

conn = DriverManager.getConnection ("jdbc:oracle:thin:@localhost:1521:orcl","system","par0la");

conn.setAutoCommit (false);

System.out.println("I am connected");

}

La sfârșit, dacă nu există erori și calea către baza de date este bună se va afișa mesajul „I am connected” și se va face practic conexiunea.

În pachetul Model s-a construit fiecare clasă după modelul unei tabele din baza de date, conținând aceleași atribute și aceleași tipuri de date.

Modelul reprezintă partea de hard-programming, partea logică a aplicației. El are în responsabilitate acțiunile și operațiile asupra datelor, autentificarea utilizatorilor, integrarea diverselor clase ce permit procesarea informațiilor din diverse baze de date.

În figura 4.2.1 se pot vedea cele două pachete „Model” și „Controller” dar și pachetul „gui” care reprezeintă partea de view a aplicației.

.

Figura 4.2.1 Model-View-Controller

View-ul se ocupă de afișarea datelor, practic această parte a programului va avea grijă de cum vede end-userul informația procesată de controller. O dată ce funcțiile sunt executate de model, viewului îi sunt oferite rezultatele, iar acesta le va trimite către browser. În general viewul este o mini-aplicație ce ajută la randarea unor informații, având la bază diverse template-uri.

Programul Jdeveloper oferă instrumentele necesare pentru a putea lucra în baza de date direct din acesta (figură 4.2.2), astfel începând din acest moment nu mai avem nevoie de SQL Developer .

Figura 4.2.2 Transferul întregii baze de date în JDeveloper

4.3 Încărcarea si validarea datelor

Operația de încărcare a datelor în baza de date se face prin intermediul aplicației, mai exact cu ajutorul formularelor. Astfel că datele din fiecare formular vor fi preluate și înserate în câte o tabelă din baza de date pentru ca mai apoi să poată fi selectate și afișate în alte ferestre ale aplicației și să se poată crea diverse metode care folosesc aceste date.

Un exemplu este formularul de înregistrare prezentat în figura 4.3.1.

Figura 4.3.1 Încărcarea datelor în baza de date prin formularul de register

Datele introduse în acest formular vor fi încărcate în tabela Clienți din baza de date. După apăsarea butonului de register în tabela Clienți din baza de date se poate observa că ultima înregistrare efectuată con ține exact datele care au fost introduse în formularul de înregistrare.

Figura 4.3.2 Tabela Clienți cu înregistrări inserate.

În felul acesta se pot încărca datele și în celelalte tabele ale bazei de date, cât despre validarea lor, sunt metode pentru înregistrare menite să verifice dacă înregistrarea este corectă. De exemplu validarea pentru CNP. În cazul în care CNP-ul introdus de client în câmpul de text corespunzător nu este valid atunci clientul va primi un mesaj de avertizare în care i se va spune că CNP-ul nu este valid (figura 4.3.3).

Figura 4.3.3 Mesaj de avertizare pentru CNP

Metoda folosită pentru validarea CNP-ului este:

public static boolean isValid(String cnp){

if(cnp.length() == 13){

int[] cnpArray = Validators.CnpValidator.getArray(cnp);

long sum = cnpArray[0] * 2 + cnpArray[1] * 7 + cnpArray[2] * 9 + cnpArray[3] * 1 + cnpArray[4] * 4 + cnpArray[5] * 6

+ cnpArray[6] * 3 + cnpArray[7] * 5 + cnpArray[8] * 8 + cnpArray[9] * 2 + cnpArray[10] * 7 + cnpArray[11] * 9;

long rest = sum % 11;

if(((rest < 10) && (rest == cnpArray[12])) || ((rest == 10) && (cnpArray[12] == 1))){

return true;

}

return false;

}

La fel s-a procedat și la validarea adresei de e-mail. S-a folosit următoarea metodă în care se specifică faptul că adresa de e-mail poate conține litere mici și mari dar și cifre, nu trebuie să lipsească caracterul special „@”, iar după „ . ” trebuie să existe între 2 și 4 caractere care pot fi litere mari sau mici. În cazul în care adresa este corectă sistemul va afișa un mesaj în care va spune că adresa este validă, iar dacă aceasta nu este corectă se va afișa un mesaj în care se va informa clientul că adresa de e-mail nu este validă.

public class EmailValidator {

String email = "[anonimizat]";

String regEx = \\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}\\b;

Pattern p = Pattern.compile(regEx);

Matcher m = p.matcher(email);

{

if(m.find())

{

System.out.println(email + " is a valid email address.");

}

else

{

System.out.println(email + " is a invalid email address");}}}

A fost facută validare și pe nume și prenume tot folosind o metodă în care se specifică faptul că numele și prenumele poate conține litere mici sau mari, fără cifre sau caractere speciale:

public class NameValidator {

// validate first name

public static boolean validateFirstName( String firstName )

{

return firstName.matches( "[A-Z][a-zA-Z]*" );

} // end method validateFirstName

// validate last name

public static boolean validateLastName( String lastName )

{

return lastName.matches( "[a-zA-z]+([ '-][a-zA-Z]+)*" );

} // end method validateLastName

La parolă validarea este făcută la fel ca și la adresa de e-mail, prima dată în formularul de register iar apoi în fereastra de login unde atât parola cât și adresa de e-mail trebuie introduse corect pentru ca logarea să se poată face.

public class PsswordValidator {

private Pattern pattern;

private Matcher matcher;

private static final String PASSWORD_PATTERN = "((?=.*[a-z])(?=.*\\d).{6,16})";

public void PasswordValidator() {

pattern = Pattern.compile(PASSWORD_PATTERN);

}

public boolean validate(final String password) {

matcher = pattern.matcher(password);

return matcher.matches();}}

Figura 4.3.4 Mesajul de eroare la scrierea gresită a utilizatorului sau a parolei

Se poate observa în figura 4.3.4 ce mesaj de atenționare este afișat în cazul în care adresa de e-mail sau parola nu sunt scrise corespunzător.

4.4 Prezentarea funcționalităților aplicației de plată online a facturilor

Acest capitol poate fi considerat ca fiind un manual de utilizare al aplicației și este destinat clienților care vor folosi într-un final aplicația de plată a facturii online.

La dechiderea aplicației va apărea fereastra principală „MainFrame” de la care pornesc celelalte ferestre ale aplicației.

Fereastra principală conține 2 butoane: „Register” și „Login”. Dacă utilizatorul nu are încă un cont trebuie să își creeze unul apăsând butonul „Register”, iar în cazul în care și-a creat deja un cont înainte trebuie să se logheze apăsând buton „Login”.

În figura 4.4.1 este prezentată fereastra principală.

Figura 4.4.1 Fereastra principală a aplicației

Fereastra „RegisterFrame” conține practic un formular care trebuie completat de către client, datele fiind preluate și inserate în baza de date iar pe baza lor se face intrarea clientului în aplicatie.

Figura 4.4.2 Fereastra de înregistrare

După apăsarea pe butonul „Register”, dacă datele sunt introduse corect va fi afișat un mesaj de confirmare.

Figura 4.4.3 Mesaj de confirmare

Pe baza datelor scrise în câmpul de text al adresei de e-mail și al parolei se va face intrarea în aplicație prin fereastra „Login Frame” reprezentată în figura 4.4.4.

Figura 4.4.4 Fereastra de login

Dacă datele introduse în fereastra de login sunt scrise corect, după apăsarea butonului „Login” vom intra în aplicație și va apărea fereastra cu meniul aplicației.

Figura 4.4.5 Fereastra „Meniu ” a aplicației

Observăm că în fereastra din figură 4.4.5 este preluat prenumele utilizatorului și folosit într-un mesaj de întâmpinare.

Apoi urmează meniul aplicației. Prima posibilitate este de a plăti o factură dând click pe submeniul „Plata facturi”. În continuare se va deschide o fereastră care va conține utilitățile la care putem plăti o factură și furnizorii corespunzători (figura 4.4.6).

Figura 4.4.6 Alegerea utilitații și a furnizorului

Această fereastră are deasemenea și un buton în colțul din dreapta sus pentru ca utilizatorul să se poată întoarce la fereastra cu meniul pricipal.

După alegerea unui furnizor se da click pe numele furnizorului respectiv și se va intra în fereastra de plată a facturii.

Figura 4.4.7 Introducerea detaliilor facturii

Fereastra conține butonul de întoarcere la meniul principal dar și un buton de întoarcere la utilități poziționat în stânga jos. Dacă se dă click pe butonul „Achita factură !”, datele introduse se salvează în baza de date și vor fi afișate în fereastra de istoric plăți după cum se poate observa și în figura 4.4.8, după care se trece la următorul pas.

Figura 4.4.8 Afisarea platilor in fereastra de istoric a platilor

După ce se introduc datele facturii și se apasă butonul de achitare, se dechide o nouă fereastră în care trebuie să completăm datele cardului cu care dorim să achităm factura (figura4.4.9).

Figura 4.4.9 Plata cu cardul

Această fereastră mai conține, pe lângă butonul de întoarcere la meniul pricipal al aplicației și butonul de întoarcere la fereastra cu utilități, un buton care ne duce înapoi la fereastra cu detaliile facturii, buton plasat în colțul din stânga jos, lângă butonul cu utilități.

După introducerea datelor cardului se apasa pe butonul „Efectueaza plată” și după validarea datelor introduse, dacă acestea sunt corecte se efectuează plata și se salvează deasemenea în baza de date. Această plată efectuată se poate vizualiza în fereastra „Istoric plati” prin apăsarea submeniului „Istoric plăți” din meniul principal, facturile având statusul „plătit”.

La fel datele cardului folosit se vor salva în baza de date și vor apărea în fereastra „Carduri ”, care poate fi accesată tot din meniul principal.

Figura 4.4.10 Afisarea cardurilor folosite

După apăsarea pe butonul „Efectuează plata” va apărea din nou fereastra cu meniul principal al aplicației din care putem selecta una din cele 3 opțiuni rămase sau putem să ne delogăm accesând butonul din dreapta jos (figura 4.4.5).

Dacă intrăm în meniul „Setari cont” vom putea vizualiza datele contului în care am intrat (Figura 4.4.11) și bineințeles avem posibilitatea de a modifica datele contului și chiar parola, acțiuni evidențiate în figurile imediat următoare.

Figura 4.4.11 Datele contului activ

Daca se dorește modificarea datelor contului, pur si simplu se modifică respectivele date și apoi prin apăsarea butonului „Modifică date”, se realizează modificarea în baza de date, acțiune încheiată în urma rulării unei metode ce conține un script SQL care realizează o actualizare a bazei de date.

Parola poate fi schimbată apăsând pe butonul „Schimbă parola”. În fereastra aplicației ce apare trebuie introdusă și confirmată parola. Se confirmă acțiunea apăsând pe buton și parola va fi schimbată, figura 4.4.12.

Figura 4.4.12 Fereastra de modificare a parolei

După apăsarea pe butonul „Schimbă parola” clientul se poate loga următoarea dată cu parola nouă pe care și-a ales-o.

În continuare se poate plăti o altă factură sau se poate ieși din aplicație.

Concluzii

Motivația în alegerea temei de disertație „Baza de date Oracle, cu suport Java în domeniul financiar-bancar”, a fost în primul rând importanta acestei ramuri a economiei, și anume ramura financiar-bancară, dar și necesitatea unui sistem informatic capabil să efectueze plățile facturilor de la distanță, având în vedere confruntarea continuă a populației cu lipsa timpului, problemă din ce în ce mai accentuată în prezent.

Programul zilnic este din ce în ce mai încărcat, având în vedere că majoritatea programelor de lucru se termină după ora 17:00. Pe lângă acest aspect, trebuie să luăm în considerare nevoile de zi cu zi ale oamenilor, însă cel mai important lucru care trebuie luat în considerare este faptul că majoritatea instituțiilor bancare unde se pot plăti facturile au programul până la ora 16:00, fiind practic imposibil ca acțiunea de plată a unei facturi la ghișeul unei bănci să se efectueze după terminarea programului de lucru. Având în vedere toate aceste aspecte, se poate trage concluzia că folosirea unui sistem de plată online a facturilor devine din ce în ce mai mult o necesitate și nu numai o opțiune pentru populațiile țărilor dezvoltate.

Lipsa dificultăților de instalare, existența manualelor de folosire a sistemelor de acest fel dar și ușurința cu care aceste programe pot fi accesate sau procurate, determină transformarea acțiunii de plată a unei facturi, dintr-o acțiune dificilă, care implică pierderea timpului liber, și considerată o obligație greu de îndeplinit, într-o acțiune facilă care să fie efectuată cu plăcere.

Dintr-o analiză recentă cu privire la frecvența utilizării programelor de Internet Banking, a rezultat o creștere cu 28% mai mult față de anul 2013, lucru care evidențiază și mai mult importanța și necesitatea folosiri programelor de plată online a facturilor. În prezent, aproximativ 425.000 de persoane folosesc serviciul Internet Banking. Bineînțeles că domeniul plăților prin Internet este într-o continuă dezvoltare, în fiecare an apărând noi facilități și funcționalități oferite de sistemele implementate, prin urmare este de așteptat ca numărul utilizatorilor să crească din ce în ce mai mult de la an la an. Așadar, acest domeniu studiat de mine este nu numai important dar și interesant, având în vedere continua schimbare prin care trece cu fiecare an, acesta fiind încă un motiv care a contribut la motivarea alegerii temei de disertație prezentată anterior.

Timpul este poate cea mai importantă resursă de care dispunem cu toții. A fost, este și va fi o preocupare constantă a omului, fie că vorbim de ”economisirea” timpului fie că vorbim despre ”investirea” acestuia în activități utile pentru noi.

Principalul beneficiu pe care îl aduce folosirea acestui sistem de plată a facturilor la utilități prin intermediul Internetului, este economisirea timpului pierdut cu realizarea plăților utilizând metodele vechi.

„Chiar și un ceas care s-a oprit arată ora exactă de doua ori pe zi”( Marie von Ebner Eschenbach).

Bibliografie

Bogdan Căpraru, Activitatea bancară – Sisteme, operațiuni și practici, Ed. C.H. Beck, București, 2010, p.119.

Jean-Pierre Faugère, Moneda și politica monetară, Ed. Institutul European pentru Cooperare Cultural-științifică, Iași, 2000, p.31.

Tom Kokkola, The payment system Payments, securities and derivatives, and the role of the eurosystem, Ed. European Central Bank, Frankfurt am Main, 2010, p.25.

http://www.bnro.ro/Sisteme-de-plati-304.aspx

http://ro.wikipedia.org/wiki/Sistemul_Na%C8%9Bional_Electronic_de_Plat%C4%83

http://ro.wikipedia.org/wiki/Sistem_de_pl%C4%83%C8%9Bi#Procedeele_de_plat.C4.83

www.payu.row/companie/resurse-presa/comunicate-presa/220-milioane-euro-pentru-comertul-electronic-cu-plata-online/

http://www.telegrafonline.ro/ .

http://www.bugetulpersonal.ro/.

Peter Norton – Ghid de programare în Java, Editura Teora, București 1999

Baze de date. Fundamente teoretice și practice, Grupul BDASEIG, Editura Infomega, București, 2002

Călin Marin Văduva – Programarea în Java Editura Albastră, Cluj-Napoca 2000

http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdf

http://www.aut.upt.ro/

http://teachercolecadm.wikispaces.com/

http://bdfr.cs.pub.ro/

http://inf.ucv.ro/

Ion Lungu, Constanta Bodea, Georgeta Badescu, Cristina Ionita, Baze de date organizare, proiectare și implementare, Editura All Educational, Bucuresti, 1995.

Velicanu Manole, Lungu Ion, Ionescu Simona, Muntean Mihaela, Sisteme de baze de date, Ed.Petrion Gaudeamus, București, 2003 Popescu, I., Modelarea bazelor de date – Editura Tehnica, Bucuresti 2001;

Anexe

Anexa 1

Codul sursă al clasei DbHelperLocal, main controllerul aplicației, unde după cum se poate observa în codul sursă este făcută conexiunea cu baza de date.

package Controller;

import Model.Carduri;

import Model.Client;

import Model.Furnizori;

import java.sql.Connection;

import java.sql.DriverManager;

import java.util.ArrayList;

import javax.sound.midi.ControllerEventListener;

public class DbHelperLocal {

Connection conn;

private static DbHelperLocal singleton;

public DbHelperLocal()throws Exception{

DriverManager.registerDriver(

new oracle.jdbc.driver.OracleDriver());

conn = DriverManager.getConnection ("jdbc:oracle:thin:@localhost:1521:orcl","system","par0la");

conn.setAutoCommit (false);

System.out.println("I am connected");

}

public static DbHelperLocal getInstance(){

if(singleton == null){

try {

singleton = new DbHelperLocal();

} catch (Exception e) {

}

return singleton;

}

Clasa ClientController unde se găsesc metodele necesare pentru acțiunea de înregistrare a clientului precum și pentru cea de conectare (logare) scrise în Jdeveloper în limbajul Java.

package Controller;

import Model.Client;

import Model.Factura;

import Model.Furnizori;

import com.sun.corba.se.pept.protocol.ClientInvocationInfo;

import java.sql.ClientInfoStatus;

import java.sql.Connection;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

import java.util.ArrayList;

import java.util.logging.Level;

import java.util.logging.Logger;

public class ClientController {

Connection conn;

PreparedStatement ps1;

Statement ps2;

Statement st1, st2;

public ClientController(Connection conn){

this.conn=conn;

try {

st1=conn.createStatement();

st2=conn.createStatement();

ps1=conn.prepareStatement("INSERT INTO CLIENTI (NUME,PRENUME,ADRESA,TELEFON,CNP,E_MAIL,PAROLA) VALUES(?,?,?,?,?,?,?)");

ps2=conn.createStatement();

} catch (SQLException e) {

}

public Client checkMail(String email){

try {

ResultSet rs = ps2.executeQuery("SELECT CODCLIENT,NUME,PRENUME,ADRESA,TELEFON,CNP,E_MAIL,PAROLA from CLIENTI where E_MAIL = '" + email + "'");

if(rs.next ())

{

return new Client(rs.getInt(1),rs.getString(2),rs.getString(3),rs.getString(4),rs.getInt(5),rs.getString(6),rs.getString(7),rs.getString(8));

}

} catch (SQLException ex) {

Logger.getLogger(ClientController.class.getName()).log(Level.SEVERE, null, ex); }

return null;

}

public boolean adaugaClient(String nume,String prenume,String adresa,int telefon, String cnp,String email,String parola){

if(checkMail(email)!=null){

return false;

}else{

try {

System.out.println(nume + " " + prenume + " " +adresa+" " + telefon + " " + cnp + " " + " " + email + " " + parola);

ps1.setString(1,nume);

ps1.setString(2,prenume);

ps1.setString(3,adresa);

ps1.setInt(4,telefon);

ps1.setString(5,cnp);

ps1.setString(6,email);

ps1.setString(7,parola);

ps1.executeUpdate();

conn.commit();

return true;

} catch (SQLException e) {

Logger.getLogger(ClientController.class.getName()).log(Level.SEVERE, null, e); }

}

return false;

}

public Client conectare(String email,String parola){

Client client = checkMail(email);

if(client != null){

if(client.getParola().equals(parola)) return client;

else return null;

}else return null;

}

Metoda necesară pentru realizarea acțiunii de afișare a detaliilor unei facturi, împreună cu statusul acesteia (plătită sau neplătită), în fereastra de istoric al plăților.

public ArrayList<Furnizori> getFurnizori(int codClient) throws Exception{

ArrayList<Furnizori> fz = new ArrayList<Furnizori>();

System.out.println("Cod client:"+codClient);

ResultSet res =st1.executeQuery("SELECT F.COD_FACTURA,F.CODCLIENT,F.SUMA,F.STATUS,FZ.DENUMIRE FROM FACTURA F,FURNIZORI FZ WHERE F.CODCLIENT="+codClient+" AND FZ.COD_FACTURA=F.COD_FACTURA AND F.STATUS='Neplatit'" );

while(res.next()){

System.out.println(res.getInt(1)+" "+res.getInt(2)+" "+res.getString(3)+" "+res.getString(4)+" "+res.getString(5));

fz.add(new Furnizori(new Factura(res.getInt(1),res.getInt(2),res.getString(3),res.getString(4)), res.getString(5)));

}

return fz;

}

Metodele corespunzatoare acțiunilor de înregistrare a datelor cardului în baza de date, precum și cea de extragere a acestor date și de afișare în fereastra ”Carduri”, sunt descrise de următoarele secvențe de cod:

public CardController(Connection conn){

this.conn=conn;

try {

ps1=conn.prepareStatement("INSERT INTO Carduri (CVV,DATA_EXPIRARE,NR_CARD) VALUES(?,?,?)");

ps2=conn.createStatement();

st1=conn.createStatement();

st2=conn.createStatement();

} catch (SQLException e) {

}

public boolean adaugaCard(String cvv, String dataExpirare, String nrCard){

try {

System.out.println(cvv + " " + dataExpirare+" "+nrCard );

ps1.setString(1,cvv);

ps1.setString(2,dataExpirare);

ps1.setString(3, nrCard);

ps1.executeUpdate();

conn.commit();

return true;

} catch (SQLException e) {

Logger.getLogger(CardController.class.getName()).log(Level.SEVERE, null, e);

}

return false;

}

Anexa 2

~Abrevieri~

SNEP – Sistemul Național Electronic de Plată

CNMSI – Centrul Național de Management pentru Societatea Informațională

MCSI – Ministerului Comunicațiilor și Societății Informaționale

PHARE – Poland and Hungary: Assistance for Restructuring their Economies

WAP – Wireless Application Protocol

ENEL – Ente Nazionale per l'energia ELettrica

PC – Personal Computer

SQL – Structured Query Language

POO – Programarea Orientată pe Obiecte

GUI – Graphical User Interface

IDE – mediu integrat de dezvoltare (Integrated Development Environment)

XML – Extensible Mark-up Language

Oracle ADF – Oracle Application Development Framework

JEE – Java Enterprise Edition

JSE – Java Standard Edition

JME – Java Mobile Edition

JDBC-Java Database Connectivity

SDK – Software Developer’s Kit

Oracle ADF – Oracle Application Development Framework

MVC – Model-View-Controller

HTML – Hyper Text Mark-up Language

JSP – Java Server Pages

ADF UIX – Application Development Framework User Interface XML

PL/SQL- Procedural Language/Structured Query Language

XDK – Oracle XML Developers Kit

IBM – International Business Machines

ANSI – American National Standards Institute

ISO – International Organization for Standardization

UML – Unified Modeling Language (Limbajul de Modelare Unificat)

OMT – Object Modeling Technique

OOSE – Object Oriented Software Engineering

JVM – Java Virtual Machine

JIT – Just-In-Time

JRE – Java Runtime Environment

JDK – Java Development Kit

Anexa 3

Lista figurilor

Figura 2.1 Evolutia limbajelor de programare

Figura 2.5 Structura mașinii virtuale Java

Figura 3.1.Analiza cerintelor

Figura 3.2 Diagrama generală a cazurilor de utilizare

Figura 3.2.1 Diagrama detaliată a cazurilor de utilizare: Autentificarea

Figura 3.2.2 Diagrama detaliată a cazurilor de utilizare: Inițierea acțiunii de plată a unei facturii.

Figura 3.2.3 Diagrama detaliată a cazului de utilizare: Plata facturii

Figura 3.3.1 Diagrama de activitate

Figura 3.4.1 Diagrama claselor

Figura 3.5.1 Schema conceptuală a bazei de date

Figura 4.1.1 Crearea conexiunii

Figura 4.1.2 Tabela Clienti

Figura 4.1.3 Tabela Factură

Figura 4.1.4 Tabela Carduri

Figura 4.1.5 Tabela Furnizori

Figura 4.2.1 Model-View-Controller

Figura 4.2.2 Transferul întregii baze de date in Jdeveloper

Figura 4.3.1 Încărcarea datelor in baza de date prin formularul de register

Figura 4.3.2 Tabela Clienți cu înregistrări inserate.

Figura 4.3.3 Mesaj de avertizare pentru cnp

Figura 4.3.4 Mesajul de eroare la scrierea gresită a utilizatorului sau a parolei

Figura 4.4.1 Fereastra principală a aplicației

Figura 4.4.3 Mesaj de confirmare

Figura 4.4.4 Fereastra de login

Figura 4.4.5 Fereastra „Meniu ” a aplicației

Figura 4.4.6 Alegerea utilitatii si a furnizorului

Figura 4.4.7 Introducerea detaliilor facturii

Figura 4.4.8 Afisarea platilor in fereastra de istoric a platilor

Figura 4.4.9 Plata cu cardul

Figura 4.4.10 Afisarea cardurilor folosite

Figura 4.4.11 Datele contului activ

Figura 4.4.12 Fereastra de modificare a parolei

Lista tabelelor

Tabelul 3.1. Exemple de cerințe care influențează arhitectura

Tabelul 3.2. Exemple de cerințe care acționează sub forma de constrângeri.

Bibliografie

Bogdan Căpraru, Activitatea bancară – Sisteme, operațiuni și practici, Ed. C.H. Beck, București, 2010, p.119.

Jean-Pierre Faugère, Moneda și politica monetară, Ed. Institutul European pentru Cooperare Cultural-științifică, Iași, 2000, p.31.

Tom Kokkola, The payment system Payments, securities and derivatives, and the role of the eurosystem, Ed. European Central Bank, Frankfurt am Main, 2010, p.25.

http://www.bnro.ro/Sisteme-de-plati-304.aspx

http://ro.wikipedia.org/wiki/Sistemul_Na%C8%9Bional_Electronic_de_Plat%C4%83

http://ro.wikipedia.org/wiki/Sistem_de_pl%C4%83%C8%9Bi#Procedeele_de_plat.C4.83

www.payu.row/companie/resurse-presa/comunicate-presa/220-milioane-euro-pentru-comertul-electronic-cu-plata-online/

http://www.telegrafonline.ro/ .

http://www.bugetulpersonal.ro/.

Peter Norton – Ghid de programare în Java, Editura Teora, București 1999

Baze de date. Fundamente teoretice și practice, Grupul BDASEIG, Editura Infomega, București, 2002

Călin Marin Văduva – Programarea în Java Editura Albastră, Cluj-Napoca 2000

http://inf.ucv.ro/~giurca/courses/CB3105/resources/Introducere%20in%20UML.pdf

http://www.aut.upt.ro/

http://teachercolecadm.wikispaces.com/

http://bdfr.cs.pub.ro/

http://inf.ucv.ro/

Ion Lungu, Constanta Bodea, Georgeta Badescu, Cristina Ionita, Baze de date organizare, proiectare și implementare, Editura All Educational, Bucuresti, 1995.

Velicanu Manole, Lungu Ion, Ionescu Simona, Muntean Mihaela, Sisteme de baze de date, Ed.Petrion Gaudeamus, București, 2003 Popescu, I., Modelarea bazelor de date – Editura Tehnica, Bucuresti 2001;

Anexe

Anexa 1

Codul sursă al clasei DbHelperLocal, main controllerul aplicației, unde după cum se poate observa în codul sursă este făcută conexiunea cu baza de date.

package Controller;

import Model.Carduri;

import Model.Client;

import Model.Furnizori;

import java.sql.Connection;

import java.sql.DriverManager;

import java.util.ArrayList;

import javax.sound.midi.ControllerEventListener;

public class DbHelperLocal {

Connection conn;

private static DbHelperLocal singleton;

public DbHelperLocal()throws Exception{

DriverManager.registerDriver(

new oracle.jdbc.driver.OracleDriver());

conn = DriverManager.getConnection ("jdbc:oracle:thin:@localhost:1521:orcl","system","par0la");

conn.setAutoCommit (false);

System.out.println("I am connected");

}

public static DbHelperLocal getInstance(){

if(singleton == null){

try {

singleton = new DbHelperLocal();

} catch (Exception e) {

}

return singleton;

}

Clasa ClientController unde se găsesc metodele necesare pentru acțiunea de înregistrare a clientului precum și pentru cea de conectare (logare) scrise în Jdeveloper în limbajul Java.

package Controller;

import Model.Client;

import Model.Factura;

import Model.Furnizori;

import com.sun.corba.se.pept.protocol.ClientInvocationInfo;

import java.sql.ClientInfoStatus;

import java.sql.Connection;

import java.sql.PreparedStatement;

import java.sql.ResultSet;

import java.sql.SQLException;

import java.sql.Statement;

import java.util.ArrayList;

import java.util.logging.Level;

import java.util.logging.Logger;

public class ClientController {

Connection conn;

PreparedStatement ps1;

Statement ps2;

Statement st1, st2;

public ClientController(Connection conn){

this.conn=conn;

try {

st1=conn.createStatement();

st2=conn.createStatement();

ps1=conn.prepareStatement("INSERT INTO CLIENTI (NUME,PRENUME,ADRESA,TELEFON,CNP,E_MAIL,PAROLA) VALUES(?,?,?,?,?,?,?)");

ps2=conn.createStatement();

} catch (SQLException e) {

}

public Client checkMail(String email){

try {

ResultSet rs = ps2.executeQuery("SELECT CODCLIENT,NUME,PRENUME,ADRESA,TELEFON,CNP,E_MAIL,PAROLA from CLIENTI where E_MAIL = '" + email + "'");

if(rs.next ())

{

return new Client(rs.getInt(1),rs.getString(2),rs.getString(3),rs.getString(4),rs.getInt(5),rs.getString(6),rs.getString(7),rs.getString(8));

}

} catch (SQLException ex) {

Logger.getLogger(ClientController.class.getName()).log(Level.SEVERE, null, ex); }

return null;

}

public boolean adaugaClient(String nume,String prenume,String adresa,int telefon, String cnp,String email,String parola){

if(checkMail(email)!=null){

return false;

}else{

try {

System.out.println(nume + " " + prenume + " " +adresa+" " + telefon + " " + cnp + " " + " " + email + " " + parola);

ps1.setString(1,nume);

ps1.setString(2,prenume);

ps1.setString(3,adresa);

ps1.setInt(4,telefon);

ps1.setString(5,cnp);

ps1.setString(6,email);

ps1.setString(7,parola);

ps1.executeUpdate();

conn.commit();

return true;

} catch (SQLException e) {

Logger.getLogger(ClientController.class.getName()).log(Level.SEVERE, null, e); }

}

return false;

}

public Client conectare(String email,String parola){

Client client = checkMail(email);

if(client != null){

if(client.getParola().equals(parola)) return client;

else return null;

}else return null;

}

Metoda necesară pentru realizarea acțiunii de afișare a detaliilor unei facturi, împreună cu statusul acesteia (plătită sau neplătită), în fereastra de istoric al plăților.

public ArrayList<Furnizori> getFurnizori(int codClient) throws Exception{

ArrayList<Furnizori> fz = new ArrayList<Furnizori>();

System.out.println("Cod client:"+codClient);

ResultSet res =st1.executeQuery("SELECT F.COD_FACTURA,F.CODCLIENT,F.SUMA,F.STATUS,FZ.DENUMIRE FROM FACTURA F,FURNIZORI FZ WHERE F.CODCLIENT="+codClient+" AND FZ.COD_FACTURA=F.COD_FACTURA AND F.STATUS='Neplatit'" );

while(res.next()){

System.out.println(res.getInt(1)+" "+res.getInt(2)+" "+res.getString(3)+" "+res.getString(4)+" "+res.getString(5));

fz.add(new Furnizori(new Factura(res.getInt(1),res.getInt(2),res.getString(3),res.getString(4)), res.getString(5)));

}

return fz;

}

Metodele corespunzatoare acțiunilor de înregistrare a datelor cardului în baza de date, precum și cea de extragere a acestor date și de afișare în fereastra ”Carduri”, sunt descrise de următoarele secvențe de cod:

public CardController(Connection conn){

this.conn=conn;

try {

ps1=conn.prepareStatement("INSERT INTO Carduri (CVV,DATA_EXPIRARE,NR_CARD) VALUES(?,?,?)");

ps2=conn.createStatement();

st1=conn.createStatement();

st2=conn.createStatement();

} catch (SQLException e) {

}

public boolean adaugaCard(String cvv, String dataExpirare, String nrCard){

try {

System.out.println(cvv + " " + dataExpirare+" "+nrCard );

ps1.setString(1,cvv);

ps1.setString(2,dataExpirare);

ps1.setString(3, nrCard);

ps1.executeUpdate();

conn.commit();

return true;

} catch (SQLException e) {

Logger.getLogger(CardController.class.getName()).log(Level.SEVERE, null, e);

}

return false;

}

Anexa 2

~Abrevieri~

SNEP – Sistemul Național Electronic de Plată

CNMSI – Centrul Național de Management pentru Societatea Informațională

MCSI – Ministerului Comunicațiilor și Societății Informaționale

PHARE – Poland and Hungary: Assistance for Restructuring their Economies

WAP – Wireless Application Protocol

ENEL – Ente Nazionale per l'energia ELettrica

PC – Personal Computer

SQL – Structured Query Language

POO – Programarea Orientată pe Obiecte

GUI – Graphical User Interface

IDE – mediu integrat de dezvoltare (Integrated Development Environment)

XML – Extensible Mark-up Language

Oracle ADF – Oracle Application Development Framework

JEE – Java Enterprise Edition

JSE – Java Standard Edition

JME – Java Mobile Edition

JDBC-Java Database Connectivity

SDK – Software Developer’s Kit

Oracle ADF – Oracle Application Development Framework

MVC – Model-View-Controller

HTML – Hyper Text Mark-up Language

JSP – Java Server Pages

ADF UIX – Application Development Framework User Interface XML

PL/SQL- Procedural Language/Structured Query Language

XDK – Oracle XML Developers Kit

IBM – International Business Machines

ANSI – American National Standards Institute

ISO – International Organization for Standardization

UML – Unified Modeling Language (Limbajul de Modelare Unificat)

OMT – Object Modeling Technique

OOSE – Object Oriented Software Engineering

JVM – Java Virtual Machine

JIT – Just-In-Time

JRE – Java Runtime Environment

JDK – Java Development Kit

Anexa 3

Lista figurilor

Figura 2.1 Evolutia limbajelor de programare

Figura 2.5 Structura mașinii virtuale Java

Figura 3.1.Analiza cerintelor

Figura 3.2 Diagrama generală a cazurilor de utilizare

Figura 3.2.1 Diagrama detaliată a cazurilor de utilizare: Autentificarea

Figura 3.2.2 Diagrama detaliată a cazurilor de utilizare: Inițierea acțiunii de plată a unei facturii.

Figura 3.2.3 Diagrama detaliată a cazului de utilizare: Plata facturii

Figura 3.3.1 Diagrama de activitate

Figura 3.4.1 Diagrama claselor

Figura 3.5.1 Schema conceptuală a bazei de date

Figura 4.1.1 Crearea conexiunii

Figura 4.1.2 Tabela Clienti

Figura 4.1.3 Tabela Factură

Figura 4.1.4 Tabela Carduri

Figura 4.1.5 Tabela Furnizori

Figura 4.2.1 Model-View-Controller

Figura 4.2.2 Transferul întregii baze de date in Jdeveloper

Figura 4.3.1 Încărcarea datelor in baza de date prin formularul de register

Figura 4.3.2 Tabela Clienți cu înregistrări inserate.

Figura 4.3.3 Mesaj de avertizare pentru cnp

Figura 4.3.4 Mesajul de eroare la scrierea gresită a utilizatorului sau a parolei

Figura 4.4.1 Fereastra principală a aplicației

Figura 4.4.3 Mesaj de confirmare

Figura 4.4.4 Fereastra de login

Figura 4.4.5 Fereastra „Meniu ” a aplicației

Figura 4.4.6 Alegerea utilitatii si a furnizorului

Figura 4.4.7 Introducerea detaliilor facturii

Figura 4.4.8 Afisarea platilor in fereastra de istoric a platilor

Figura 4.4.9 Plata cu cardul

Figura 4.4.10 Afisarea cardurilor folosite

Figura 4.4.11 Datele contului activ

Figura 4.4.12 Fereastra de modificare a parolei

Lista tabelelor

Tabelul 3.1. Exemple de cerințe care influențează arhitectura

Tabelul 3.2. Exemple de cerințe care acționează sub forma de constrângeri.

Copyright Notice

© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.

Acest articol: Proiectarea Unei Aplicatii Informatice a Unei Activitati Bancare Privind Sistemul de Plati (ID: 150236)

Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.

Proiectarea Unei Aplicatii Informatice a Unei Activitati Bancare Privind Sistemul de Plati

Copyright Notice

Proiectarea Unui Sistem Informational Privind Cotarea Si Tranzactionarea LA Bvb

Managemantul Tranzactiilor In Baze de Date Relationale

Biblioteca Digitala

Elaborarea a Unei Pagini Web

. Codec Uri de Linie. Notiuni Teoretice Privind Codoarele Si Decodoarele de Date

Problema de Clusterizare pe Date

Copyright Notice

Similar Posts