Academia de Studii Economice din București [608439]

Academia de Studii Economice din București
Facultatea de Cibernetică, Statistică și Informatică Economică
Specializarea Informatică Economică

LUCRARE DE LICENȚĂ

Aplicaț ie pențru rezervarea bilețelor

Coordonator
Lect. Dr. Ilie -Nemedi Iulian
Absolvent: [anonimizat] 2017

Declarație privind originalitatea conținutului
și asumarea răspunderii

Prin prezenta declar că rezultatele prezentate în această lucrare sunt în
întregime rezultatul propriei mele creații cu excepția cazului în care se fac referiri la
rezultatele altor autori. Confirm faptul că orice material folosit din alte surse (reviste,
cărți, articole si site -uri de I nternet) este în mod clar referit în lucrare și este indicat
în lista de referințe bibliografice.

Cuprins

1. Introducere ………………………….. ………………………….. ………………………….. ……………………. 1
2. Proiectarea aplicației ………………………….. ………………………….. ………………………….. ……… 3
2.1 Prezentarea sistemului informatic ………………………….. ………………………….. …………. 3
2.2 Analiza sistemului informatic ………………………….. ………………………….. ………………. 8
2.3 Proiectarea sistemului informatic ………………………….. ………………………….. ……….. 13
3. Implementarea aplicației ………………………….. ………………………….. ………………………….. . 18
3.1 Tehnologii utilizate ………………………….. ………………………….. ………………………….. . 18
3.2 Prezentarea funcționalității aplicației ………………………….. ………………………….. …… 24
3.3 Prezentarea funcționalității serverului ………………………….. ………………………….. …. 36
4. Concluzii ………………………….. ………………………….. ………………………….. …………………….. 39
Bibliografie ………………………….. ………………………….. ………………………….. …………………….. 41
Anexe ………………………….. ………………………….. ………………………….. ………………………….. … 41

1
1. Introducere

Transportul de pasageri interurban rep rezintă o necesitate a populației de bază cât și o sursă
însemnată de venit pentru cei ce prestează serviciile de transport de pasageri. Infrastructura
României oferă posibilitatea de transport de persoane pe cale terestră, feroviară, maritimă și
aeriană. Conform Institutului Național de Statistică numărul pasagerilor, în anul 2016, a înregistrat
o creștere de 8% comparativ cu anul 2015. În anul 2016 ca și în anii precedenți, cea mai mare
ponder e (78,9%) o are transportul rutier, pe locul doi clasându -se transportul feroviar (1 6,8%) și
pe locul trei aflându -se transportul aerian cu 4,3%, transportul maritim reprezentând o valoare sub
0,05%. Cu certitudine putem spune că principalul mod de asigurare a mobilității persoanelor este
transportul rutier de persoane.
În urma unei anali ze a aplicațiilor deja existente pe piață în domeniul dat, am identificat în
mare parte aplicații web și puține aplicații mobile care nu sunt destinate pieței din România , cele
mai populare exemple sunt Eurolines și CDI , care oferă posibilitatea de a rezer va onlin e o cursă în
compania corespunză toare, verificând cursele in funcție de destinație, dată, durată și preț. Una din
problemele identificate de mine ca client, e necesitatea verificării diferitor companii de transport
pentru a face o comparație între preț, confort etc. Simțeam nevoia centralizării tuturor companiilor
pentru a avea o imagine clară și a efectua o comparație în timp util. Altă problemă identificată este
imposibilitatea de a -ți selecta locul în transport, după modelul curselor aeriene.
Aplicația dezvoltată în cadrul lucrării de licențe oferă facilitatea de rezervare a locurilor in
transport pentru o cursă interurbană, aplicația este destinată pentru două tipuri de utiliz atori, pentru
cei ce doresc efectuarea unei rezervări și pentru firme care prestează servicii de transport de
pasageri. Aplicația oferă facilități în funcție de tipul de utilizator, firmele ce dețin un cont de tip
administrator au posibilitatea de a adăuga o rută și a specifica detaliile aferente acestei rute și la fel
pot s ă î-și adauge tipurile de transport în parcul din aplicație , tipuri de transport disponibile:
autocar, microbuz și tren. Pentru utilizatorul de tip client, aplicația oferă facilitatea de căutare a
rutelor postate de firme și rezervarea locului dorit în tra nsport. Toate datele aferente aplicației sunt
stocate într-o bază de date, situată pe server. Aplicația avută în vedere are ca obiectiv facilitarea și
simplificarea procesului de rezervare a unui bilet de rută interurban cu ajutorul noilor tehnologii
informatice.

2
Lucrarea dată este structurată în patru capitole care descriu din diferite puncte de vedere
aplicația dată, introducerea în domeniul selectat, prezentarea analiza și proiectarea sistemului
informatic, detaliile privind implementarea aplicației și concluziile finale.
Primul capitol reprezintă introducerea, ce face o mică prezentarea a probl emei existente,
precum și eventuale soluții pentru problema identificată. La fel prezintă și o scurtă descriere a
aplicației.
Al doilea capitol descrie pașii de proiectare a sistemului informatic, precum prezentarea,
analiza și proiectarea sistemului. Acest capitol conține diferite tipuri de diagrame UML pentru a
avea o viziune mai simplificată asupra sistemului.
Al treilea capitol prezintă partea de implementare a aplicației și demonstrează funcționalităție
sistemului. La fel capitolul dat conține date despre tehnologiile folosite și detaliile privind
algoritmii folosiți cu scurte exemple de cod.
Ultimul capitol reprezintă concluzia finală în urma analizei acestui domeniu și
implementarea unei astfel de aplicații. Totodată conține și detalii privind dir ecțiile de dezvoltare
viitoare a alicației.

3
2. Proiectarea aplicației

2.1 Prezentarea sistemului informatic
2.1.1 Descrierea generală a sistemului informatic
Scopul aplicației date este realizarea aplicației mobile pentru gestiunea rezervărilor biletel or
unei rute de transport interurban. În vederea realizării unei rezervări, utilizatorul are nevoie de un
cont în sistem, după care are la alegere rutele disponibile pe ecran la care poate face o rezervare,
selectând ruta și apoi locul, după care va fi pri mi o notificare de confirmare. Confirmarea are loc
prin email sau prin telefon de către administratorul rutei, rezervare este validă doar pentru maxim
4 persoane de pe un cont, la fel utilizatorul poate anula rezervarea doar cu maxim 24 de ore înaintea
timpului de plecare a transportului. Pentru publicarea unei rute este nevoie de un cont de tip
administrator, oferit doar de proprietarul aplicației și de minim un transport disponibil în parc.
Aplicația avută în vedere are ca obiectiv facilitarea și simplif icarea procesului de rezervare a unui
bilet interurban cu ajutorul noilor tehnologii informatice.

2.1.2 Specificarea cerințelor
Aplicația dată urmărește scopul de a reduce timpul destinat procesului de rezervare a unui
bilet de transport interurban și oferă confortul clientului de a selecta desinestătător locul în
transport.
Capitolul dat are rolul de a specifica detaliile funcționale a cerințelor ce trebuie să le rezolve
aplicația software pentru soluționarea obiectivelor menționate mai sus, cât și prezent area
metodologiei de proiectare.
Prin intermediul diagramelor a cazurilor de utilizare sunt identificate și realizate c erințele
funcționale aferente aplicației în timpul dezvoltării. Diagramele date ne prezintă modul în care
sistemul informatic va fi utilizat prin prezentarea actorilor și a acțiunilor întreprinse de ei, numite
cazuri de utilizare.

4
❖ Diagrama cazurilor de utilizare aferente clientului

