Cuprins ………………………….. ………………………….. ………………………….. ……………………….. 7 1…. [620966]

7
Cuprins

Cuprins ………………………….. ………………………….. ………………………….. ……………………….. 7
1. Introducere ………………………….. ………………………….. ………………………….. ……………….. 8
2. Programare. Fundamente Teoretice ………………………….. ………………………….. ………….. 9
2.1 Introducere în programare ………………………….. ………………………….. …………………. 9
2.2 Programare orientată pe obiecte ………………………….. ………………………….. ………… 10
3. Proiectarea și implementarea aplicației ………………………….. ………………………….. …… 11
3.1 Specificații ………………………….. ………………………….. ………………………….. ………… 12
3.2 Arhitectura aplicației ………………………….. ………………………….. ……………………….. 12
3.2.1 Schema generală ………………………….. ………………………….. ……………………….. 13
3.2.2 Proiectare UML ………………………….. ………………………….. ………………………… 14
3.2.3 Modulul Client ………………………….. ………………………….. …………………………. 24
3.2.4 Modulul Server ………………………….. ………………………….. …………………………. 27
3.2.5 Modulul traducere automată ………………………….. ………………………….. ……….. 29
3.2.6 Comunicare Client -Server ………………………….. ………………………….. ………….. 30
3.2.7 Tehnologii folosite ………………………….. ………………………….. ……………………. 35
4. Utilizarea aplicației ………………………….. ………………………….. ………………………….. ….. 43
4.1 Interfața grafică ………………………….. ………………………….. ………………………….. ….. 43
4.1.2 Modulul Server ………………………….. ………………………….. …………………………. 43
4.1.2 Modulul Client ………………………….. ………………………….. …………………………. 44
5. Concluzii ………………………….. ………………………….. ………………………….. ………………… 56
6. Bibliografie ………………………….. ………………………….. ………………………….. …………….. 58

8
1. Introducere

Din cauza dezvoltării tehnologice și economice, un număr important al
activităților umanității se situează pe o scală și un orizont atât de mari, încât au depășit
granițele naționale. Au apărut corporațiile multinaționale, piețele financiare globale și
comunic area între oameni a devenit tot mai complicată.
Din acest motiv, această lucrare de disertație se ocupă de proiectarea și realizarea
unei aplicații messenger pentru a face posibilă comunicarea între persoane care vorbesc
limbi diferite.
Fiecare utilizator selectea ză limba cunoscută în momentul deschiderii aplicației,
iar când trimite mesajele către persoana cu care comunică, aplicația traduce mesajul în
mod automat.
Aplicația se numește World Wide Messenger (WWM) și este scrisă în Java, un
limbaj de progr amare foarte răspândit. Am ales acest limbaj, deoarece f iind orientat pe
obiecte, unitățile care alcătuiesc un program, se apropie de modul de gândire a omului.
Lucrarea este structurată în trei capitole, fiecar e având mai multe subcapitole ,
urmate de o serie de concluzii și o listă de referințe bibliografi ce.
Capitolul 2 conține o introducere în programare, împreună cu un scurt istoric
despre primele tehnici ale acesteia, după care urmează fundamentele teoretice despre
programarea orientată pe obiecte.
Capitolul 3 se referă la proiectarea și implementarea aplicației. Sunt prezentate
toate elementele care stau la baza messengerului, de exemplu: specificațiile , schema
generală a aplicației și proiectarea cu ajutorul diagramelor UML. La sfârșitul acestui
capitol am prezentat tehnologiile si aplicațiile folosite în cadrul aplicației.
Capitolul 4 prezintă utilizarea aplicației și toate interfețele grafice ale acesteia.
Această lucrare prezintă aplicația care poate reprezenta o soluție în orice domeniu
pentru comunicarea persoanelor care nu cunosc o limbă. Totodată prezenta lucrare
cuprinde într -un instantaneu destul de detaliat, aspecte teoretice și practice ale
modalităților de concepere și implementare a aplicației.

9
2. Programare. Fundamente Teoretice
2.1 Introducere în programare

Programele de calculator sunt constituite dintr -o serie de instrucțiuni executate de
calculator. La crearea unui program trebuie avute în vedere aceste instrucțiuni pentru
realizarea operațiilor dorite. Procesul d e definire a instrucțiunilor executate de calculator
este numit programare.
Instrucțiunile utilizate de calculator sunt așa numite grupuri 1 și 0, adică cifre
binare, care sunt semnale electronice în interiorul calculatorului. Pentru programarea
primelor calculatoare (în anii 1940 -1950) trebuia înțeleasă modul de interpretare a
diferitelor combinații 0 și 1, unde programatorii scriau toate programele utilizând cifrele
binare. Acest mod de lucru a devenit incomod pentru programatori, deoarece prog ramele
au ajuns să fie din ce în ce mai mari. În acest sens cercetătorii au creat limbaje de
programare care au dat acces la o exprimare mai accesibilă a instrucțiunilor pentru om.
Un limbaj de programare este un set de expresii și reguli (sau tehnici) de formulare
a instrucțiunilor pentru un calculator. Acesta face posibilă programatorului specificarea
în mod exact acțiunilor executate de calculator. Pentru executarea unui program scris într –
un limbaj anume, există două abordări: compilarea sau interpreta rea. Compilarea constă
în faptul că programul -sursă este transformat de compilator în totalitate într -un program
echivalent scris în limbaj, care la urmă va fi executat. La interpretare, interpretorul va lua
prima instrucțiune din programul -sursă și o va transforma într -un limbaj pe care la urmă
o execută, după care trece la următoarea instrucțiune.
Limbajele moderne combină aceste două abordări, adică codul sursă este compilat
într-un limbaj binar numit bytecode care la rulare este interpr etat de către o m așină
virtuală .1

1Dr. Kris Jamsa & Lars Klander, Traducere de Eugen Dumitrescu, Totul despre C și C++ Manualul
fundamental de programare în C și C++, Editura Teora, București, 2007

10
2.2 Programare orientată pe obiecte

Programarea orientată pe obiecte este o paradigmă de programare care folosește
obiecte și interacțiuni pentru modelarea arhitecturii unui program.
Programarea orientată pe obiect este un p as important în evoluția limbajelor de
programare spre o puternică abstractizare a implementării programelor. Acesta a apărut
din necesitatea exprimării problemei într -un mod natural a ființei umane. Astfel unitățile
care alcătuiesc un program se apropie d e modul de gândire a omului mai mult decât la
modul de lucru al calculatorului. Până la apariția acestui tip de programare, programele
au fost puse în aplicare cu ajutorul programelor procedurale (C, Pascal) sau în limbaje
care nu oferă o modalitate de gru pare a instrucțiunilor în unități logice (funcții, proceduri),
ca de exemplu în cazul limbajului de asamblare (as sembler).
Conceptul de bază al programării orientate pe obiecte este Clasa. Aceasta grupează
datele și unitățile de prelucrare a ace stora într -un modul.
Clasele sunt grupate în module, pachete, programe, etc., care vor stabili legături
între ele. Legăturile prezintă relațiile care sunt stabilite între clasele sau obiectele
problemei care sunt preluate din natură.2
Principiile de bază a programării orientate pe obiecte sunt:
• Abstractizarea – este procesul de transformare a obiectelor reale în concepte virtuale ;
• Încapsularea – garantează faptul că obiectele nu pot modifica starea internă a altor
obiecte în mod direct (ci doar pr in metode implementate de obiectul respectiv) , aceste
transformări pot fi realizate doar de metodele proprii ale obiectului ;
• Polimorfismul – reprezintă capacitatea obiectelor de a conține funcționalități diferite
sub același nume. Aceeași metodă poate exec uta acțiuni diferite în funcție de locul în
care este implementat ;
• Moștenirea – permite definirea și crearea unor clase specializate, plecând de la clase
generale. Clasele particularizate pot extinde comportamentul claselor generale, fără a
fi nevoie de a le redefini.3

2https://docs.oracle.com/javase/tutorial/
3https://ro.w ikipedia.org/wiki/Programare_orientat%C4%83_pe_obiecte

11
3. Proiectarea și implementarea aplicației