Figura 2.1. Diagrama cazurilor de utilizare pentru client
Cum vedem în diagrama de mai sus, clientului îi sunt oferite facilități precum vizualizarea
rutelor prin intermediul unei căutări în funcție de oraș, vizualizarea rezervărilor efectuate de el
precum și oportunitatea de anulare a rezervării efectuate respectând condițiile impuse de aplicație,
adăugarea rutelor preferate la favorite și accesarea lor în timp util, vizualizarea profilul ui și
posibilitatea de editarea a informaților person ale. În momentul în care client ul înaintează o cerere
de rezervare de loc la ruta dorită, i se afișează harta locurilor a transportului, scaunele indicate cu
roșu fiind deja rezervate și celelalte colora te gri sunt disponibile. Clientul poate rezerva de pe un
cont maxim 4 locuri la o rută. Toate facilitățile descrise mai sus sunt disponibile doar pentru clienții
ce s-au înregistrat în sistem și s -au autentificat.
Tabel 2.1. Descrierea elementelor cazurilo r de utilizare pentru utilizator
Element al cazului de
utilizare Descriere
Cod CU01
Stare Schiță
Scop Prezentarea activităților oferite clientului
Nume Cazurile de utilizare pentru client
Actor principal Clientul
Descriere Clientul are posibilitatea de căutare a rutei dorite și
vizualizarea detaliilor despr e rută. Clientul poate să -și ada uge

5
rute la secțiune favorite. Clientul are posibilitatea de rezervare
a unui loc anumit. Clientul poate să -și vizualizeze rezervările
efectuate cât și anularea lor r espectând anumite condiții. La fel
clientul poate să î -și vadă datele de profil precum și să le
modifice.
Precondiții Clientul să se înregistreze și să se autentifice.
Postcondiții Serverul să fie activ.
Declanșator Clientul
Flux de bază 1) Clientul introduce datele de logare.
2) Se verifică validitatea contului în baza de date.
3) Se deschide meniul principal cu opțiunile prezente in figura
2.1.
4) Clientul decide ce opțiune î-și alege.
5) Se execută cererea aferentă.
Fluxuri alternative 1) User -ul introduce date eronate de logare
2) Se înregistrează
3) Se loghează
Relații Extends: Anulează rezervarea, selectează loc, editează
informațiile , înregistrare.
Include: Autentificare
Frecvența utilizării Foarte des
Reguli de afaceri – Existența unui administrator ce să posteze rute
– Existența unui client ce dorește să efectueze o
rezervare.

6
❖ Diagrama cazurilor de utilizare aferente administratorului

Figura 2.2. Diagrama cazurilor de utilizare pentru administrator
După cum vedem în diagrama prezentă mai sus, administratorul are în mare parte alte cazuri
de utilizare față de client dar totodată sunt dependenți unu de altul. Administrator ul are
oportunitatea de a adăuga o rută în sistem cu condiția că are transport di sponibil, ulterior ca să
poată fi găsit în activitatea de căutare a clientului. Administratorul poate să își vizualizeze parcul
de transport și ulterior la necesitate să modifice datele transporturilor. Totodată administratorul
poate să î -și lărgească parc ul de transporturi adăugând în sistem alte transporturi deținute. La fel
ca și clientul are posibilitatea de a -și vizualiza profilul și la dorință să î -și modifice datele personale.
Toate facilitățile de mai sus sunt exclusiv destinate persoanelor sau firm elor cu drepturi aferente
transportului de persoane. Aceste tipuri de conturi (administrator) sunt obținute doar în urma
validării datelor de către administratorul sistemului.
Tabel 2.2. Descrierea elementelor cazurilor de utilizare pentru administrator
Element al cazului de
utilizare Descriere
Cod CU02
Stare Schiță

7
Scop Prezentarea activităților oferite administratorului
Nume Cazurile de utilizare pentru administrator
Actor principal Administratorul
Descriere Administratorul are facilități precum: adăugarea unui transport
care ulterior este asignat unei rute, adăugarea unei rute cu
condiția de disponibilitate de transport, vizualizarea rutelor și
transportului propriu ș i la necesitate modificarea lor,
vizualizare profilului și la dorință modificarea acestora.
Precondiții Administratorul să se înregistreze , să obțină validarea pentru
contul de administrator și să se autentifice.
Postcondiții Serverul să fie activ.
Declanșator Administratorul
Flux de bază 1) Administratorul introduce datele de logare.
2) Se verifică validitatea contului în baza de date.
3) Se deschide meniul principal cu opțiunile prezente in figura
2.2.
4) Administratorul î-și alege opțiunile necesare din meniu .
5) Se execută cererea.
Fluxuri alternative 1) Admin -ul încearcă să se logheze fără a primi validarea de
cont.
2) Va fi logat ca client.
Relații Extends: Editează ruta, editează transport, editează profil ,
înregistrare.
Include: Autentificare , adaugă transport.
Frecvența utilizării Des
Reguli de afaceri – Deținerea documentelor aferente transportului de
persoane
– Primirea vali dării de către administratorul sistemului.
– Deținerea a unui transport pentru persoane.

8
2.2 Analiza sistemului informatic
2.2.1 Diagrama de activitate
Diagrama de activitate este folosită pentru a descrie fluxul de lucru dintr -un punct de start
până la un punct de sfârșit, amănunțind drumurile de decizie car e apar într -o activitate.

Figura 2.3. Diagrama de activitate pentru rezervarea unui loc
Diagrama de mai sus prezintă fluxul de activitate în cazul rezervării unui loc. Clientul
selectează ruta interesată, după care trebuie să aleagă locul dorit în transport. Sistemul primește
datele de la utilizator, verifică dacă acest utilizator a mai efect uat o rezervare la această rută, dacă

9
da primește o notificare că nu mai poate efectua rezervări la această rută, dacă nu i se oferă
informații detaliate despre rută, după care clientul trebuie să î -și confirme rezervarea. În caz de
acceptare, rezervarea e ste adăugată în baza de date a aplicației și primește confirmare a rezervării,
la fel poate refuza rezervarea în acest moment.

2.2.2 Diagrama claselor
Diagrama claselor reprezintă sistemul din punct de vedere structural remarcând clasele
acestuia și relațiile dintre ele. Diagrama claselor e compusă din câteva elemente principale: clasă,
interfață și relație. Diagrama de clase este folosită în diferite et ape ale procesului de dezvoltare a
sistemului pentru definirea modelului conceptual și reprezentarea entităților de bază ale sistemului.

Figura 2.4 . Diagrama claselor
Cum vedem în figura de mai sus avem clasa Administrator și Client derivate din clasa User.
Administratorul are relația de agregare partajată cu clasa Ruta și Transport. Administratorul poate
avea mai multe instanțe de Ruta și Transport, multiplicitatea fiind 1..*, la rândul său o instanță de
Transport sau Ruta po ate fi asociată doar de un singur Administrator. Relația între Transport și
Ruta este de agregare compusă, deoarece o rută nu poate exista fără un transport asociat. O instanță
de rută poate avea un singur transport asociat, pe când un transport poate fi a sociat mai multor rute,
respectând condiția că nu va fi asociat la două rute ale căror dată și oră se suprapun. Clientul are
relația de asociere cu clasa Transport și Rezervare, un Client având posibilitatea să fie asociat mai
multor transporturi și mai mu ltor rezervări, la rândul său o Rezervare fiind asociată doar unui Client

10
iar Transport având multiplicitatea cu Client 1..*, totodată unei Rezervări se asociază doar un
Transport.

2.2.3 Diagramele de interacțiune
Diagramele de interacțiune conțin actorii, obiectele sau componentele ce formează o
interacțiune și redau mesajele interschimbate în timpul interacțiunii .
❖ Diagramele de secvență
Diagrama de secvență este o diagramă de interacțiune formată din obiectele, mesajele care
sunt transmise între actori și evidențiază ordinea mesajelor în dependență de timp.

Figura 2.5 . Diagrama de secvență pentru crearea unei rute

11
Pentru crearea unei rute administratorul are nevoie de cel puțin un transport. Crearea unui
transport presupune completarea unui formular aferent după care aceste date sunt trimise către
server de către sistem pentru validare, în caz că transportul nu este prezent în baza de date, este
adăugat, altfel este trimisă o e roare. În caz de succes administratorul primește un mesaj de succes
și transportul este adăugat în parcul său. Pentru crearea unei rute la fel se completează un formular
valid, după completare administratorul primește un review la ce a completat și confirm ă datele.
După care datele sunt transmise către server pentru adăugare în baza de date și administratorul este
avizat în caz de succes sau eroare.

Figura 2.6 . Diagrama de secvență pentru rezervarea unui loc
Pentru a -și rezerva un loc, clientul pentru înc eput trebuie să caute ruta dorită, în momentul
căutării, sistemul transmite datele de căutare către server pentru a primi cursele disponibile în baza

12
de date. Serverul răspunde cererii cu datele căutate de user și ulterior le are afișate pe ecran. Clientul
selectează ruta dorită, obține detalii aferente rutei, după care poate să înainteze o cerere de
rezervare. După asta clientului i se afișează harta locurilor unde sunt afișate locurile libere și
rezervate, ulterior clientul poate să aleagă locul dorit. Du pă confirmarea locului, de către client,
sistemul trimite datele către server și baza de date se actualizează, după care transmite un mesaj de
succes clientului. Clientul poate și să refuze confirmarea.

2.2.4 Diagrama de stare
Diagrama de stare are rolul de modelare a stării dinamice a unui obiect în parte.

Figura 2.7. Diagrama de stare pentru clasa Ruta
Conform diagramei de mai sus vedem ce stări poate avea clasa Ruta, după inițializare se
verifică dacă au fost introduse date valide dacă nu se întoarce la etapa precedentă, dacă da ruta este
validată și publicată după care i se adaugă un transport. În caz că se depistează ca ruta nu are
transport ruta se desființează automat.

13
2.2.5 Diagramele BPMN
Business Process Modeling Notation (BPMN) este o notație ce defineș te procesele de afaceri i
dintr -un workflow. BPMN este un limbaj înțeles atât utilizatorilor tehnici cât și de utilizatorii de
business.

Figura 2.8. Diagrama BPMN pentru obținerea contului de tip Administrator
Mai sus vedem o diagramă BPMN ce descrie proc esul de obținere a contului de tip
utilizator, astfel pentru a deveni administrator e nevoie de furnizarea documentelor ce confirmă
faptul că aveți dreptul să transportați persoane și dispuneți de transport.

2.3 Proiectarea sistemului informatic

2.3.1 Proiectarea bazei de date
La acest stadiu, în urma analizei cerințelor sistemului, se realizează modelarea cerințelor de
date utilizând un model de nivel înalt. Proiectarea conceptuală a bazei de date admite crearea unui
model al informațiilor care urmează să fie util izate de către sistem în așa fel ca modelul dat să nu
țină cont de resursele fizice.
O schemă a bazei de date este scheletul care reprezintă imaginea logică a întregii baze de
date. Aceasta definește modul în care sunt organizate datele și relațiile dintre ele. Schema
formulează toate constrângerile care trebuie aplicate datelor.
Deoarece modelul de date a aplicației este unul rațional, sistemul de gestiune a bazelor de
date utilizat în caz ul dat este MySql dezvoltat de Oracle, de asemenea, un SGBD relațion al. Schema
logică a bazei de date este prezentată mai jos și a fost generată utilizând un serviciu web.

14

Figura 2.9. Schema bazei de date. Sursa: www.genmymodel.com
Aplicația prezentă activează cu un număr de 4 tabele care au între ele mai multe relații. Pentru
funcționarea aplicației, baza de date are nevoie de următoarele tabele: users, transports,
reservations și routes.
Tabela users gestionează datele aferente pro filului unui utilizator. Cheia primară a tabelei
este id -ul. Aceasta și email -ul identifică în mod unic un utilizator. Toate câmpurile sunt obligatorii .
Tabela transports gestionează datele aferente unui transport. Cheia primară este id -ul.
Aceasta și reg Nr identifică un transport în mod unic. Toate câmpurile nu pot fi nule.
Tabela routes lucrează cu datele ce compun o rută. Cheia primară este id -ul. Tabela are și o
cheie externă care identifică un transport unic în funcție de numărul de înmatriculare. Che ia
primară identifică o rută în mod unic. Toate câmpurile sunt obliga torii.
Tabela reservations administrează datele aferente unei rezervări. Tabela are două chei externe
care identifică ruta și clientul care a efectuat rezervarea. Cheia primară este id -ul. La fel toate
câmpurile sunt obligatorii.

15
2.3.2 Diagrama de componente
Componentele sunt module compuse din diferite tipuri de cod. Diagrama de componente are
rolul de a descrie componentele principale implementate de sistem și dependențele acestora. Este
folosit preponderent de dezvoltatorii aplicațiilor.
Diagrama componentelor prezintă fișierele sistemului informatic în care vor folosi clasele
aplicației. Sistemul prezent are următoarele componente: program sursă (.java, .js), program
executabil (.apk).

Figura 2.10. Diagrama de componente. Sursa: www.creately.com

16
2.3.3 Diagrama de desfășurare
Diagrama de desfășurare descrie structura aplicației în momentul executării. Astfel aplicația
pentru rezervarea biletelor conține componentele ce interacționează pentru e xecutarea programului
implementat:
• Dispozitive mobile(Android)
• Serverul ce conține baza de date
• Rețeaua de internet

Figura 2.10. Diagrama de desfășurare a aplicației .

2.3.4 Securizarea aplicației
Sistemul de operare Android are o mulțime de caracteristici de securitate integrate, ca de
exemplu sandbox -ul aplicației , protecția împotriva buffer -ului și a atacurilor de supraîncărcare
asupra datelor de tipul Integer. Ca urmare aplicațiile Android simple care nu prelucrează nici un
fișier din sistem sau operații în rețea pot fi considerate aplicații securizate implicit.
Dacă dezvoltăm o aplicație mai complexă, este responsabilitatea dezvoltatorului să asigure
și să protejeze confidențialitatea utilizatorului. În urmare voi enumera măsurile impl ementate în
aplicație pentru securizarea ei.

17
• Validarea intrăr ilor. Toate datele introduse în aplicație conțin validatori și nu permit
introducerea informațiilor eronate, un prim pas pentru securizarea aplicației .
• Pagină de autentificare. Aplicația dispune de o pagină de autentificare, pentru a
permite unui utilizator să folosească aplicația . În caz că nu are cont, va fi nevoit să se
înregistreze în sistem.
• Stocarea datelor criptate pe dispozitivele externe. Aplicația în cauză dispune de
un algoritm de criptare a parolelor. Parolele sunt criptate pe dispozitiv, mai apoi
transmise și stocate pe server în format criptat. Modalitatea de criptare folosită este
una standard de a obține o cheie criptată simetrică definită în PKCS #5 (Public Key
Cryptograph y Standard) publicată de RCS. Standardul se bazează pe două idei
principale: folosirea unei chei salt pentru a proteja atacurile asupra dicționarului de
tabele asistate și folosirea unui număr mare de iterații pentru a face derivarea cheii
costisitoare din punct de vedere computațional (key-streching).
• Testarea aplicației continue. Aplicația dată a fost supusă testelor de fiecare dată ce
s-au adăugat caracteristici noi.
• Utilizare Intent -ului pentru transfer de date între aplicații . Activitatea
expeditoare a intent -ului poate verifica dacă activitatea destinatară are permisiune,
specificând o permisiune nenulă, odată cu apelul metodei. Numai activitățile cu
această permisiune au acces la acest Intent.
• Evitarea obținerii datelor person ale de la utilizatori. Securitatea datelor personale
în zilele de astăzi este foarte importantă. De fapt există legi, cum ar fi European
Union's Data Protection Directive , ce obligă securizarea dat elor personale a
utilizatorilor.
• Îmbunătățirea continuă a securității . Cât de securizată ne -ar părea o aplicație ,
totuși există câteodată puncte vulnerabile. Sporirea securității continue va seta noi
standarde de securitate și va îngreuna lucrul celor care încearcă să penetreze aplicația .
Pe viitor se presupune c riptarea tuturor datelor ce se stochează în baza de date.