Exist ă o mul țime structurat ă de activit ăți necesare pentru a dezvolta o aplica ție, și
anume: definirea specificațiilor și analiza, proiectarea și implementarea, verificarea,
testarea și evolu ția.
Definirea specificațiilor și analiza fac parte din procesul de stabilire a serviciilor
necesare, specificarea detaliată a funcționalităților ce trebuie să fie suportate de către
sistemul informatic. La sfârșitul procesului, se analizează și se realizează id entificarea
caracteristicilor esențiale tuturor soluțiilor corecte posibile.
Proiectarea și implementarea aplicației este un proces în care programatorii
convertesc specificațiile definite într -un sistem executabil. Proiectarea în sine înseamnă
realizarea unei structuri de aplicație care tre buie să rezolve specificațiile, iar
implementarea este translatarea acestei structuri de aplicație într -o aplicație executabilă.
În etapa de testare se validează faptul că implementarea respectă specificațiile și
cerințele clientului, presupune execuția sistemului într -un caz de utilizare cu date reale.
Ultima etapă de dezvoltare este evoluția aplicației, care a devenit tot mai
importantă în ultima vreme. Cerințele se schimbă foarte repede și aplicația trebuie să fie
cât mai flexibilă față de aceste schimbări. Chiar dacă a existat o separare între dezvoltare
și evoluție, aceasta este tot mai slabă, deoarece tot mai puține aplicații sunt complet noi.
Figura 01 reprezintă modelu l de dezvoltare a unei aplicații .

Fig. 01 – Modelul de dezvoltare a unei aplicații

12
3.1 Specificații

Aplicația prezentată în această lucrare este un chat care poate ușura comunicare a
între persoane care vorbesc limbi diferite.
Limba utilizată î n intermediul aplicației este selectată înainte de autentificare și
este cunoscut de parte nerii de comunicare pe tot parcursul sesiunii. Utilizatorul are
posibilitatea de a schimba limba folosită pentru comunicare după deconectare.
Autentificarea nu poate fi realizată fără înregistrarea utilizatorului, această
funcționalitate fiind disponibilă în fereastra de autentificare. După autentificare, clientul
primește lista utilizatorilor conectați la sistem. Din această listă poate selecta partenerul
de convorbire.
Fereastra de comunicare cu partenerul selectat, afișează limba aleasă de ambii
utiliza tori care participă la convorbire . Prin intermediul acestei ferestre se realizează
comunicarea în timp real, mesajele fiind traduse și afișate atât în limba selectată de fiecare
utilizator, cât și în limba originală în care mesajul a fost trimis.

3.2 Arhi tectura aplicației

În acest capitol am să prezint faza de proiectare și implementare a aplicației. E a
are în vedere activitatea de convertire a specificațiilor și cerințelor sistemului într -un
sistem executabil. Proiectarea și implementarea unei aplicați i sunt strâns legate și deseori
se suprapun.
Acest sub capitol este structurat în șapte subcapitole.
Subcapitolul (3.2.1) conține schema generală care prezintă pe scurt modul de
funcționare a aplicației.
Subcapitolul (3.2.2) tratează proiectarea aplicaț iei cu diagrame UML. În cadrul
proiectării am folosit patru tipuri de diagrame.
În subcapitolele (3.2.3) și (3.2.4) am prezentat modulul client și modulul server,
iar în subcapitolul (3.2.6) comunicarea între aceste două module.
Subcapitolul (3.2.5) prez intă modulul de traducere automată de la Microsoft, mai
precis API -ul. Acest serviciu reprezintă un element foarte important în cadrul aplicației.

13
Subcapitolul (3.2.7) se referă la tehnologiile și aplicațiile folosite în realizarea
programului ( Java, Ecli pse, XAMPP și MySQL ).

3.2.1 Schema generală

Figura 02 p rezintă pe scurt modul de funcțion are a aplicației .
Utilizatorii selectează limba în care doresc să desfășoare convorbirea pe parcursul
sesiunii de comunicare, în momentul autentificării. Parteneru l de convorbire astfel, va fi
informat pe tot parcursul sesiunii, des pre limba selectată de restul u tilizatorilor.
În acest exemplu concret, d upă autentificare începe convorbirea între cei doi
utilizatori . Primul utilizator trimite un mesaj în limba român ă către partenerul de discuții.
Pentru el totul este transparent, dar în spate, mesajul – care pe lângă textul care trebuie
tradus, conține numele utilizatorului expeditor și al utilizatorului destinatar – ajunge la
server.
Server ul trimite mai departe in formațiile – textul și limba în care acesta treb uie
tradus (de exemplu engleză) – către serviciul nor de traducere automată.
Când tradu cerea s -a desfășurat, serviciul nor trimite mesajul tradus la server, iar
acesta redirectează, pe baza numelui de utiliz ator destinatar , textul original și cel tradus
către utilizatorul numărul 2.
Când utilizatorul 2 răspunde la mesaj, totul se întâ mplă în același mod, doar în
direcția invers ă (traducere din engleză în română).

Fig. 02 – Schema generală

14

Fig. 03 – Diagrame UML
3.2.2 Proiectare UML

Limbajul de modelare (U ML – The U nified Modeling Language) reprezintă un
sprijin semnificativ în analiza și proiectarea aplicațiilor software, deoarece exprimă grafic
structura și comportamentul aplicației care urmează să fie implementată . Acest mod de
reprezentare ajută la înțe legerea funcționalităților, este un limbaj potrivit pentru
specificarea, vizualizarea, constr uirea și documentarea software. Modelarea se realizează
prin combinarea notațiilor UML în cadrul elementelor principal e ale acestora , numite
diagrame.
Aceste diag rame sunt prezentate și explicate în foarte multe moduri, deoarece, și
UML -ul – în concordanță cu toate sistemele informatice – continuă să fie actualizat și
îmbunătățit în funcție de necesitățile piețe i.
Cea mai răspândită reprezentare, împarte diagramel e în două categorii mari, și
anume: diagrame care reprezintă informații de structură sau de comportament. Cele de
comportament pot conține și informații legate de interacțiune cu alte elemente ale
sistemulu i.4

Figura 03 p rezintă diagramele UML c ele mai folosite după modalitatea de
reprezentare s pecificată mai sus.5

4Vasile Topac, Ingineria Sistemelor de Programare, Note de curs, 2015
5 https://en.wikipedia.org/wiki/Unified_Modeling_Language