18
3. Implementarea aplicației
3.1 Tehnologii utilizate
Tehnologia principală în jurul căreia a fost dezvoltată aplicația
este Android . Android -ul este un sistem de operare , bazat pe linux ,
destinat dispozitivelor mobile și dezvoltat de Google. Sistemul de
operare în mare parte este manipulat de gesturi pe un ecran tactil. Am
ales această tehnologie pentru că oferă facilități de dezvoltare, dat fiind
faptul, că este un proiect open -source. Android -ul oferă instrumente
pentru crearea de aplicații mobile care să arate foarte bine și să profite
la maxim de capacitățile hardware pe orice dispozitiv compatibil.
Interfața se adaptează automat, pentru a oferi o experiență maximă
utilizatorului și c ontrol, pe fiecare dispozitiv.
Android -ul este instalat pe sute de milioane de dispozitive global, în mai mult de 190 de țări.
Este cel mai instalat sistem de operare pe platformele mobile , inclusiv în România, și continuă să
crească de la o zi la alta. La fel Android oferă o piață deschisă pentru a distribui imediat aplicațiile
create de dezvoltator, serviciul numindu -se Google Play.
Pentru a dezvolta aplicații compatibile cu sistemul de operare Android, Googl e ne oferă un
mediu de dezvoltare integrat numit Android Studio . Acesta oferă dezvoltatorilor, toate
instrumentele necesare pentru a construi o aplicație compatibilă. Android Studio este un IDE bazat
pe IntelliJ IDEA și este distribuit gratuit. Aplicația e ste destinată echipelor de dezvoltare de o
persoană sau echipelor mari și multinaționale. Android studio oferă următoarele facilități:
• Un sistem flexibil de Build bazat pe Gradle.
• Un emulator rapid cu o mulțime de facilități
• Un mediu unificat unde puteți dezvolta aplicații
pentru toate tipurile de dispozitive.
• Posibilitatea de rulare a aplicației cu ultimele
modificări efectuate fără a crea un nou APK.
• Șabloane de coduri dis ponibile și integrare GitHub
pentru ajutorul construirii de caracteristici comune și pentru importarea exemplelor
de coduri existente.
• Instrumente pentru a detecta performanța, gradul de utilizare, compatibilitatea
versiunilor și alte probleme.
Figura 3.1.
Logotip Android.
Sursa: www.zellox.com
Figura 3 .2.
Logotip Android Studio .
Sursa: www. net-apk-android.blogspot.ro

19
Pentru a p ermite unui programator să dezvolte aplicații Android este nevoie de un kit de
dezvoltare software numit Android SDK . SDK -ul Android include exemple de proiecte cu cod
sursă, instrumente de dezvoltare, emulator și biblioteci necesare pentru a construi apli cații Android.
Aplicațiile sunt scrise în limbajul de programare Java și rulează pe Dalvik, o mașină virtuală
personalizată concepută pentru utilizare încorporată care rulează pe un kernel Linux.
Tehnologia Java este utilizată pentru a dezvolta aplicații pentru o gamă largă
de medii, de la dispozitive destinate consumatorilor la sisteme de întreprinderi
eterogene. Limbajul Java, ca orice alt limbaj de programare, are propria structură,
reguli de sintaxă și paradigmă de programare. Paradigma de programare a limbajului
este bazată pe principiile de POO, care este sprijinit de funcțiile limbajului. Limbajul
Java este un derivat al limbajului C, de aceea se pot observa reguli de sintaxă comune.
De exemplu, blocurile de cod sunt modularizate în metode și delimitate de acolade,
și variabilele sunt declarate la început, înainte de a fi utilizate. Din punct de vedere
structural Java e co mpus din pachete. Pachetul este mecanismul de namespace a
limbajului Java. În pachete sunt definite clase, iar in clase sunt definite metode,
variabile, constante etc.
Codul sursă, scris de programator, se află în fișiere cu extensia .java și apoi sunt co mpilate.
Compilatorul verifică codul pentru a detecta erorile de sintaxă ale limbajului, apoi scrie byte code –
ul în fișiere de tip .class. Bytecode -ul este un set de instrucțiuni pentru executare pe mașina virtuală
Java (engleză Java Virtual Machine, presc urtat JVM) . La runtime, mașina virtuală citește și
interpretează fișierele .class și execută instrucțiunile programului pe platforma hardware pentru
care a fost scris JVM -ul. Mașina virtuală Java interpretează byte code -ul la fel cum procesorul
interpretea ză instrucțiunile unui limbaj de asamblare, doar că diferența este că JVM este o parte de
software scrisă pentru o anumită platformă. JVM este disponibil pe platforme precum Windows,
Linux, iar subseturile limbajului Java au fost implementate în JVM -uri pe ntru dispozitive mobile
și microcip -uri.
Figura 3.3.
Logotip JAVA.
Sursa:
www.wikipedia
.com

20

Figura 3.3. Procesul de executare a unei aplicații Java.
Sursa: http://www.media -art-online.org/java/help/how -it-works.html

Odată ce o aplicație Java creează o instanță de obiect, JVM alocă automat spațiul de memorie
necesar, pentru obiectul dat, din Heap – memoria dinamică rezervată pentru program. Garbage
Collector rulează în fundal, urmărind obiectele pe care aplicația nu le mai refere nțiază și
recuperează memoria de la aceasta. Această abordare a gestiunii memoriei este numită gestiunea
implicită a memoriei, pentru că nu necesită scrierea unui cod pentru manipularea memoriei.
Pentru dezvoltarea interfețelor cu utilizatorul (engleză UI) , arhitectura Android oferă niște
scheme de amplasare numite în engleză layouts . Aceste layout -uri definesc structura vizuală pentru
UI, cum ar fi pentru activități , widget etc. Layout -urile se definesc în două moduri:
• Declararea elementelor UI în fișiere XML.
• Instanțierea elementelor layout -ului la runtime.
XML (din engleză Extensible Markup Language) reprezintă un set de reguli pentru
codificarea documentelor în forma înțeleasă de mașini . XML este un format popular pentru
partajarea datelor pe internet. Site-urile web care permanent î -și modifică conținutul , cum ar fi
bloguri și site-urile de știri, sunt bazate pe fișierele XML pentru ca programele externe să fie la
curent cu schimbările efectuate, în timp util.
Avantajul declarării elementelor UI în XML este că permite separarea mai bună a prezentării
aplicației de codul care controlează comportamentul acesteia. Descrierea UI -ului este în afara