15
La proiectarea acestei aplicații am ut ilizat 4 tipuri de diagrame UML (folosind
programul Star UML 2.4.06:
• diagrama cazurilor de utilizare ( use case) prezintă funcțiile sistemului din p unct de
vedere al utilizatorului, având ca arce relațiile dintre grafurile de actori și cazurile de
utilizare ;
• diagrama de secvență arată șirul evenimentelor care apar în timpul unei interacțiuni
a utilizatorului cu sistemul;
• diagrama de activități prezint ă comportamentul unei operațiuni în termeni de
acțiuni, acestea fiind cazuri particulare ale diagramelor de stare. Acestea însă nu arată
un flux de control bazat pe evenimente, ci o procedură, unde toate tranzițiile sau o
mare parte a lor se efectuează aut omat, la terminarea acțiunilor în interiorul stării;
• diagrama de clase reprezintă structura statică în termeni de clase și relații, aceste
diagrame fiind g rafuri având ca noduri în genera l clase, dar putând conține și pachete,
interfețe sau chiar obiecte, iar ca arce relațiile dintre aceste elemente.
Figura 04 reprezintă așa numita diagramă use case sau diagrama cazurilor de
utilizare și ilustrează modurile de utilizare a sistemului. Utilizatorul se poate înregistra și

6http://staruml.io/
Fig. 04 – Moduri de utilizare – Diagrama us e case

16
autentifica la sistem, are posibilita tea de a trimite și a primi mesaje, după care se poate
deconecta.
În timpul înregistrării, serverul verifică validitatea datelor în concordanță cu
conținutul bazei de date (de exemplu, nume de utilizator existent), după care – în cazul în
care datele sunt valide – salvează informațiile în baza de date.
Autentificarea se poate face doar după o înregistrare reușită cu datele de
autentificare stabilite în urma înregistrării. În mod a semănător cu procedura de
înregistrare, și în cazul autentificării se verifică corectitudinea datelor în baza de date.
Dacă numele de utilizator sau parola nu corespunde, autentificarea nu se poate efectua.
Este important de menționat faptul că, limba folosită pe tot parcursul sesiunii de
convorbire, se selectează înainte de autent ificare.
După o autentificare reușită, utilizatorii pot trimite și recepționa mesaje. Orice
mesaj, va fi transmis prima dată către server împreună cu numele de utilizator destinatar.
Serverul – precum la autentificare toți utilizatorii au selectat limba în care doresc să
comunice – cunoaște limba folosită de destinatar și cere de la API -ul Translator traducerea
mesajului în limba respectivă.
Mesajul tradus, este trimis către destinatar împreună cu mesajul original. Acest
lucru este necesar, deoarece nu toat e cuvintele existente au varianta corespunzătoare în
baza de date a translatorului și se pot crea confuzii.
Ultima funcționalitate prezentată în diagramă este deconectarea. Utilizatorul
poate părăsi chat -ul prin apăsarea butonului Sign -Out.

Pentru cazuril e mai complexe, cum ar fi înregistrarea, autentificarea și
trimitea/recepționarea mesajelor am pregătit câte o diagram ă de secvență (sequence
diagram ), care are ca scop prezentarea șirului de evenimente care apar în timpul
interacțiun ii utilizatorului cu s istemul .

17

Diagram a de mai sus reprezintă procesul de înregistrare al unui utilizator (Fig.
05). După des chiderea aplicației și înainte de autentificare, utilizatorul apasă butonul de
înregistrare și se deschide fereastra cu formularul de înregi strare. Câmpurile care trebuie
completate în mod obligatoriu de către client sunt: nume utilizator, parolă , nume, prenume
și adresă e-mail. Numărul de telefon, țara și data nașterii sunt câmpuri opționale.
Majoritatea formularelor de înregistrare, conțin încă d ouă câmpuri care au un rol
semnificativ în selectarea numelui de utilizator și a parolei, deoarece obligă utilizatorul
să introducă același nume de utilizator și aceeași parolă de două ori. Astfel șansele de a
Fig. 05 – Înregistrare – Diagram ă de secvență

18
introduce o informație nedorită scad. Pentru a ceastă dublă -verificare se folosesc
câmpurile confirmare nume utilizator și confirmare parolă.
Datele completate sunt verificate parțial direct de către modulul client ( câmpurile
obligatorii, reverificarea mai sus menționată și formatul adresei de e -mail), respectiv de
către server în baza de date (nume utilizator existent) .
După terminarea procesului de verificare, în caz de eșec, toate greșelile constate
sunt afișate într-un singur mesaj și utilizatorul este rugat să corecteze datele necesare
înregistrăr ii.
În cazul în care toate informațiile introduse sunt corecte, modulul client trimite
datele completate către server, care încearcă salvarea lor în baza de date.
Având ca premisă faptul că baza de date există, conexiunea între server și bază de
date este activă, datele se vor salva și utilizatorul va fi informat cum că înregistrarea s -a
făcut cu succes. În diagrama de mai sus este prezentat și cazul contrar.

19

A doua diagramă de secvență prezintă procesul de autentificare ( Fig. 06). După
deschid erea aplicației, apare fereastra de autentificare. Presupunând că utilizatorul a
trecut de procesul de înregistrare, el poate introduce numele lui de utilizator și parola
selectată anterior.
Asemănător cu validarea din procesul de înregistrare , unele infor mații sunt
verificate doar de către modulul client: utilizatorul trebuie să completeze în mod
obligatoriu câmpurile nume utilizator și parolă .
Înainte de autentificare, serverul verifică în baza de date num ele de utilizator și
parola introduse de client. Dacă informațiile introduse se găsesc printre înregistrările
bazei de date, utilizatorul se poate conecta.
Fig. 06 – Autentificare – Diagram ă de secvență

20
În caz ul în care condițiile de mai sus nu sunt îndeplinite (câmpuri obligatorii
necompletate sau da te de autentificare incorecte) , serverul trimite un mesaj de eroare către
client, el având posibilitatea de a corecta datele .
Dacă utilizatorul a introdus toate datele corect va primi mesajul de autentificare
cu succes de la server și va apare fereastra principală de WWM .
Ultima diagramă de secvență prezintă procesul de convorbire ( Fig. 07). În cadrul
ferestrei principale, din lista utilizatorilor conectați, Utilizatorul 1 selectează partenerul
de comunicare și apare fereastra de conv orbire pentru cei doi. După introducerea textului
și apăsarea butonului Trimite, Utilizatorul 1 trimite mesajul către server împreună cu
numele utilizatorului destinatar (Utilizator 2).
După căutarea limbii selectate de către Utilizatorul 2 în structurile interne, server –
ul înaintează translatorului textul, împreună cu limba în care acesta trebuie tradus.
Translatorul efectuează traducerea și răspunde serverului. Mesajul original și cel
tradus va fi transmis, pe baza numelui de utilizator destinatar, către fereastra de
convorbire aferentă Utilizatorul 2.
După ce mesajele apar în fereastra de convorbire, Utilizatorul 2 are posibilitatea
de a răspunde în timp real, iar procedura va fi identică și în direcție opusă.

Fig. 07 – Convorbire – Diagram ăde secvență

21

Fig. 08 – Diagram ă de activități

22
După diagr amele de secvență am pregătit o diagramă de activitate ( activity
diagram ), care arată fluxul de lucru în cadrul aplicației (Fig. 08). Acest tip de diagram ă
este caracterizat prin încadrarea activităților aplicației între punctele start și stop.
În fereastr a de autentificare trebuie luată decizia, dacă utilizatorul este unul nou
sau a fost înregistrat deja. În cazul în care este vorba de un utilizator nou, în prima e tapă
trebuie să se înregistreze; iar în cazul în care este vorba de un utilizator înregistrat , acesta
cunoaște numele de utilizator și parola și se poate autentifica. În urma completării
incorecte apar e un mesaj de eroare, iar în caz contrar se poate desfășura autentificarea.
După o autentificare cu succes, utilizatorul poate alege o persoană din lista
utilizatorilor conectați la sistem și se va începe convorbirea între cei doi.
În urma trimiterii mesajului de expeditor către destinatar, server -ul verifică dacă
convorbirea este multi – sau mono -lingvă . În cazul convorbirii mono -lingve mesajul nu
trebuie tradus și va apare direct în fereastra de convorbire a utilizatorului destinatar. Dacă
convorbirea este multi -lingvă, serverul trimite textul care trebuie tradus la MS Translator
API și așteaptă răspunsul. Mesajul tradus ajunge la server, după care se transmite
utilizatorului destinatar.
Partenerul de discuții are posibilitatea de a răspunde și în acest caz, acțiunile se
vor desfășura în același mod, doar în direcția inversă.
În cazul în care un client nu mai dorește să comunice cu utilizatorii con ectați la
sistem se poate deconecta și sesiunea de lucru se sfârșește.
Întregul program Java este împărțit în 7 pachete și anume:
• server.communication și client.communication – sunt pachetele care conțin toate
clasele folosite de modulul server , respectiv client pentru comunicare ;
• server.gui și client.gui – includ clasele care se folosesc pentru crearea interf eței
grafic e în module le server și client ;
• tools – conține clasele care comunică cu baza de date, respectiv cu serviciul nor de
traducere automată;
• dataStructures – acest pachet cuprinde clasele care sunt folosite ca și structuri de date
specifice aplicației;
• constants – în acest pachet sunt definite toate constantele ce se utilizează în timpul
comunicării între server și client.

23
În continuare am să p rezint structura claselor folosite în cadrul aplicației cu
ajutorul diagramelor de clase (class diagram).
O diagramă de clasă modelează st ructura unui program, surprinde conexiunile
semantice sau interacțiunile care se stabilesc între elementele componente .7
Componentele acestor diagrame conțin informații im portante despre o anumită
clasă, cum ar fi numele clasei, variabilele, met odele și vizibilitatea datelor.
În realizarea diagramei de clase din Figura 09 am folosit plug -in-ul ObjectAid
UML Explorer pentru Eclipse.8
Clasele, după cum arată și diagrama de mai sus, sunt împărțite – pe baza tehnicii
folosite – în două categorii: partea de server, respectiv partea de client. Cele mai
importante clase din subsecțiunile prezentate, sunt fișierele de bază Serv erSide -, respectiv
ClientSideCommunicator, care asigură comunicarea între cele două module. Restul
claselor sunt legate de aceste două clase de bază.
În continuare voi prezenta în detaliu cele două module.

7 http://software.ucv.ro/~aion/ip/Laborator4/Diagram e%20de%20clase.pdf
8 http://www.objectaid.com
Fig. 09 – Diagrame de clase

24
3.2.3 Modul ul Client

În ultima vreme aplicațiile folosite devin tot mai complexe, nevoia de resurse și
numărul utilizatorilor crește. Din acest motiv, majoritatea aplicațiilor sunt împărțite în
două module: client și server. Introducerea și afișarea datelor nu necesită performanță
mare, astfel poate fi e fectuată și de o platformă mai slabă – în modulul client. Server -ul
în schimb trebuie să fie mai performant, deoarece m enținerea diferitelor relații între
obiecte, stocarea și prelucrarea datelor au nevoie de surse mai puternice. În anumite cazuri
modulul server și modulul client rulează pe același calculator.
În acest subcapitol voi prezenta modulul client. După cum se poate observa în
diagrama de clasă pentru modulul client ( Figura 1 1), punctul de pornire pentru client este
clasa LoginScreen . Această clas ă construiește interfața grafică pentru accesarea ferestrei
de autentificare în metoda buildContentPane() .
Tot din această fereastră se pornește înregistrarea unui utilizator nou. Clasa care
se ocupă de această funcționalitate se numește Regist ration Scree n. După introducerea
datelor folosite pentru înregistrare (nume de utilizator, parolă, date personale), acestea
vor fi verificate de către sistem. Pe lângă verificarea existenței numelui de utilizator în
baza de date, se validează și adresa de e -mail intro dusă de către utilizator.
Formatul valid a unei adrese de e -mail este prezentat în Figura 10, orice adresă de
e-mail fiind împă rțită în partea locală și partea de domain.

O adresă de e -mail validă trebuie să c orespundă următoarel or cerințe:
• trebuie să conțină în mod obligatoriu un simbol ”@”
• după simbolul ”@ ” nu poate apare imediat simbolul “.”
• după ultimul simbol ”.” trebuie să se afle minim două caractere
• primul caracter din adresă nu poate fi simbolul ”.”
Fig. 10 – Format e -mail valid

25
• partea locală poate conține oricare dintre următoarele caractere:
o litere latine mici și majuscule
o numere între 0 și 9
o următoarele caractere speciale: #-_~!$&‘()*+,;=:
o caracterul . nu poate fi primul sau ultimul și nu poate apărea în mod
consecutiv
o caracterele speciale sunt permise cu restricții: Space și “(),:;<>@[ \]9

În continuare am să prezint c lasa principală al modul ului client, și anume
ClientSideCommunicator . Funcționalitatea acest ei clase este invizibilă de către client,
dar vitală din punct de vedere a aplicației. Aceasta conține mai multe metode importante,
care au ca scop crearea și menținerea relației între client și server. În afară de acest lucru
mai sunt prezente metode care servesc la înregistrare, autentificare/deco nectare și
trimiterea mesajelor ( connect() , login() , logout() , register() , sendMessage() ).
Clasa MessengerMainScreen conține din nou o interfață grafică, este fereastra
principală a World Wide Messenger -ului, care apare după o conexiune stabilită cu succes
între client și server, în momentul autentificării. Încarcă lista utilizatorilor conectați la
sistem și cu ajutorul metodelor accountLoggedIn() , respectiv accountLoggedOut()
actualizează această listă în momentu l în care un alt utilizator intră în camera de chat,
respectiv se deconectează de la sistem.
AccountForList este o clasă care joacă un rol foarte important în cadrul aplicației,
reprezintă o structură de date stabilită pentru lista de utilizatori din cadru l ferestrei
principale. Această structură conține informațiile necesare despre un utilizator în cadrul
interfeței grafice: nume de utilizator, limba selectată, nume și prenume.
Rolul clasei MessageReceiverThread este de a rula un fir de execuție care ascul tă
după mesaje asincrone (mesaje de notificare, care pot veni în orice moment, fără cererea
clientului), cum ar fi: primirea unui mesaj de la un alt utilizator sau notificări în momentul
în care un utilizator se conectează la sistem, respectiv se deconecte ază.

9 https://en.wikipedia.org/wiki/Email_address

26

După trimiterea sau recepționarea unui mesaj, din fereastra principală se deschide
MessengerMessageDialogScreen pentru fiecare pereche de utilizatori . Numărul
ferestrelor ce se poate deschide este limitat de numărul utiliz atorilor conectați la sistem.
Metoda buildContentPane() construiește interfața grafică pentru această fereastră de
convorbire.
Fig. 11 – Diagrame de clase – Modulul Client

27
3.2.4 Modul ul Server

Datorită faptului că o aplicație de tip messenger prelucrează multe informații, este
necesară implementar ea unui modul server, care se ocupă de sarcinile mai complexe, cum
ar fi în cazul nostru: traducerea mesajelor utilizând un translator API înainte de expediere
și salvarea datelor utilizatorilor într -o bază de date.
Modulul server stă la baza funcționării aplicației, fără pornirea acestuia, partea de
client nici nu are la ce să se conecteze .
Pornirea modului server se face din fereast ra de a dministrator. Interfața grafică
este construită în clasa AdminScreen , metoda buildContentPane() .
În Figura 12 se poat e observa clasa de bază a acestui modul, și anume
ServerSideCommunicator. Având implementate metodele initServer() , stopServer() și
manageClient() este responsabil pentru funcționalitățile de bază a unei aplicații de tip
client -server, și anume: pornirea ș i oprirea server -ului și administrarea conexiunilor
pentru fiecare client în parte.
ManageClientThread este o clasă care are un rol important, creează un fir de
execuție pentru fiecare utilizator conectat în parte. Pe acest fir trimite mesajele sincrone
și așteaptă răspuns pentru ele, cum ar fi: cererea de autentificare, de deconectare sau de
înregistrare.
Clasa SingletonHashMap folosește șablonul de design (o soluție generală și
reutilizabilă a unei probleme comune în design -ul software) numit Singleton, care este
utilizat pentru restricț ionarea numă rului de instanț ieri ale unei clase la un singur obiect.
Cu ajutorul acestei soluții m -am asigurat de faptul că lista de utilizatori care sunt online
este unică (onlineAccsThreadMap) și orice modificare asupra ei va avea un rezultat
corect.
Clasa MySQLConnector reprezintă un instrument care ajută la conectarea
server -ului la baza de date. Prin intermediul metodei addUserAtRegistration()
implementate serverul salvează datele utilizatorului în baza de date în urm a înregistrării
clientului. Metodele usernameAlreadyExists() și isValidUserAndPass() sunt folosite
pentru verificări ulterio are, cum ar fi: în momentul autentificării se verifică dacă numele
de utilizator și parola există în baza de date (înregistrarea s -a efectuat cu succes), iar în
cazul procesului de înregistrare se verifică existența numelui de utilizator selectat.

28

Fig. 12 – Diagrama de clase – Modulul Server

29
Cel mai important instrument în cadrul modulului server, sau chiar și în cadrul
aplicației poate fi numit translatorul. Clasa MSTransl ator asigură comunicarea între
modulul server și serviciul de nor de traducere automată și efectuează prin metoda
translateFromTo() traducerea mesajelor primite de la server în limba solicitată.
Ultima clasă din modulul server reprezintă structura de date stabilită pentru un
obiect de tip utilizator. Account grupează datele de utilizator: nume utilizator, parolă ,
limba selectată, nume, prenume și starea conexiunii într-o variabilă de tip boolean, care
poate fi conectat (adevărat) sau deconectat (fals).

3.2.5 Modul ul traducere automată

Microsoft Translator API10este un serviciu nor de traducere automată care suportă
peste 95% din limbile existente din lume. Poate fi folosit pentru a dezvolta aplicații, web
site-uri și instrumente, sau când este nevoie de o soluție care necesită un sprijin
multilingvă (vezi Figura 1 3).

Acest API este o soluție dovedită, scalabilă și personalizabilă pentru o traducere
automată . Se poate integra în orice platformă, se poate folosi sub orice sistem de operare
pentru a efectua o traducere sau alte operațiuni legate de limbă, cum ar fi detectarea limbii,
text to speech sau dicționar. Funcționează atât în traducerea în web, desktop sau aplicații
mobile . Oferă o funcționalitate bogată pentru orice dezvoltator , are o gamă largă de
interfețe : AJAX , HTTP , SOAP , OData și traducător WebWidget .

10https://www.microsoft.com/translator/api.aspx
Fig. 1 3 – Sistem de traducere automată

30
Sisteme le de traducere automată sunt aplicații sau servicii online care utilizează
tehnologia “m achine -learning” pentru a traduce o cantitate mare de text , având ca text de
intrare și ieșire orice combinație între limbile suportate.
Deși conceptul și interfețele pentru utilizarea acestor sisteme sunt relativ simple,
știința și tehnologia în spatele lor sunt extrem de complexe și îmbină mai multe tehnologii
de vârf, cum ar fi pe lângă machine -learnin g, big data, lingvistică, cloud computing și
web API -uri.11

3.2.6 Comunicare Client -Server

La baza majorității aplicațiilor care comunică prin rețea stă arhitectura Client –
Server (Fig. 1 4). Aceasta presupune un mod de implementare distribuită a aplicațiil or
destinate lucrului în rețea: există doi actori implicați în procesul de comunicație p recum
și un set comun de reguli .

Clientul și serverul folosește același mediu de comunicație, mai precis un canal
de comunicație care permite circulația in formației de la server către client și invers. Acest
canal de comunicație este rețeaua.

11 https://code.google.com/p/microsoft -translator -java-api/
Fig. 14 – Arhitectura Client -Server

31
Setul de reguli care este cunoscut și aplicat de actorii impl icați în procesul de
comunicare, se numește protocol.12
Protocolul creat pentru comunicarea în cadrul aplic ației World Wide Messenger
va fi prezenta t în acest capitol cu ajutorul Figurii 1 5. Diagrama care prezintă clasa
CommunicationConstants , conține tipurile de mesaje, separatorii folosiți în timpul
comunicării, precum și elementele mesajelor.

12Vasile Topac, Programarea Sistemelor Automate Distribuite , Note de curs, 2015

Fig. 15 – Diagrama de clase – CommunicationConstants

32
Primele trei constante din imaginea de mai sus sunt folosite pentru inițierea și
stabilirea conexiunii între client și server. Acestea reprezintă adresa de IP
(COMMUNICATION_HOST ) și port -ul (COMMUNICATION_PORT ) server -ului la
care se va conecta client -ul și numărul maxim de conexiuni
(MAX_CONNECTION_NUMBER ) ce suportă server -ul. Acest număr, în momentul de
față este 10, dar după testarea și optimizarea aplicației poate crește.
Mesajele transmise între client și server pot fi împărțite în mesaje sincrone și
asincrone. În cazul mesajelo r sincrone, după ce clientul trimite o cerere (request) către
server așteaptă un răspuns (response) de la acesta (de exemplu, în cazul înregistrării,
autentificării sau a deconectării). Mesajele asincrone sunt trimise către client și conțin de
obicei notif icări, de exemplu: conectarea sau deconectarea unui alt utilizator la sistem sau
primirea textului tradus de la partenerul de convorbiri.
Mesajele sincrone (perechile de cerere și răspuns) utilizate pentru comunicarea
între client și server în cadrul aplic ației prezentate sunt următoarele:
MSG_TYPE_REQUEST_LOGIN și MSG_TYPE_RESPONSE_LOGIN sunt folosite
pentru autentificare, MSG_TYPE_REQUEST_LOGOUT și
MSG_TYPE_RESPONSE_LOGOUT pentru deconectare, respectiv
MSG_TYPE_REQUEST_REGISTER și MSG_TYPE_RESPONSE_REGIST ER pentru
înregistrarea utilizatorului la sistem.
Mesajele asincrone care apar și în Figura 1 5 sunt
MSG_TYPE_SEND_MESSAGE, MSG_TYPE_READ_MESSAGE – folosite pentru
trimiterea textului către server pentru traducere și redirecționarea textului tradus către
destinatar, respectiv MST_TYPE_ACC_LOGIN și MST_TYPE_ACC_LOGOUT –
utilizate pentru notificarea partenerilor de comunicare după conectarea sau deconectarea
unui utilizator.
În cadrul oricărui protocol de comunicare între client și server (vezi Figura 1 6),
mesajele sunt împărțite cu ajutorul unor separatori (TAG_SEPARATOR,
FIELD_SEPARATOR și ITEM_SEPARATOR), care delimitează informațiile concrete
transmise și etichetele folosite (USERNAME, PASSWORD, LASTNAME,
FIRSTNAME, PHONE, EMAIL. COUNTRY, BIRTHDATE, LANGUA GE, FROM,
TO și TEXT).

33
Majoritatea etichetelor de mai sus se folosesc pentru înregistrarea clientului la
sistem. USERNAME și PASSWORD sunt refolosite și în mesajul de autentificare, iar
FROM, TO, TEXT se utilizează în timpul convorbirii între clienți.
Am ales ca și exemplu concret mesajul de cerere pentru înregistrare la sistem, prin
care am să prezint protocolul de comunicare folosit în cadrul aplicației World Wide
Messenger.

În urma completării formularului de înregistrare, datele introd use de client, sunt
trimise ca și parametrii către metoda register() din clasa ClientSideCommunicator –
aceasta făcând parte din modulul client al aplicației. În cadrul acestei metode se
construiește – pe baza protocolului definit – mesajul de cerere (req uest), care ulterior va
fi trimis către server.
Ultima parte a Figurei 1 7 prezintă mesajul construit înainte de trimiterea acestuia
către server.
Fig. 16 – Protocolul de comunicare
Fig. 17 – Fragment de cod Java – Modulul Client

34

Fragmentul de cod din Figura 1 8 face parte din clasa ManageClientThread din
cadrul modul ui server a aplicației.
Dacă tipul de mesaj primit de la client este o cerere de înregistrare ( REQ_REG ),
serverul descompune mesajul primit – cu ajutorul protocolului definit – pentru a accesa
informațiile transmise. Dacă aceste date sunt salvate cu succe s în baza de date, serverul
pregătește răspunsul pentru client ( RESP_REG ). În cadrul Figurii 17 se poate observa
cum că înregistrarea utilizatorului s -a efectuat cu succes și serverul pregătește răspunsul
pentru a trimite clientului.

Fig. 18 – Fragment de cod Java – Modulul Server

35
3.2.7 Tehnologii f olosite
3.2.7.1 Java. Caracteristicile limbajului

Java este un limbaj de programare orientat pe obiecte. Acest limbaj s -a înființat în
anul 1991, când compania Sun Microsystems (în zilele noastre filială Oracle) a finanțat
un proiect, numit G reen, condus de James Gosling.
Caracteristicile limbajului Java:
• este un limbaj compilat și interpretat. Limbajul este compilat dacă programul scris în
acel limbaj de programare este tradus într -un cod pe care un calculator îl poate executa
mai ușor. De asemenea, putem vorbi de un limbaj interpretat dacă instrucțiunile unui
program sunt efectuate linie cu linie.
• este un limbaj independent de platformă. În momentul instalării limbajului Java, va fi
creată o mașină virtuală Java (Java Virtual Mach ine – JVM) care are drept țintă
traducerea instrucțiunilor unui byte code Java în instrucțiuni -mașină pentru platforma
curentă. Astfel fișierele pot fi copiate și executate pe orice platformă.
• este un limbaj orientat pe obiecte. Cea mai importantă propriet ate a limbajului Java.
Acest limbaj pune în evidență toate aspectele legate de programare orientată pe
obiecte, mai exact: trimiterea parametrilor, obiecte, încapsulare, clase, biblioteci,
moștenire și modificatori de acces.
• este un limbaj concurent. Concu rența (multithreading) – este abilitatea unui program
de a executa mai multe secvențe de cod deodată. O secvență de cod în limbajul Java
se numește fir de execuție (thread).
• este un limbaj distribuit. Java permite folosirea obiectelor locale și la distanț ă, astfel
putem afirma că este distribuit. Respectă standarul IEEE (Institute of Electrical and
Electronics Engineers) pentru structurile de date, ca de exemplu folosirea întregilor,
numerelor în virgulă flotantă și a șirurilor de caractere. Java se poate utiliza în aplicații
de rețea, fiindcă respectă protoco alele de rețea, cum ar fi FTP, HTTP, SOAP, etc.
• este un limbaj performant. Are posibilitatea să lucreze cu fire de execuție multiple și
astfel este capabil să execute un byte code aproape la fel de re pede ca pe un cod
compilat. Un program Java poate să aștepte citirea unor date, în timp ce un alt fir de
execuție poate aloca sau elibera memoria necesară programului.

36
• este un limbaj dinamic și robust. Java este dinamic, deoarece întârzie până la momentul
execuției alocarea obiectelor și legarea claselor. Astfel se evită erorile de alocare, chiar
dacă mediul s -a modificat de la ultima compilare a programului. Java este un limbaj
robust, fiindcă a fost eliminată utilizarea pointerilor, care a fost generatoar ea de erori
în alte limbaje de programare. Java verifică memoria dinamic, înainte de alocare.
• este un limbaj sigur. Java alocă memoria doar la execuție și nu folosește pointeri, nu
poate accesa memoria heap, stack sau alte secțiuni protejate de memorie. Î nainte de
executare, programul verifică dacă este un cod valid Java, prin intermediul cercetării
accesului la date.
Limbajul Java poate fi instalat pe calculatoare cu diverse sisteme de operare, cum
ar fi Windows, Linux sau Solaris . Un program Java nu se execută direct de către
microprocesor, ci folosește o mașină virtuală (Java Virtual Machine – JVM).
Pentru crearea și editarea programului Java se poate utiliza orice editor de texte,
dar totuși este recomandat folosirea unui editor specializat, pentru că acestea reduc
semnificativ timpul de dezvoltare a aplicațiilor. Unele dintre cele mai importante medii
de programare pentru Java este Eclipse și NetBeans.13

3.2.7.2 Eclipse

În cazul utilizării unui editor de text simplu, dezvoltarea aplicații lor complexe
Java pot deveni foarte dificile. În aceste condiții programatorul trebuie să aleagă și să
instaleze o aplicație care să -l ajute în dezvoltarea aplicațiilor. O astfel de aplicație poartă
numele de IDE (Integrated Development Enviroment).
Un mediu de dezvoltare (IDE) este un set de programe care ajută programatorul
în scrierea codului unei aplicații. Un mediu de dezvoltare combină pașii necesari creării
unui program (de exemplu: editarea codului sursă, compilare, rulare, depanare) înt r-un
singur soft, care oferă o interfaț ă grafică cu utilizatorul.
Eclipse este un mediu de dezvoltare open -source scris preponderent în Java.
Acesta este folosit pentru dezvoltarea aplicațiilor Java. Eclipse cuprinde o mașină virtuală

13 Ștefan Tanasă & Ștefan Andrei, Cristian Olaru, Java de la 0 la expert Ediția a II -a, Editura Polirom, 2011

37
și un set de funcțio nalități de bază, la care se pot adăuga ulterior diverse unelte de
dezvoltare sub forma unor plugin -uri. Mediul de dezvoltare pentru Java este prezentată în
Figura 1 9.14

3.2.7.3 XAMPP

XAMPP este un pachet de software și open source cross -platform (rulare identică
pe platforme diferite) folosit pentru crearea paginilor web dinamice în mod localhost
(modulul client și server fiind pe același calculator) . Pachetul interpretează scripturi scrise
în limbajele PHP și PERL, constând în principal din server de web Apache. XAMPP a
fost creat pentru a pune la dispoziția dezvoltatorilor un in strument eficient de testare.
Pachetul de aplicații simulează comportament ul unui server conectat la Internet, astfel

14 https://eclipse.org/
Fig. 19 – Eclipse Luna ver. 4.4 – Mediul de dezvoltare Java

38
permițând testarea a plicațiilor scrise înainte de copierea acestora pe serverul real al firmei
care va deține produsul software lansat .15
Caracteristicile principale sunt ale acestui pachet software sunt:
• este un ser ver web folosit pentru implementarea aplicațiilor în mod localhost ;
• instal ează aplicațiile Apache, MySQL, PHP, Perl, phpMyAdmin, FileZilla FTP
Server, etc.;
• este stabil, sigur, rapi d și eficient;
• are o interfață simplă și intuitivă, astfel este ușor de folosit.16
Din aplicațiile instalate de pachetul software XAMPP, am folosit în cadrul
implementării aplicației World Wide Messenger, serviciul MySQL pentru conectarea la
baza de date. Figura 20, prezintă interfața grafică al pachetului XAMPP având serviciul
MySQL pornit.

15 https://www.apachefriends.org/ro/index.html
16 Cristina Băla, Tehnologii Web, Note de curs, 2015
Fig. 20 – XAMP P Control Panel v3.2.1 – Interfața XAMPP

39
3.2.7.4 Baze de date . MySQL

Baza de date este o colecție de date, creată și menținută computerizat, pentru
prelucrarea datelor în contextul unui set de aplicații. Prelucrarea datelor constă din
operațiuni de culegere, memorare, organizare, regăsire, prelucrare și administra re a unui
volum mare de date. Arhitectura unei baze de date reprezintă modul de organizare a
datelor, între calculatorul care operează asupra datelor sub forma de biți și utilizatorul
bazelor de date. Nivelele de independență și de abstractizare a datelor sunt caracteristice
arhitecturii unei baze de date.
Pentru asigurarea independenței datelor se impune adoptarea unei arhitecturi
organizate pe cel puțin trei nivele. În funcție de nivelul de abstractizare se po t identifica
următoarele nivele:
• nivelul int ern (baza de date fizică);
• nivelul con ceptual (modelul conceptual sau schema conceptuală);
• nivelul extern (modelul extern, subschemă, vedere).
Figura 2 1 reprezintă arhitectura unei baze de date .

Fig. 21 – Schema generală a unei baze de date

40
Nivelul intern, numit și baza de date fizică este o colecție de fișiere care conține
date fizice la care sunt adăugate diverse structuri auxiliare care asigură accesul operativ
la aceste date. Baza de date fizică este prezentă în memoria permanentă a calculatorului.
Modul de organizare al acesteia d epinde de configurația echipamentelor hardware care
suportă baza de date și sistemul de operare.
Modelul conceptual constă din descrierea structurii logice a datelor în baza de
date. Fiecare bază de date are un model conceptual propriu prin care sunt numit e toate
unitățile logice și legăturile dintre acestea. Acest model integrează viziunile utilizatorilor
asupra datelor și amin tește ce poate face parte din baza de date și ce anume nu poate fi
memorat de aceasta.
Modelul extern poate fi privit ca o descrie re a bazei de date, care corespunde
fiecărui utilizator în parte. Acest model cuprinde o parte a unităților logice din modelul
conceptual, la care se mai adaugă un număr de unități virtuale care nu au core spondent în
baza de date fizică.
Conceptul de veder e se definește la nivel extern, ca fiind o viziune individualizată
și simplificată asupra bazei de date, corespunzând unui anumit utilizator sau grup de
utilizatori.
În cadrul unei baze de date transformările care definesc interfața între două nivele
succesive se desfășoară prin trecerea de la un nivel la altul.
Un sistem de gestionare a bazelor de date (SGBD) este un software specializat în
stocarea și prelucrarea unui volum mare de date. Pentru re alizarea obiectivului, un SGBD
utilizează toate nivelele de abstractizare ale bazei de date și toate interfețele dintre acestea.
Cele mai importante avantaje sunt:
• dacă fiecare aplicație lucrează cu fișierele proprii este posibil ca aceeași date să apară
de mai multe ori în fișiere diferite ;
• duplicarea datelor în fișiere poate cauza probleme la actualizare ;
• partajarea datelor – mai multe aplicații utilizează același fișier ;
• introducerea standardelor oferă posibilitatea transferului de date de la o bază de date
la alta ;

41
• datele se consideră corecte dacă ele sunt consistente și valide prin proceduri specifice
aplicației.17

Pentru exploatarea bazelor de date este utilizat SQL (Structured Query Language),
adică limbajul de interogare structurat. SQL este cel mai utilizat limbaj standardizat
pentru accesul la baza de date, permițând stocarea, regăsirea și modificarea datelor din
baza de date.
Cel mai popular SGBD cu sursă deschisă este MySQL. MySQL este un sistem de
gestiune a bazelor de date relaționale foarte rapid. Serverul MySQL controlează accesul
la datele utili zatorului pentru posibilitatea utilizării acestora simultan de către mai mulți
utilizatori și pentru a oferi un acces rapid la ele, dar și pentru a garanta faptul că au acces
la ele doar utilizatorii autorizați. Astfel, MySQL se poate numi un server multiu ser (cu
mai mulți utilizatori) și multithread ( cu mai multe fire de execuție).
MySQL utilizează ca și alte SGBD -uri arhitectura client -server (Fig. 2 2). Această
arhitectură este utilizată și în alte sisteme de baze de date, cum ar fi: Oracle, Microsoft
SQL Server, etc.
Serverul MySQL ”așteaptă” posibilele cereri de conexiune ale clienților. Prin
client MySQL se înțelege orice aplicație capabilă să trimită interogări serverului MySQL.

17Mariana Nagy, Miha iela Vizental, Baze de Date, Material de studiu pentru învățământ la distanță, Editura
Universității Aurel Vlaicu, Arad, 2010

Fig. 22 – Arhitectura client -server

42
MySQL are multe puncte forte, printre care:
• performanță ridicată, adică MySQL este foarte rapid;
• cost scăzut, deoarece este disponibil gratuit sub o licență Open Source sau la un preț
mic sub o licență comercială dacă aceasta este necesară pentru aplicația dezvoltată ;
• ușurință în configurare și învățare, pentru că majoritatea bazelor de date moderne
utilizează SQL. Deasemnea, MySQL este mai ușor de configurat decât multe produse
asemănătoare;
• portabilitate, fiindcă MySQL poate fi folosit pe multe sisteme de operare;
• disponibilitatea codului sursă, deoarece codul sursă al bazei de date se poate modifica.

Există numeroase interfețe de acces la bazele de date MySQL din diverse limbaje
și medii de programare. Între acestea se pot aminti aplicația phpMyAdmin, care poate fi
utiliza t cu mare eficiență și ușurință , pentru gestionarea bazelor de date, a tabelelor și a
drepturilor de acces, dar și pentru execuția instrucțiunilor SQL. Programatorul își poate
crea propriile interfețe de acces la bazele de date MySQL.18
Cum am amintit și în subcapitolul precedent, am ales interfața pachetulu i software
XAMPP pentru a beneficia de serviciul MySQL.

18Luke Welling & Laura Thomson, Traducere de Ioan Bledea, Dezvoltarea aplicațiilor Web cu PHP și
MySQL, Ediția a I I-a, Editura Teora, București, 2005

43
4. Utilizarea aplicației
4.1 Interfața grafică

Interfața grafică (Graphical User Interface – GUI) ajută la crearea relației între
utilizator și o aplicație prin diferite ferestre, elemente grafice și text, butoane sau imagini.
Pentru prezentarea informațiilor și acțiunilor disponibile, un GUI oferă
pictograme și indicatori vizuali, în contrast cu interfețele bazate pe text, care oferă doar
nume de comenzi sau navigația text.
În continuare am să prezint interfața grafică utilizată în cadrul aplicației de chat
World Wide Messenger. Cele două module ale aplicației, având două ferestre principale
distinse , vor fi prezentate în capitole separate.

4.1.2 Modulul Server

Fereastra principală utili zată de modulul server, poartă denumirea WWM Admin .
Pe bara de titlu apare numele aplicației și al modulului: WWM este prescurtarea denumirii
aplicației ( World Wide Messenger ), iar Admin -ul indică faptul că această interfață este
pentru Administrator (Figu ra 23).

Fig. 23 – Fereastră principală modulului server

44
Această fereastră are un rol important în cadrul aplicației, deoarece cu ajutorul
acesteia se poate porni (sau la nevoie, a opri) modulul de server . În cazul în car e acest
modul nu funcționează, clientul nu se poate conecta la sistem.
După apăsarea butonului START pornește server -ul și aplicația client are
posibilitatea de a stabili o conexiune cu acesta . Textul de pe buton se schimbă pe STOP
și administratorul, prin reapăsarea butonului, poate opri serverul .

4.1.2 Modulul Client

Prima fereastră din modulul c lient este cea de autentificare ( Login to World
Wide Messenger ) prezentată în Fig. 2 4. Această fereastră apare în momentul pornirii
modulului client și se poate împărți în două : secțiunea de înregistrare și secțiunea de
autentific are.

În partea stângă a ferestrei, prin apăsarea butonul ui Sign Up , utilizatorul se poate
înregistra la sistem. Este foarte important de menționat faptul că un client se poate conecta
la sistem, doar daca în prealabil a trecut cu succes de proce dura de înregistrare. Această
procedură va fi prezentată în următoarea secțiune.
Partea dreaptă a ferestrei este folosită pentru introducerea datelor de autentificare
și pentru conectare prin apăsarea butonului Sign In .
Fig. 24 – Fereastra de autentificare

45
În cazul completării eronate sau a altor probleme ce pot apărea pe parcursul
autentificării, u tilizatorul se poate întâlni cu multiple mesaje de eroare. Aceste mesaje
sunt prezentate în Fig. 2 5.

Primul mesaj („You are not connected to the server. ”) apare în cazul în care
serverul nu funcționează și clientul nu se poate conecta la aceasta .
Mesajul („Empty username or password fi eld. Please fill in the blanks. ”) apare în
cazul în care numele de utilizator și/sau parola nu au fost introduse de loc .
Ultimul mesaj („Invalid username or password. ”) este răspunsul server -ului în
cazul î n care numele de utilizator și/sau parola introdusă sunt greșite.
Fig. 2 5 – Mesaje de eroare în cadrul aut entificării

46
În cazul în care nu intervine nici o problemă pe parcursul autentificării și
utilizatorul introduce date de autentificare existente și valide, va apărea mesajul (Fig. 2 6)
care informează cl ientul cum că a avut loc autentificarea cu succes ( „You have been
successfully logged in. ”).

În continuare am să prezint fereastra de înregistrare ( Registration ) care se
deschide din fereastra principală prin apăsarea butonului Sign Up . După cum se observă
și în cadrul Figurii 2 7, fereastra de înregistrare este împărțită în trei secțiuni, și anume,
partea de informații, partea principală de formular de înregistrare și cea de butoane.
Prima parte , afișează informații pentru utilizatorul care urmea ză să se înregistreze
la sistem. Mesajul („The information you supply will be used for registration purposes
Fig. 2 6 – Autentificare cu succes
Fig. 2 7 – Fereastra de înregistrare

47
only. It will not be given to a third party.” ) înseamnă ca datele clientului vor fi utilizate
doar în scopul înregistrării și nu vor fi transmise altora (Fig. 28).

A doua secțiune, oferă fun cționalitatea de bază a acestei ferestre , deoarece conține
formularul de înregistrare (Fig. 29). Utilizatorul, pentru efectuarea înregistrării, trebuie să
își aleagă un nume de utilizator și o parolă, după care să introducă datele personale cerute
(nume, prenume, număr de telefon , adresă electronică, țară și data nașterii ). Câmpurile de
confirmare nume de utilizator și parolă sunt folosite, ca și la majoritatea formularelor,
pentru a obliga utilizatorul să intro ducă numele de utilizator și parola de două ori,
eliminând posibilitatea greșelilor de scriere.

După introducerea datelor, sistemul va efectua validarea acestora: verifică dacă
s-au introdus informații în câmpurile obligatorii sau dacă numele de utilizator este deja
folosit de un alt client, compară conținutul câmpurilor nume de utilizator și confirmare
nume de utilizator (respectiv parolă și confirmare parolă) și validează formatul adresei de
e-mail.

Fig. 28 – Informații
Fig. 29 – Formularul de înregistrare

48
În continuare voi prezenta tipurile de mesaje în cazul în care validarea datelor
eșuează.
Mesajele d in cadrul F igurii 30 („Empty fie ld. … is required. ”) apar dacă
utilizatorul nu completează câmpurile obligatorii. În acest exemplu toate câmpurile
obligatorii sunt lăsate necompletate, dar dacă util izatorul ratează un singur câmp, sistemul
va indica doar acel câmp gol.

Fig. 30 – Mesaje de eroare – Câmpuri obligatorii pentru înregistrare

49
În imaginea următoare se p ot observa mesaj ele „Usernames do not match. ” și
„Passwords do not match. ”, care apar în cazul în care utilizatorul introduce valori diferite
pentru câmpurile: nume utilizator și verificare nume utilizator, respectiv parolă și
verificare parolă ( Fig. 31).

Fig. 31 – Mesaje de eroare – Câmpurile nu me de utilizator/parolă diferă

50
Ultima verificare ce se face în cadrul acestui formular este validarea adresei de e –
mail. În cazul în care aceasta nu are un format co respunzător, utilizatorul v -a primi
mesajul „Invalid e -mail address. ” reprezentat în Figura 32.

Dacă înregistrarea s -a desfășurat cu succes va apare următorul mesaj care
informează clientul despre acest lucru: „Your account has been created successfully a nd
is ready to use .” (Fig. 33).

Fig. 32 – Mesaje de eroare – Adresă e -mail invalidă
Fig. 33 – Înregistrare cu succes

51
A treia parte din cadrul ferestrei de înregistrare reprezintă secțiunea butoanelor
prezentate și în cadrul Figurei 34.

La apă sarea b utonul ui Save sistemul va efectua verificările necesare , iar în cazul
în care va găsi orice problemă , va afișa mesaj ele de eroare mai sus menționate . Dacă
procedura s-a desfășurat cu succes, datele vor fi trimis e la server, care le va salva în baza
de date.
Butonul Clear șterge din formularul de înregistrare toate datele completate de
client până în momentul respectiv .
Ultimul buton, Cancel închide fereastra de înregistrare , procedura de înregistrare
se întrerupe și clientul se poate întoarce la fereastra de autentificare.
Dacă procesul de autentificare s -a efectuat cu succes și uti lizatorul a primit
mesajul din Figura 26, va apare fereastra principală WWM (Fig. 35).

Fig. 34 – Butoane în fereastra de înregistrare
Fig. 35 – Fereastra principală WWM

52
Fereastra principală se poate împărți în trei secțiuni: partea de informații, lista de
contacte și secțiunea folosită pentru căutare.
Partea de inf ormații (Fig. 36) , în bara de titlu al ferestrei , afișează prescurtarea
WWM (World Wide Messenger) și numele de utilizator al clientului . Un pic mai jos, deja
în cadrul ferestrei, se afișează informația despre limba . În exemplul nostru, utilizatorul
folosește limba română ( „You Speak Romanian” ), astfel sistemul îi va traduce
întotdeauna mesajele primite în română.

Partea din mijloc conține lista de contacte (Contact List) și butonul Sign Out
(Fig. 37). Ace astă listă conține toți utilizatorii care sunt conectați la sistem în momentul
de față. Aplicația arată numele și prenumele acestora, informații care au fost furnizate de
către client în momentul înregistrării.

Prin apăsarea butonului Sign Out utilizatorul poate ieși din aplicația messenger și
sistemul va face posibil reîntoarcerea lui în orice moment. Dacă deconectarea s -a efectuat
cu succes apare mesajul „You have been successfully logged out. ” reprezentat în Figura
38.
Fig. 37 – Lista de contacte
Fig. 36 – Informații

53

Ultima parte a ferestrei principale este secțiunea de căutare ( Search ) (Fig. 39).
Această funcționalitate va fi implementat ă în următoarea versiune a aplicației . Această
parte va ajuta în găsirea unui utilizator anume din lista de contacte, folosindu -se de
numele lui de utilizator, de nume sau de prenume.

Ultima fereastră care va fi prezentată în acest capitol este fereastra de convorbire
(Fig. 40) în care se desfășoară comunicarea în sine între partenerii de discuții.
Fig. 40 – Fereastra de convorbire
Fig. 38 – Deconectare cu succes
Fig. 39 – Căutare

54
În bara de titlu a acestei ferestre, pe lângă d enumirea aplicației, apare numele
utilizatorului curent.
Asemănător ferestrelor prezentate în prealabil, și fereastra de convorbire se poate
împărți în trei componente: secțiunea de convorbire, cea cu informații și cea folosită
pentru trimiterea mesajelor .
În secțiunea de convorbire apare discuția în sine. Mesajele trimise și primite apar
în timp real. Fiecare rând începe cu numele utilizator ului care a trimis mesajul respectiv ,
iar după caracterul “:” apare mesajul tradus și în paranteze mesajul origina l.
În exemplul din Figura 41 clientul curent a primit mesajul “Hi! How are you?”,
care a fost tradus în limba selectată de el: “salut! ce mai faci?”

În partea dreaptă , apar informații despre convorbirea curentă (Fig. 42) .
Sub icoana aplicației Worl d Wide Messenger, apare numele utilizatorului cu care
clientul curent desfășoară o convorbire ( Your Friend ) și o secțiune care oferă informații
despre limbile folosite de către clienții care participă la această convorbire. În exemplul
de față (Fig. 42), u tilizatorul curent vorbește limba română, pe când, partenerul de discuții
a ales limba engleză înainte de a se autentifica .

Fig. 42 – Informații
Fig. 41 – Secțiunea de convorbire

55
Câmpul mai mic din partea de jos a ferestrei se folosește pentru trimiterea
mesajelor de către clientul curent la clientu l cu care acesta comunică. După introducerea
mesajului în acest câmp, dacă utilizatorul apasă butonul Send , mesajul lui va fi trimis
către partenerul de discuții (Fig. 43).

Dacă în timpul discuției partenerul se deconectează de la sistem , în secțiu nea de
convorbire, printre mesaje, apare un rând care indică acest lucru: „Your friend signed out
at 20:53 ”. Figura 44 prezintă un exemplu pentru acest caz, mesajul indică ora și minutul
la care celălalt utilizator a ieșit din program .

Fig. 43 – Secțiunea de trimitere mesaje
Fig. 44 – Deconectarea partenerului de comunicare

56
5. Concluzii

În acest capitol aș vrea să rezum și să apreciez tehnologiile folosite în proiectarea
programului și messengerul în sine.
Deoarece fiecare limbă are norme de ortografie propri i, crearea unei aplicații care
suportă toate limbile și în acel ași timp să se adapteze la aceste norme reprezintă o
problemă majoră. Multe cuvinte sunt polisemantice, se poate întâmpla că din cauza
contextului trebuie utilizată o altă structură a cuvintelor ca propoziția în sine să fie corectă.
Ca să nu mai vorbim despre fapt ul că în lumea noastră accelerată oamenii sunt obișnuiți
să prescurteze cuvintele, chiar și doar la 2 -3 litere, pentru a transmite cât mai scurt și
repede mesajele. Din această cauză pot apare erori în fiecare program de traducere. Aceste
greșeli sunt întotdeauna corectate periodic și în mod automat de către Translator API,
deoarece acesta se adaptează independent la regulile variabile.

Aplicația este disponibilă pentru orice utilizator care are conexiune la Internet și are
Java instalat pe calculator . Dacă aceste aspecte nu reprezintă o problemă, tehnologiile
folosite fiind portabile, aplicația se poate instala pe orice calculator.

Pentru atingerea obiectivelor propuse și prezentate în Introducere, am folosit
tehnologiile UML, Java, MySQL , XAMPP și MSTra nslator de la Microsoft . Motivele
pentru c are am ales aceste tehnologii sunt:
• Proiectarea programului este ușurată prin utilizarea diferitel or tipuri de diagrame
UML. Aceste diagrame ușurează implementarea aplicației, deo arece ajută la
înțelegerea relațiil or între clase și module sau a comportamentului aplicației.
• Java este cel mai răspândit l imbaj de programare orientată pe obiect , larg utilizată în
zilele noastre. Un program Java nu se execută direct de către microprocesor, ci
folosește o mașină virtuală (Java Virtual Machine – JVM), astfel acesta poate fi instalat
pe calculatoare cu diverse sisteme de operare.
• Volumul mare de date care stă la baza aplicației în cazul în care are mulți clienți
înregistrați la sistem , necesită un sistem de gestionare a baz elor de date. Acest aspect
a fost acoperit de serviciul MySQL cu ajutorul pachetului de software XAMPP.

57
• MSTranslator este o soluție dovedită, scalabilă și personalizabilă pentru o traducere
automată . Se poate integra în orice platformă, se poate folosi sub orice sistem de
operare pentru a efectua o traducere sau alte operațiuni legate de limbă, cum ar fi de
exemplu detectarea limbi i.
• Compatibilitatea perfectă între aceste componente.
• Fac parte din categoria aplicațiilor freeware.

În moment ul actual program ul W orld Wide Messenger este la versiunea 1.0.1 , ceea
ce înseamnă că acesta este prima ediție . Deoarece am folosit tehnologii care oferă
posibilitatea dezvoltatorului de a extinde aplicația în viitor , se dorește adăugarea unor noi
funcționalități atât în m odulul client, cât și în modulul server.
În lista funcționalităților pe care va trebui să le suporte serverul în următoarele
versiuni sunt:
• posibilitatea de adăugare de clienți noi ;
• modificarea datelor salvate în baza de date ;
• ștergerea clienților existen ți.
Modulul client oferă mult mai multe posibilități, astfel lista ideilor mele poate fi
extins oricând:
• posibilitatea de a schimba limba selectată în timpul sesiunii ;
• după traducere – la bifarea unei opțiuni – sistemul să și citească textul clientului
• posibilitate de adăugare/modificare/ștergere utilizatori într -o listă salvată pentru
fiecare utilizator în parte
• căutare în lista utilizatorilor
• poză customizabilă pentru fiecare utilizator .

Este important de menționat faptul că această listă se poate modifica, în funcție de
necesități și posibilități pe parcursul proiectării și implementării.
Consider că am oferit o soluție care ușurează și eficientizează munca în orice
activitate ce necesită o convorbire între două persoane care nu cunosc o li mbă comună.

58
6. Bibliografie

1. Dr. Kris Jamsa & Lars Klander, Traducere de Eugen Dumitrescu, Totul despre C și
C++ Manualul fundamental de programare în C și C++, Editura Teora, București,
2007
2. Ștefan Tanasă & Ștefan Andrei, Cristian Olaru, Java de la 0 la expert Ediția a II -a,
Editura Polirom, 2011
3. Luke Welling & Laura Thomson, Traducere de Ioan Bledea, Dezvoltarea
aplicațiilor Web cu PHP și MySQL, Ediția a II -a, Editura Teora, București, 2005
4. Mariana Nagy, Mihaiela Vizental, Baze de Date, Material de st udiu pentru
învățământ la distanță, Editura Universității Aurel Vlaicu, Arad, 2010
5. Vasile Topac, Ingineria Sistemelor de Programare, Note de curs, 2015
6. Vasile Topac, Programarea Sistemelor Automate Distribuite, Note de curs, 2015
7. Cristina Băla, Tehnologii Web, Note de curs, 2015
8. ***https://docs.oracle.com/javase/tutorial/
9. ***https://ro.wikipedia.org/wiki/Programare_orientat%C4%83_pe_obiecte
10. ***https://en.wikipedia.org/wiki/Unified_Modeling_Language
11. ***http://software.ucv.ro/~aion/ip/Laborator4/Diagrame%20de %20clase.pdf
12. ***https://en.wikipedia.org/wiki/Email_address
13. ***https://www.microsoft.com/translator/api.aspx
14. ***http://www.objectaid.com/
15. ***https://code.google.com/p/microsoft -translator -java-api/
16. ***https://eclipse.org/
17. ***https://www.apachefriends.org/r o/index.html
18. ***http://staruml.io/