21
codului de bază a aplicației , ceea ce înseamnă că putem face modificări, în aceste fișiere XML, și
vizualiza re zultatul fără recompilarea codului de bază. În plus, declararea layout -urilor în XML
facilitează vizualizarea structurii UI -ului, deci este mai ușor de depanat problemele intervenite.
Conectivitatea și transferul datelor, în rețea , între aplicație și serve r-ul ce conține baza de
date, este garantată de către protocolul HTTP (din engleză Hypertext Transfer Protocol). HTTP
este protocolul de bază utilizat de rețeaua globală de internet (din engleză World Wide Web,
WWW) și acesta definește modul în care mesajele sunt formatate și transmise și ce acțiuni ar trebui
să întreprindă serverele Web și browser -ele ca răspuns la diferite comenzi. HTTP este proiectat
pentru a permite elementelor intermediare din rețea să permită comunicarea sau îmbun ătățirea
acesteia între clienți și server.

Figura 3.4 . Arhitectura HTTP . Sursa: www.tutorialspoint.com

Datele necesare comunicării în rețea aplicației și serverul sunt încapsulate în JSON . Din
engleză JavaScript Object Notation (JSON) este un format ușor de schimb de date. Este ușor de
interpretat și de scris pentru oameni. Este ușor pentru mașini de calcul să le genereze și să le
parseze. JSON este compus din 2 structuri: o colecție de pe rechi cheie -valoare reprezentate ca un
obiect sau o listă ordonată de valori reprezentată ca un vector de obiecte.
Tehnologia de bază în realizarea server -ului cu baza de
date este Node.js . Node.js este o platformă construită pe
runtime -ul JavaScript de pe Chrome, pentru a dezvolta ușor
aplicații de rețea rapide și scalabile. Node.js este bazat pe
evenimente și utilizează un model de Input/Output (I/O) non –
blocabil care îl face să nu ocupe mult spațiu pe disc și eficient,
perfect pentru aplicațiile ce folosesc multe date de I/O în timp
real care rulează pe dispozitive distribuite. Node.js este un mediu open -source de rulare pe mai
multe platforme pentru dezvoltarea aplicațiilor de tip server sau rețea . Aplicațiile Node.js sunt
Figura 3.5 . Logo Node.js .
Sursa: www.wikipedia.org

22
scrise în limbajul JavaScript și pot fi executate în runtime -ul Node.js pe OS X, Microsoft Windows
și Linux. De asemenea, Node.js oferă o bibliotecă bogată ce conține diverse module JavaScript
care simplif ică mult dezvoltarea aplicațiilor Web folosind Node.js.
Caracteristicile principale ce determină dezvoltatorii să utilizeze această tehnologie sunt:
• Asincron și bazat pe evenimente. Toate API -urile din biblioteca Node.js sunt
asincrone, adică, non -blocabile. Asta înseamnă că un server bazat pe Node.js nu
așteaptă niciodată API -ul pentru a returna date.
• Foarte rapid. Fiind dezvoltat pe motorul JavaScript V8 al browser -ului Google
Chrome, biblioteca Node.js este foa rte rapidă ce ține de executarea codului.
• Un singur fir de execuție , dar foarte scalabil. Node.js utilizează un model cu un
singur fir de execuție cu o buclă de evenimente. Mecanismul de evenimente
determină serverul să răspundă într -o manieră non -blocabil ă și face serverul extrem
de scalabil, spre deosebire de serverele tradiționale care creează fire de execuție
limitate care să manipuleze cererile.
• Nu există memorie tampon. Aplicațiile Node.js niciodată nu salvează date în
memoria tampon, acestea doar tra nsmit datele la ieșire în bucăți .
JavaScript este un limbaj cross -platform de scripting orientat obiect. Este un limbaj mic și
nu ocupă mult spațiu pe disc. În interiorul unui mediu gazdă (browser), JavaScript poate fi conectat
la obiectele din acest mediu pentru a asigura un control programatic asupra lor.
Pentru simplificarea interacțiunii serverului cu baza de date am utilizat librăria Sequelize.
Când începem a construi aplicații Web simțim nevoia pentru ceva care va interacționa cu baza de
date pentru noi. Menținerea relațiilor dintre tabele, prelucrarea înregistrărilor conexe și gestionarea
tranzacțiilor devine foarte repetitivă în timp atunci câ nd utilizăm interogări scrise direct în SQL.
Sequelize abstractizează toate aceste sarcini pentru dezvoltator și oferă instrumentele necesare
pentru manipularea bazei de date. Sequelize este un ORM (din engleză, Object Relational
Mapping) proiectat să luc reze cu Node.js, este scris în JavaScript și suportă o mulțime de motoare
de baze de date majore cum ar fi MySQL, Postgres, SQLite, etc.

23

Figura 3.6 . Arhitectura ORM. Sursa: www.agile -code.com

Sistemul de gestiune a bazei de date (SGBD) ales pentru aplicație este MySQL . MySQL este
un SGBD relațional open -source, este bazat pe limbajul SQL, care este utilizat pentru adăugare a,
ștergere a și modificare a informațiilor din baza de date și este dezvolta t în limbajul C și C++.

24
3.2 Prezentarea funcționalității aplicației
Aplicația dată este destinată dispozitivelor mobile ce suportă sistemul
de operare Android cu o versiune minimă de Android 4.0.3 (sdk 15). Numele
aplicației este BookYourTrip, ce caracterizează funcționalitatea de bază a
aplicației. Aplicația poate fi utilizată doar cu server -ul pornit, altfel
utilizatorii nu v -or putea trece peste pagina de autentificare.
La pornirea aplicației i se va cere utilizatorului datele de autentificare,
în caz că nu are cont, are posibilitatea să se înregistreze. Pagina este
compusă din două EditText -uri pentru introducerea email -ului și a parolei
și două but oane pentru logare să respectiv înregistrare. Pentru a se înregistra este nevoie ca
utilizatorul să apese butonul Înregistrează -te. După care utilizatorul primește un formular de
înregistrare. Toate câmpurile fiind obligatorii.

La fel toate câmpurile din activitatea de înregistrare conțin validatori, respectiv numele nu
poate fi fără nici un caracter, validarea câmpului email este efectuată prin verificarea prezenței
caracterului @, câmpul parola are tipul de input de password și trebuie să conțină minim 6
caractere , astfel caracterele introduse sunt ascunse din motive de securitate, numărul de telefon la
Figura 3.7 .
Pictograma aplicației
Figura 3.8 . Pagina de
autentificare și înregistrare.

25
fel este verif icat și poate să conțină minim patru cifre. Parola este criptată în aplicație și trimisă
către server în format criptat. Codul sursă referitor la criptare este prezent în anexe. După o validare
a tuturor câmpurilor are loc trimiterea datelor către server printr -un JSON și ulterior introducerea
în bază de date pe server, după server -ul trimite un răspuns în format text dacă operațiunea a fost
efectuată cu succes sau nu. În orice caz după înregistrare utilizatorul este trimis către pagina de
login pentru autentificare cu login -ul deja setat. În caz de introducere de date eronate la înreg istrare,
sistemul detectează aceste erori și le marchează ca în figura 3.9.

Validarea email -ului are loc pe server, se verifică existența unui astfel de email în baza de
date, în caz ca nu există, are lo c înregistrarea, în caz că există, se trimite către aplicație un mesaj
de eroare. Mesajul de eroare este în engleză pentru că este trimis de către server.
După înregistrare cu succes utilizatorul introduce datele în pagina de autentificare , aplicația
primește parola de pe server după care o decriptează și verifică dacă parola decriptată corespunde
cu parola introdusă de utilizator. La fel aici are loc redirecționarea utilizatorului către tipul de
aplicație aferent acestuia, în caz că este client este t rimis către modul client, dacă dispune de cont
de tip administrator primește acces către modul administrator. Fiecare utilizator, în baza de date,
dispune de un câmp în car e este indicat tipul acestuia, 1 pentru client și 0 pentru administrator .
Figura 3.9. Erori de validare la înregistrare.

26
Aplicația detectează tipul utilizatorului în funcție de acest câmp. În continuare vom discuta despre
tipul de utilizator client, ca mai apoi să trecem la modul administrator.
Meniul principal al utilizatorului de tip client este compus
din opt secțiuni, un TextView în partea de sus a activității în care
este indicat numele utilizatorului și alte șapte ImageButton -uri.
Primul buton este destinat căutării rutelor dorite de către
utilizator și la fel în cadrul acestei activități poate să î -și rezerve
locul dorit , al do ilea arată rezervările efectuate ca o listă și
totodată locurile rezervate la fiecare rută , al treilea reprezintă
profilul, unde utilizatorul poate să î -și editeze datele personale și
parola. Butonul favorite reprezintă o listă creată de utilizator cu
orașele favorite care la un click pe oraș este redirecționat în
activitatea caută rută , butonul de setări reprezintă setările
aplicației. Despre este butonul ce conține datele de contact al
dezvoltatorului. Și ultimul buton este Ieșire pentru delogarea
utiliza torului din aplicație .
La această etapă în spatele interfeței grafice are loc
descărcarea datelor despre utilizatorul logat și salvarea acestora
în fișiere de preferință locale (SharedPreferences) pentru a folosi
ulterior datele utilizatorului logat fără a se conecta la server.
Meniul principal ca și restul activităților sunt setate, din
punct de vedere al design -ului, în așa fel ca să arate la fel pe
toate tipurile de rezoluții de ecrane. Asta a fost posibil prin
evitarea utilizării datelor fixe pentru dimensiunea
conținutului ș i utilizarea așa numitului layout_weight, pentru
a seta proporțiile pe care le ocupă un obiect anumit în
activitate. Putem observa în figura 3.11, unde este pornită
aplicația pe o tabletă Android cu o rezoluție 2048 x 1536
pixeli și putem observa așezarea componentelor proporțional
ca și în dispozitiv -ul din figura 3.10 cu rezoluția 720 x 1280
pixeli (smartphone). Imaginile folosite pentru reprezentarea
butoanelor în meniu sunt imagini oferite de Google ,
disponibile în apk -ul Android.
Figura 3.10. Meniul
principal al utilizatorului de tip
Client
Figura 3.11. Meniul
principal al utilizatorului de tip
Client pe tabletă

27
Activitatea de căutar e a unei rute se accesează tastând butonul Caută Rută. Activitatea în sine
reprezintă un motor de căutare. În partea de sus avem un câmp de căutare unde utilizatorul poate
introduce un oraș și motorul de căutare va afișa toate rutele ce pornesc și pleacă î n acest oraș.
Aplicația doar trimite datele de căutare serverului după care serverul se ocupă de interogarea bazei
de date și trimiterea rezultatelor aferente. După ce aplicația primește datele, imediat după, sunt
afișate într-un ListView cu un adaptor personalizat în activitate.

Pentru a vedea detaliile aferente unei rute dorite, ut ilizatorul poate tasta pe ruta dorită din
listă. După selectarea unei rute are loc afișarea detaliilor rutei aferente precum punctele
intermediare, transportul, ora sosirii și locurile totale. Detaliile sunt transmise, din activitatea de
căutare, printr -un Intent. Dacă utilizatorul se decide să facă o rezervare, trebuie să testeze butonul
din josul activității “Rezerv ă loc ”, în caz că nu, la fel poate să se întoarcă înapoi la activitatea de
căutare.
Figura 3.12. Rezultatul unei
căutări și detaliile aferente unei
rute

28
La tastarea butonului rezervă loc se pornește o activitate ce reprezintă harta locurilor din
transport. Este o activitate dinamică care se adaptează fiecărui caz în parte, sunt desenate un număr
de butoane egal cu num ărul total de locuri a transportului aferent rutei, algoritmul dat este prezent
în anexe. Algoritmul funcționează în felul următor, verifică tipul rutei, în caz că e microbuz sunt
desenate pe partea stângă două coloane de rănduri , pe mijloc un spațiu ce in dică numărul rândului
și pe dreapta o col oană. Dacă tipul este autocar atunci sunt desenate două coloane pe stânga și două
coloane pe dreapta, la fel cu un spațiu între ele. Pentru tipul de microbuz și autobus de fiecare dată
ultimul rând nu conține spațiu și în caz că rămân locuri sunt afișate în spatele acestui rând. Pentru
tipul tren sunt afișate două coloane pe stânga, două pe dreapta și cu un spațiu între, dar la sfârșit nu
are rândul plin, ci este cu spațiu . La fel la acest tip sunt delimitate vagoane le, în funcție de numărul
rândului. La fiecare al treizecilea rând apare un delimitator.

Activitatea totodată trimite o cerere spre server de a primi locurile rezervate rutei aferente, în
caz că sunt locuri rezervate, pictogramele locurilor sunt colorate în roșu și cele libere cu gri. Pentru
a selecta un loc este nevoie de doar tastarea unui loc disponibil, adică gri. La tastarea locului în
bara de sus este afișat locul sau locurile selectate și totodată pictograma este colorată în verde
pentru a evidenția locurile selectate.
Figura 3.13. Toate trei tipuri de seatmap -uri, a trans porturilor, disponibile în aplicație.

29

După ce am selectat locurile, pentru a finaliza rezervarea tastăm butonul “Finalizează
rezervarea ”. La tastarea acestui buton are loc trimiterea datelor, despre rezervare, către server.
Ulterior, utilizatorul este trimis către activitatea principală cu răspunsul de la server afișat . Acum
dacă încercăm să accesăm aceiași rută putem observa, ca în figura 3.14, că locurile rezervate mai
devreme au fos t colorate cu roșu.
La această etapă sunt câteva validări foarte importante, clientul nu mai poate efectua o
rezervare la o rută dacă a rezervat deja locuri la această rută, această validare se face prin verificarea
existenței mail-ului clientului logat , în baza de date la ruta aferentă. La fel clientul nu poate selecta
un loc deja rezervat, adică colorat în roșu. Altă validare foarte importantă este limitarea clientului
la efectuare rezervărilor, adică maxim 4 locuri per client. Aceste validări au fost con cepute pentru
a evita rezervarea unui singur client a tuturor locurilor în transport. Mesajele de eroare intervenite
în urma acestor tipuri de validări sunt afișate în figura 3.15 .
Figura 3.14. Procesul de rezervarea a locurilor la o rută

30

Pentru a vedea propriile rezervări, utilizatorul accesează butonul “Călătoriile mele ” din
meniul principal . Aici este afișat istoricul rezervărilor, și sunt prezente atât rezervările active cât
și cele deja expirate. Rezultatul este afișat în urma cereri înaintate către server cu email -ul
clientului , serverul caută în tabela Reservations toate rezervările în funcție de email -ul primit. În
final sunt transmise datele despre rută și locurile rezervate într -un array de tip JSON. Î n funcție
de răspuns ul primit, se afișează într-un ListView cu un adaptor personalizat rezervările efectuate
și locurile rezervate la ruta dată.

Figura 3.16. Activitatea Rezervările mele.
Figura 3.15. Mesajele de eroare condiționate de validările descrise în p agina precedentă.

31
O altă funcționalitate oferită din meniul principal al clientului, este posibilitatea de a -și
modifica datele personale, pentru aceasta se accesează buton -ul Profil din meniul principal.
Utilizatorul este redirecționat într-o activitate cu EditText -uri care au fost completate c u datele
curente de profil. Pentru a modifica una din date, este nevoie doar de a modifica sau schimba textul
din EditText și la apăsarea buton -ului Salvează, datele sunt salvate în baza de date, în caz că se
modifică și email -ul se modifică toate tabelele în baza de date pentru a nu pierde datele aferente
rezervărilor a clientului din cauza referirii la email -ul vechi. Astfel în caz că clientul dorește să î-și
modifice email -ul nu î -și va pierde datele asociate email -ului vechi.
Pentru a -și schimba parola, utilizatorului este propus buton -ul Schimba Parola. Pentru a
efectua această cerere cu succes, se afișează un dialog și utilizatorul va fi rugat să introducă și
parola veche, din motive de securitate, după care va introduce parola nouă. Parola se va schim ba
doar în cazul că parola veche este echivalentă cu parola asociată profilului din baza de date, primită
în format criptat de pe server și decriptată în aplicație și ulterior comparată cu cea introdusă de
utilizator. Apoi parola nouă este criptată și trimisă către server pentru a realiza modificarea în baza
de date.

Figura 3.17. Activitatea Profil și dialog -ul de schimbare a parolei

32
Butonul Favorite din meniul principal este pentru a salva orașele preferate a clientului pentru
a facilita căutarea de rute. Activitatea conține o listă în care pot fi adăugate orașele dorite de către
client. Pentru a salva din timpul dedicat căutării , utilizatorul poate doar da click pe orașul dorit din
această listă și automat este redirecționat în activitatea de căutare unde deja este introdus orașul de
căutare dorit. În orice moment utilizatorul are posibilitatea de a -și șterge orașul preferat apăsând
îndelungat pe orașul respectiv, pentru a preveni ștergerea din înt âmplare, se afișează un dialog în
care utilizatorul este întrebat dacă sigur dorește să șteargă acest element.

Datele aferente acestei activități sunt salvate local cu ajutorul fișierelor de preferințe conform
algoritmului de mai jos.

Figura 3.18. Activitatea Favorite și momentul în care se face un
click pe oraș.

33
Butonul de Setări din meniul principal al aplicației este destinat setărilor de sistem.
Momentan este disponibil doar un tip de setare, acesta este schimbarea limbi i. Aplicația dispune
de două limbi, română și engleză, se poate trece de la un a la alta foarte simplu din setări. În setări
avem afișate două iconițe cu drapelul țării respective. Pentru a selecta o limbă, e nevoie doar să
dăm click pe una din iconițe și aplicația î-și va schimba limba.
Alte două butoane disponibile în meniul principal mai puțin
funcționale . Butonul Despre care redirecționează clientul într -o
activitate cu datele de contact al dezvoltatorului aplicației . Butonul
de ieșire este destinat ieșirii din meniul principal și redirectarea
către pagina de autentificare.
Pentru a putea utiliza aplicația în modul administrator aveți
nevoie de un cont de tip administrator care poate fi setat doar prin server. Pentru a crea un utilizator
de tip administrator e nevoie ca mai întâi utilizatorul să se înregistreze, după care să înainteze o
cerere către dezvoltatorul aplicației pentru ai modifica în baza de date tipul de utilizator. După o
modificare cu succes, utilizatoru l se poate autentifica cu datele înregistrate mai devreme și va avea
acces la toate instrumentele destinate administratorului.
Meniul principal, ca și cel al client -ului, este compus din opt
secțiuni . Secțiunea de sus, la fel, este destinată salutării
utilizatorului. În schimb c elelalte secțiuni sunt un pic schimbate fată
de cele ale clientului. Primul buton, Rutele mele, afișează rutele
postate de acest cont și datele aferente. Butonul Adaugă Ruta
permite administratorului să adauge o rută în sistem. Butonul
Transporturile mele reprezintă parcul de transporturi al
administratorului dat. Celelalte butoane sunt echivalente sau au
scopuri echivalente ca cele de la client.
Pictogramele ce reprezintă butoanele din meniul principal, o
parte sunt oferite de Android, câteva au fost editate de mine
personal. Imaginea de la butonul Rutele mele este din pachetul
Android dar i -am modificat transparența pentru a se combina cu
celelalte butoane. La fel imaginea de la butonul Transporturile mele
este imaginea folosită de aplicație pentru a indica tipurile de
transport, inițial fiind neagră, am modificat -o în alb, la fel am
modificat transparență și i-am adă ugat un chenar pentru a se încadra în design -ul meniului. Figura 3.19 .
Activitatea setări.
Figura 3.20 .
Pagina p rincipală a
administratorului

34
În continuare vom vorbi doar despre 3 butoane: Rutele mele, Adaugă Ruta și Transporturile
mele, fiindcă celelalte butoane au funcționalități echivalente celor de la client.
Pentru început pentru a adăuga o rută, administratorul are nevoie de minim un transport, altfel
nu va putea crea ruta. Deci pentru început vom analiza activitatea Rutele mele. Această activitate
conține o listă cu transporturile adăugate și un buton de adă ugare.

Activitatea de adăugare a unui transport este compusă dintr -un formular ce trebuie completat
cu date reale. Numărul de înmatriculare este verificat dacă există deja în baza de date, în caz că
există un astfel de număr de înmatriculare, utilizatorul este no tificat printr -un mesaj de eroare. În
cazul că nu există un astfel de număr de înmatriculare, transportul este adăugat cu succes în baza
de date și după este afișat în lista, cu adaptor personalizat ce afișează modelul, numărul de
înmatriculare și tipul, d in activitatea Transporturile mele.
Figura 3.21 .
Activitatea Transporturile mele și activitatea de adăugare a unui transport

35
Tot în această activitate, administratorul are posibilitatea de a modifica un transport sau sa -l
șteargă . Pentru editare se face un simplu click pe transport, după care, se deschide activitatea de
adăugare de transport cu formularul completat cu datele
aferente transportului și în caz că sunt modificate datele, după
tastarea butonului salvează, sunt editate datele în baza de date.
Pentru ștergere , administratorul trebuie sa apese îndelungat
transportul dorit și primește un dialog de confirmare a ștergerii .
Editarea și ștergerea unui transport este efectuată doar dacă
transportul nu este asociat la o rută acti vă, adică o rută care încă
nu a început. La o încercare de ștergere sau modificare a unui
astfel de transport, administratorul primește un mesaj de eroare.
Acum că dispunem de transport, putem posta o rută. Pentru a posta o rută accesăm butonul
Adaugă Rută din meniul principal, după care se cere completarea datelor aferente rutei.

Toate câmpurile formularului sunt obligatorii și conțin validatoare. La transport ave m un
ComboBox care conține rutele proprii și libere pentru atașarea unei rute. Pentru a selecta data sunt
afișate dialoguri de tip calendar și oră, pentru a selecta mai ușor data și ora. Odată ce tastăm
salvează , ruta este împ achetată în JSON și transmisă către server ca mai apoi să fie adăugată în
Figura 3.22 . Dialogul de
confirmare a ștergerii unui transport
Figura 3.23 . Activitatea de adăugare a unei rute și dialogurile pentru selectarea datei

36
baza de date. Din acest moment, ruta este vizibilă în motorul de căutare și oricine poate rezerva loc
la această rută.
Ultima activitate exclusivă pentru administrator este activitate Rutele Mele, unde
administra torul î -și poate vizualiza rutele proprii, în plus poate vedea și nr de locuri ocupate.
Activitatea este simplă și prezintă informații foarte utile pentru administratorul rutei.

Figura 3.24 . Activitatea rutele mele

Activitatea este compusă doar dintr -un ListView cu un adaptor personalizat ce permite
vizualizarea rutei, locurilor ocupate, datei și a tipului. Celelalte butoane din meniul
administratorului au funcționalități echivalente ca la client.

3.3 Prezentarea funcționalității serverului

Serverul este dezvoltat cu ajutorul aplicației WebStorm produs de JetBrains și reprezintă o
aplicație Express scrisă în JavaScript. Express conține o multitudine de metode utilitare HTTP și
middleware pentru crearea unui API simplu și rapid. Serverul rulea ză doar local, deci au acces doar
cei care sunt în aceiași rețea locală, ca de exemplu în aceeași rețea de Wi -Fi. La fel pentru a
comunica cu succes aplicația mobilă cu serverul, trebuie scoase setările proxy sau adăugarea Ip-
ului serverului în excepții , în caz că există setări proxy. Serverul se rulează din linie de comandă și
odată pornit putem folosi aplicația . Serverul dat nu dispune de interfață , el doar oferă răspuns
cererilor HTTP de tip GET și POST prin mesaje de tip string sau JSON.

37

În figura 3.25 vedem adresa locală și portul serverului, dat fiind faptul că aplicația folosește
în mai multe locuri acest Ip pentru a se conecta la server, aplicația dispune de o variabilă car e
conține adresa serverului, astfel pentru a seta adresa e nevoie doar să modificăm variabila dată.

În figura 3.26 putem vedea toate datele referitoare la cererile adresate de către aplicație și
rezultatul acestora. Putem observa că serviciul web poate manipula cererile HTTP de tip GET și
POST.
Serverul în sine este compus din funcții care sunt apelate în funcție de tipul cererii și URL –
ul corespunzător. Un exemplu de funcție , de tip GET, care primește ca parametru un oraș și în caz
că sunt rute cu astfel de destinație sau punct de start, în baza de date, sunt transmise ca răspuns în tr-
un vector ce conține alți trei vectori cu obiecte JSON. Primul vector reprezintă datele din tabela
routes pentru ai afișa datele despre rută în motorul de căutare al clientului, al doilea vector conține
datele din tabela transports pentru ai afișa detalii de transport și ultimul date din tabela de users
pentru ai afișa numele administratorului. Codul sursă este disponibil în anexă.
Figura 3.25 . Consola aplicației WebStorm în urma rulării serverului
Figura 3.26. Consola serverului în urma cererilor din partea aplicației

38
Mai jos sunt prezente două funcții mai simple a serviciului web pentru a manipula cererile
HTTP de tip GET și POST.
app.post('/transport', function (req, res) {
var a = req.body;
Transport.findOne({where : { regNr: req.body.regNr}})
.then(function(transport){
if(transport != null){
res.send("Transport with this registry number is already
registered");
} else {
Transport.create(req.body);
res.send("Succesfully added! ");
}
})
})
app.get('/transport/registryNr/:nr', function (req, res){
Transport.findOne({where : { regNr: req.params.nr}})
.then(function(transport){
if(transport != null){
res.send(transport);
} else {
res.send("No such registry number!");
}
})
})
Prima funcție este una de tip POST ce introduce un transport în baza de date, înainte de asta
verifică existența unui transport cu același număr de înmatriculare, în caz ca există deja u nul, se
transmite ca răspuns un mesaj de eroare.
A doua funcție este una de tip GET și întoarce ca răspuns transportul găsit în baza de date în
funcție de numărul de înmatriculare.

39
4. Concluzii

Pe final, în urma elaborării acestei lucrări, am realizat cât de mult putem simplifica procesul
de rezervare a unui bilet și cât de comodă poate fi o astfel de aplicație. Având toate rutele și firmele
într-un loc putem realiza foarte simplu o comparație între acestea. Și pot spune cu certitudine că
aplicația va f i foarte de folos celor care utilizează un a stfel de serviciu destul de des. Conform
statisticilor realizate de INS, precum că în anul 2016 au fost transportați 384 de milioane de
pasageri, putem afirma că aplicația dată va avea un public potențial foarte mare. Aplicația dispune
de un meniu clar definit și foarte simplu de utilizat, pentru a fi dedicat tuturor categoriilor de vârstă
și la fel pentru străini, datorită posibilității de schimbare de limbă. Mai mult decât atât va încuraja
turismul în România , pentru străini , oferind acestora o aplicație cu toate rutele centralizate și cu o
ofertă de preț mai avantajoasă. Aplicația dată este destintă nu doar celor ce intenționează să
rezerveze un bilet, ci și firmelor din domeniu oferindule acestora instrumentele necesare. T otodată
aceasta oferă facilități de intrare pe piață a noilor concurenți și astfel duce la o reducere a prețurilor
biletelor pentru o călătorie, cât și oferirea de bonusuri și servicii mai plăcute. Acum toate firmele
au servicii proprii de rez ervare, cheltuind astfel bani pentru a întreține acest serviciu, datorită
distribuirii gratuite a aplicației date, firmele nu vor mai avea nevoie de investiții ulterioare.
Aplicația dată poate fi imbunătățită în viitor în diferite direcții. Prima derecție ar fi clientul,
un motor de căutare mai îmbunătățit, acum acesta poate căuta doar în funcție de orașul de plecare
și orașul destinație. Pe viitor se presupune realizarea unui motor de căutare ce va căuta și prin
punctele intermediare pentru a oferi client ului o rută mai efectivă. Alt aspect al motorului de căutare
ce trebuie realizat, este interconectarea rutelor automat de către aplicație, de exemplu nu există rută
București – Satu Mare, dar există rutele București – Cluj și Cluj – Satu Mare și astfel cli entul poate
ajunge la destinație prin intermediul mai multor rute. O altă imbunătățire necesară este iarăși
motorul de căutare. Se urmărește adăugarea filtrelor de căutare pentru a oferi clientului
instrumentele necesare pentru a găsi ruta dorită în cel ma i scurt timp. Am intenția de a elabora și
un sistem de chat în aplicație pentru ca clienții să poată comunica cu șoferii. O altă direcție de
îmbunătățire este oferirea administratorului următoarele facilități. Posibilitatea de editare a rutei cu
notificare a ulterioară a tuturor clienților ce au rezervat loc. Oferirea administratorului date statistice
lunare despre călătorii. La fel se urmărește introducerea unui si stem de profile a firmelor, unde
clienții vor putea lăsa note și comentarii, pentru a oferi ce lorlalți clienți o scurtă experiență cu
această firmă. În viitor se prevede a stoca toate datele în baza de date în format criptat pentru o
securitate mai avansată. Pentru a mări numărul de utilizatori în viitor se mai presupune portarea
acestei aplicații și pe alte sisteme de operare, precum iOS. Se mai urmărește și obiectivul de

40
centralizare a tuturor serviciilor de transport într -o aplicație, ca de exemplu aplicații precum
BlaBlaCar care urmărește ideea de împărtățire a unei rute cu mașina personală sau aplicații de
rezervarea biletelor pentru avion. Ar fi foarte util dacă toate tipurile de transport ar fi centralizate
într-o aplicație și s -ar putea alege o variantă de călătorie cât mai practică și pe placul clientului,
fără căutari îndelungate pe interne t. Aplicația dată poate fi adaptată și în multe alte țări unde
transportul în comun este foarte popular.
În ultimii ani piața dispozitivelor mobile a avansat foarte mult, atât global cât și în Romania.
Astfel conform datelor statistici fiecare al doilea ro mân are un smartphone (53%) adică circa 10
milioane, și numărul e în continuare creștere. Astfel se simte necesitatea de lansarea a unui serviciu
de rezervare de bilete, care până în prezent este oferit doar la un calculator sau la ghișeu, pe piața
disposi tivelor mobile. Oferind posibilitatea clientului de a rezerva un loc de oriunde, foarte comod
și în timp util.

41

Bibliografie

Anexe