Dezvoltarea unei aplicat ii software de [625857]

Ministerul Educat ¸iei Nat ¸ionale s ¸i Cercet ˘arii S ¸tiint ¸ifice
Universitatea ”OVIDIUS” Constant ¸a
Facultatea de Matematic ˘a s ¸i Informatic ˘a
Specializarea Informatic ˘a
Dezvoltarea unei aplicat ¸ii software de
informare a c ˘al˘atorilor din autobuzeleRATC
Lucrare de licent ¸ ˘a
Coordonator s ¸tiint ¸ific:
Conf. univ. dr. Puchianu Crengut ¸a
Absolvent: [anonimizat] ¸caru Petric ˘a
Constant ¸a
2017

Cuprins
Cuprins i
Lista Figurilor iii
1 Motivat ¸ie 2
1.1 Structura lucr ˘arii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Starea actual ˘a a domeniului 4
2.1 Definirea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Probleme ˆıntˆampinate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Solut ¸ia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Descrierea problemei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Obiectivele sistemului . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Participant ¸i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.6 Scenarii de baz ˘a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3 Analiza software a sistemului 7
3.1 Introducere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Documentul de cerint ¸e . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Modelul funct ¸ional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
i

Cuprins Cuprins
3.4 Diagrama de secvent ¸e de sistem . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1 Evenimente de sistem . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2 Diagrame de secvent ¸e de sistem . . . . . . . . . . . . . . . . . . . 15
3.4.3 Diagrama de context . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.4.4 Modelul domeniului . . . . . . . . . . . . . . . . . . . . . . . . . 19
4 Proiectarea s ¸i implementarea aplicat ¸iei 22
4.0.1 Arhitecturi s ¸i stiluri arhitecturale . . . . . . . . . . . . . . . . . . . 22
4.1 Modele de proiectare de atribuire a responsabilit ˘at ¸ilor . . . . . . . . . . . . 24
4.2 Diagrama de interact ¸iune . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Diagrame de clase ˆın faza de proiectare . . . . . . . . . . . . . . . . . . . 47
4.4 Modelarea bazei de date . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Concluzii 54
6 Anexe 55
6.1 Anexa 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.2 Anexa 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.3 Anexa 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Referint ¸e bibliografice 63
ii

Lista Figurilor
3.1 Diagrama cazurilor de utilizare software . . . . . . . . . . . . . . . . . . . . . 14
3.2 Diagrama de secvent ¸e de sistem pentru Achizit ¸ionare Bilet . . . . . . . . . . . 17
3.3 Diagrama de secvent ¸e de sistem pentru Autentificare S ¸ofer . . . . . . 17
3.4 Diagrama de secvent ¸e de sistem pentru Creare cont s ¸ofer . . . . . . . . . . . . 18
3.5 Diagrama de secvent ¸e de sistem pentru Vizualizare Autobuze . . . . . 18
3.6 Diagrama de context a sistemului FutureBus . . . . . . . . . . . . . . . . . 19
3.7 Diagrama de clase a sistemului FutureBus . . . . . . . . . . . . . . . . . . 21
4.1 Diagrama secvent ¸e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Diagrama de comunicare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3 Diagrama de secvent ¸e pentru cazul de utilizare Achizit ¸ionare bilet . . 27
4.4 Fereastr ˘a achizit ¸ionare bilet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Selectare linie si tip bilet pentru achizit ¸ionare de bilet . . . . . . . . . . . . . . 30
4.6 C ˘al˘atorul nu a selectat nici linia s ¸i nici coloana . . . . . . . . . . . . . . . . . 31
4.7 C ˘al˘atorul a primit un cod de c ˘al˘atorie . . . . . . . . . . . . . . . . . . . . . . . 31
4.8 Meniul aplicat ¸iei s ¸i biletele achizit ¸ionate . . . . . . . . . . . . . . . . . . . . . 34
4.9 Diagrama de secvent ¸e pentru cazul de utilizare Autentificare S ¸ofer . . 35
4.10 Autentificare S ¸ofer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.11 Autentificare S ¸ofer, credent ¸iale gres ¸ite . . . . . . . . . . . . . . . . . . . . . . 38
iii

Lista Figurilor Lista Figurilor
4.12 Fereastra de localizare autobuz . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.13 Diagrama in faz ˘a de proiectare pentru cazul de utilizare Vizualizare autobuze . 43
4.14 Meniul principal s ¸i fereastra de vizualizare a autobuzelor . . . . . . . . . . . . 44
4.15 Diagrama de clase de proiectare pentru cazul de utilizare Achizit ¸ionare bilet . . 48
4.16 Diagrama de clase de proiectare pentru cazul de utilizare Vizualizare-autobuze . 49
4.17 Diagrama de clase de proiectare pentru cazul de utilizare Autentificare S ¸ofer . . 50
4.18 Diagrama bazei de date de tip Mysql . . . . . . . . . . . . . . . . . . . . . . . 51
1

Capitolul 1
Motivat ¸ie
Aplicat ¸ia prezentat ˘aˆın cadrul acestei lucr ˘ari reprezint ˘a un factor important ˆın dezvoltarea so-
ciet˘at ¸ii, permit ¸ ˆand c ˘al˘atorilor s ˘a vizualizeze ˆın timp real locat ¸ia autobuzului s ¸i s ˘a-s ¸i achizit ¸ioneze
cu us ¸urint ¸ ˘a un bilet.
1.1 Structura lucr ˘arii
Lucrarea este compus ˘a din cinci capitole prezentate ˆın cele ce urmeaz ˘a.
Primul capitol prezint ˘a ideea de baz ˘a a lucr ˘arii s ¸i succint restul capitolelor cuprinse ˆın
lucrare.
ˆIn al doilea capitol se realizeaz ˘a descrierea principalelor probleme ˆıntr-o firm ˘a de trans-
port ˆın comun c ˆat s ¸i problemele pe care c ˘al˘atorii le ˆıntˆampin ˘aˆın fiecare zi atunci c ˆand uti-
lizeaza mijloace de transport ˆın comun. Totodat ˘a se ofer ˘a s ¸i solut ¸ii pentru rezolvarea tuturor
acestor probleme.
Capitolul trei cuprinde analiza software a sistemului ce trebuie implementat. Anali-
za software a sistemului este foarte utila deoarece in timpul efectuarii ei se ˆınt ¸elege modul
de funct ¸ionare a sistemului. Totodat ˘a,ˆın timpul analizei software se realizeaz ˘a s ¸i modelul
funct ¸ional, responsabil pentru descrierea comportamentului sistemului curent si a interactiu-
nilor lui cu actorii software.
Diagramele de clase sunt prezentate ˆın acest capitol s ¸i cu ajutorul lor se face o rapid ˘a
trecere la crearea codului aplicat ¸iei.
Toate diagramele mai sus ment ¸ionate au fost prezentate prin diagrame UML (acronim
pentru Unified Modeling Language[UMLS]), realizate cu ajutorul programului Astah [Astah].
ˆIn cel de-al patrulea capitol sunt prezentate modelele rezultate ˆın urma proiect ˘arii aplicat ¸iei
cu ajutorul diagramelor prezentate anterior ˆın capitolul 3. Tot aici sunt prezentate stilurile
arhitecturale care stau la baza form ˘arii arhitecturii obiectuale a oric ˘arui sistem software s ¸i
2

Motivat ¸ie Structura lucr ˘arii
modelele de proiectare si de atribuire a responsabilit ˘at ¸ilor. Pe l ˆang˘a prezentarea modelelor
de baz ˘a,ˆın capitolul 4 au fost prezentate modelele s ¸i stilurile utilizate pentru realizarea arhi-
tecturii aplicat ¸iei. Tot aici, pe baza diagramelor de secvent ¸e ˆın faza de proiectare, s-au realizat
descrieri ale codului surs ˘a s ¸i exemplific ˘ari ale utilit ˘at ¸ii acestuia.
ˆIn cadrul acestui capitol au fost exemplificate sistemele de gestiune a bazelor de date
utilizate c ˆat s ¸i modul proiect ˘arii bazelor de date aferente.
ˆIn ultimul capitol au fost discutate concluziile realiz ˘arii acestei lucr ˘ari cˆat s ¸i contribut ¸iile
proprii, bibliografia si anexele lucr ˘arii.
3

Capitolul 2
Starea actual ˘a a domeniului
2.1 Definirea problemei
O firm ˘a de transport ˆın comun are, ca scop principal, realizarea serviciului de transport per-
soane din oras ¸ele ˆın care aceste firme ˆıs ¸i desf ˘as ¸oar ˘a activitatea. Pentru realizarea transportu-
lui exist ˘a un orar aproximativ al mijloacelor de transport ˆın comun.
2.2 Probleme ˆıntˆampinate
Pe parcursul activit ˘at ¸ii mijloacelor de transport, exist ˘a posibilitatea aparit ¸iei urm ˘atoarelor
probleme:
1.Defect ¸iuni tehnice ale autobuzului sau microbuzului ceea ce duce la nerespectarea
programului s ¸i implicit pierderea c ˘al˘atorilor. V ˘azˆand faptul c ˘a autobuzul ˆıntˆarzie prea
mult, c ˘al˘atorul poate comanda un TAXI.
2.Pe liniile pe care circul ˘a mai multe autobuze, ˆın funct ¸ie de fluxul c ˘al˘atorilor, pot ap ˘area
ˆıntarzieri. C ˘al˘atorii nu s ¸tiu unde se afl ˘a autobuzul pe care-l as ¸teapt ˘a s ¸i dac ˘a sunt ˆın
ˆıntarziere ˆıl pot pierde.
3.Persoanele str ˘aine unor oras ¸e, nes ¸tiind locurile din care-s ¸i pot procura bilet, pierd timp
ˆın c˘autarea ghis ¸eelor. Dac ˘a nu g ˘asesc niciun ghis ¸eu de la care s ˘a-s ¸i cumpere bilet,
c˘al˘atoresc f ˘ar˘a bilet s ¸i risc ˘a s˘a fie amendat ¸i.
2.2.1 Solut ¸ia
Pe baza aplicat ¸iei prezentat ˘aˆın continuare ˆın aceast ˘a lucrare, se ˆıncearc ˘a evitarea tuturor
acestor probleme ˆıntˆampinate de c ˘atre c ˘al˘atori prin crearea unei ret ¸ele virtuale de autobuze.
4

Starea actual ˘a a domeniului Descrierea problemei
2.3 Descrierea problemei
Pentru a realiza un sistem software, trebuie ca acesta s ˘a treac ˘a prin mai multe faze de dez-
voltare. Analiza s ¸i proiectarea software trebuie s ˘a fie terminate ˆınainte de scrierea codului
propriu-zis.
Pentru a realiza o descriere grafic ˘a a modelelor comportamentului s ¸i structurii sistemu-
lui, se utilizeaz ˘a limbajul UML(Unified Modelling Language)[UMLS], limbaj de modelare
standard din 1997.
Pentru a modela cu ajutorul acestui limbaj, se combin ˘a conceptele UML ˆın cadrul mod-
elelor care poart ˘a numele de diagrame. Cu ajutorul limbajului UML se pot construi mai
multe tipuri de diagrame: de clase, de cazuri de utilizare, de st ˘ari, de secvent ¸e, de obiecte,
de activitate, de interact ¸iune etc.[UMLS].
Dezvoltarea aplicat ¸iei FutureBus a pornit de la urm ˘atoarea descriere a problemei:
O firm ˘a de transport ˆın comun dores ¸te achizit ¸ionarea acestei aplicat ¸ii pentru a eficientiza
buna funct ¸ionare a relat ¸iei produc ˘ator-consumator. ˆIn cazul de fat ¸ ˘a, produc ˘atorul serviciilor
este firma de transport, iar consumatorul este reprezentat de c ˘al˘ator. ˆIn prezent, acest lu-
cru este realizat la un nivel de baz ˘a, nepun ˆandu-se accent pe cerint ¸ele s ¸i nevoile c ˘al˘atorilor.
Exist ˘a un anumit num ˘ar de autobuze/microbuze care preiau c ˘al˘atorii din stat ¸ii special ame-
najate. Nu exist ˘a un timp mediu pe care-l face un autobuz parcurg ˆand distant ¸a dintre dou ˘a
stat ¸ii. De aceea, timpul ˆın care se ajunge ˆıntr-o anumit ˘a stat ¸ie este imprecis.
2.4 Obiectivele sistemului
Aplicat ¸iaFutureBus ˆındeplines ¸te urm ˘atoarele obiective:
1.Respectarea programului de vizit ˘a a fiec ˘arei stat ¸ii de c ˘atre autobuzul aferent.
2.Evitarea pierderii c ˘al˘atorilor s ¸i cres ¸terea num ˘arului acestora.
3.Prestarea unui serviciu de transport de calitate oferit at ˆat c˘al˘atorilor uzuali c ˆat s ¸i celor
str˘aini.
2.5 Participant ¸i
Persoanele direct interesate ˆın dezvoltarea unui sistem software s ¸i cei care interact ¸ioneaz ˘a
ˆın mod constant cu sistemul, au un rol important ˆın procesul de dezvoltare software. Ter-
menul stakeholder reprezint ˘a persoana care are un impact fie el negativ, fie el pozitiv asupra
5

Starea actual ˘a a domeniului Scenarii de baz ˘a
activit ˘at ¸ii s ¸i act ¸iunilor unei companii sau organizat ¸ii. Aces ¸ti stakeholder-i se ˆımpart ˆın pri-
mari(primii afectat ¸i) s ¸i secundari(cei implicati indirect), iar cei secundari au o influent ¸ ˘a im-
portant ˘aˆın dezvoltarea aplicat ¸iei. Pentru aceast ˘a aplicat ¸ie, persoanele cheie conform struc-
turii de mai sus ar fi directorii, s ¸efii de birou, s ¸oferii de autobuze,vanz ˘atorii de bilete s ¸i con-
trolorii, aces ¸tia fiind ˆıncadrat ¸i ˆın grupa primar ˘a.ˆIn grupa secundar ˘a sunt ˆıncadrat ¸i c ˘al˘atorii.
2.6 Scenarii de baz ˘a
Pentru a putea ˆınt ¸elege modul de funct ¸ionare al acestei aplicat ¸ii, se va explica pas cu pas cum
se realizeaz ˘a o c ˘al˘atorie ˆıntr-o zi obis ¸nuit ˘a a unui c ˘al˘ator care foloses ¸te autobuzele pentru a
se deplasa ˆın oras ¸. Pentru aceasta vom presupune faptul c ˘a domnul Popescu Marcel, un
nume atribuit simbolic unui utilizator al sistemului FutureBus , dores ¸te s ˘a se deplaseze in
Constant ¸a, de la C ˘amin Pesc ˘arie la Universitate. Domnul Popescu nu este preg ˘atit de plecare
s ¸i nu s ¸tie dac ˘a s˘a se gr ˘abeasc ˘a sau nu. Dar, utiliz ˆand un smartphone, el ruleaz ˘a aplicat ¸ia s ¸i
vede ˆın timp real o hart ˘a cu toate autobuzele disponibile. Poate selecta cu us ¸urint ¸ ˘a autobuzul
despre care dores ¸te informat ¸ii prin simpla ap ˘asare a imaginii cu autobuzul dorit. Aplicat ¸ia
verific ˘a imaginea pe care Domnul Popescu a accesat-o s ¸i ˆıl informeaz ˘a printr-un mesaj unde
se afl ˘a autobuzul s ¸i ˆın cˆat timp ajunge ˆın stat ¸ia Pesc ˘arie. Astfel c ˘a domnul Popescu s ¸tie dac ˘a
s˘a se gr ˘abeasc ˘a sau nu.
Un al doilea scenariu posibil pentru care poate fi folosit ˘a aceast ˘a aplicat ¸ie este descris
dup˘a cum urmeaz ˘a: vom presupune c ˘a domnul Popescu Marcel, un nume atribuit simbolic
unui vizitator al oras ¸ului Constant ¸a, dores ¸te s ˘a c˘al˘atoreasc ˘a cu autobuzul. Nes ¸tiind de unde
s˘a-s ¸i achizit ¸ioneze bilet, urc ˘aˆın unul din autobuzele RATC f ˘ar˘a bilet s ¸i risc ˘a s˘a fie amendat
de c˘atre controlori. Dar, rul ˆand aplicat ¸ia FutureBus , poate cump ˘ara cu us ¸urint ¸ ˘a un bilet,
select ˆand datele deja furnizate de c ˘atre aplicat ¸ie. Biletul achizit ¸ionat prin intermediul acestui
sistem software este salvat ˆın smartphone-ul dumnealui iar la un eventual control nu poate fi
suprataxat. Astfel c ˘a domnul Popescu reus ¸es ¸te s ˘a cumpere bilet ˆıntr-un mod foarte simplu s ¸i
nu pierde timpul c ˘autˆand un ghis ¸eu de unde s ˘a-s ¸i procure bilet.
Un alt scenariu posibil prin intermediul c ˘aruia poate fi explicat ˘a utilitatea acestei aplicat ¸ii,
ˆıl vom descrie mai jos: V om presupune c ˘a domnul Popescu Marcel, un nume atribuit sim-
bolic unui director RATC , dores ¸te vizualizarea h ˘art ¸ii cu autobuzele de pe traseu. Ruleaz ˘a
aplicat ¸iaFutureBus s ¸i astfel vede ˆın timp real locat ¸ia exact ˘a a autobuzelor, precum s ¸i
viteza cu care se circul ˘a pe traseu. Astfel c ˘a monitorizarea autobuzelor va fi facut ˘a eficient,
cu un efort minim.
6

Capitolul 3
Analiza software a sistemului
3.1 Introducere
Prin definit ¸ie, un sistem software este o colect ¸ie de componente care interact ¸ioneaz ˘aˆıntre
eleˆıntr-un mod bine-definit, ˆımpreun ˘a cu suportul persistent folosit s ¸i documentat ¸ia afer-
ent˘a[CBMFP].
Analiza software a sistemului reprezint ˘a o activitate ˆın care sunt realizate anumite modele
conceptuale, a c ˘aror rezultat evident ¸iaz ˘a o abstractizare a domeniului problemei rezolvat ˘a de
sistem[CBMFP].
Prin intermediul acestei analize se obt ¸in informat ¸ii esentiale privind structura codului,
riscurile s ¸i deficient ¸ele rezultate ˆın urma test ˘arii programului.
ˆIn cadrul realiz ˘arii unui sistem software, primul produs realizat este documentul de cerint ¸e.
Acesta este o descriere a funct ¸ionalit ˘at ¸ilor s ¸i propriet ˘at ¸ilor sistemului, as ¸a cum este v ˘azut de
c˘atre cei care sunt interesat ¸i ˆın funct ¸ionarea lui, precum s ¸i modul ˆın care poate fi folosit acest
sistem[CBMFP].
7

Analiza software a sistemului Documentul de cerint ¸e
3.2 Documentul de cerint ¸e
Documentul cerint ¸elor cont ¸ine 4 sect ¸iuni importante:
1.Descrierea sistemului cont ¸ine c ˆateva fraze care caracterizeaz ˘a sistemul s ¸i implicit obiec-
tivele acestuia.
2.Actorii software descriu unul sau mai multe roluri pe care le joac ˘a utilizatorii care
interact ¸ioneaz ˘a cu sistemul.
3.Cerint ¸ele funct ¸ionale specific ˘a tot ceea ce face sistemul.
4.Cerint ¸ele nefunct ¸ionale(atribute de calitate) reprezint ˘a propriet ˘at ¸ile sistemului sau prestat ¸iile
sistemului, as ¸a cum sunt v ˘azute de c ˘atre stakeholder-i[CBDAS].
Documentul de cerint ¸e al FutureBus este prezentat ˆın continuare:
1.Descrierea sistemului:
Sistemul realizeaz ˘a informarea c ˘al˘atorilor cu privire la locat ¸ia s ¸i timpul p ˆan˘a la destinat ¸ie
al autobuzelor din Constant ¸a.
2.Actorii software: S ¸ofer, c ˘al˘ator, administrator.
3.Cerint ¸e funct ¸ionale:
F 1 Creare cont s ¸ofer
F 1.1 Afis ¸eaz ˘a un formular ce permite introducerea datelor
F 1.2 Verific ˘a corectitudinea datelor
F 1.3 Creeaza un cont de utilizator s ¸i o parol ˘a pe care le memoreaz ˘a
F 1.4 Trimite prin email s ¸oferului datele create
F 1.5 Afis ¸eaz ˘a un mesaj
F2 Autentificare s ¸ofer
F 2.1 Permite introducerea datelor de autentificare de c ˘atre s ¸ofer, prin afis ¸area unui
formular
F 2.2 Verific ˘a corectitudinea datelor de autentificare ale s ¸oferului, din punct de vedere
sintactic
F 2.3 Afis ¸eaz ˘a un mesaj de Bun venit
F 2.4 Memoreaz ˘a datele de autentificare
F 2.5 Dac ˘a datele introduse de c ˘atre s ¸ofer nu sunt corecte, afis ¸eaz ˘a un mesaj de eroare
F3 Furnizare locat ¸ie autobuz
F 3.1 Permite selectarea unei opt ¸iuni
F 3.2 Memoreaz ˘a datele localiz ˘arii autobuzului
F 3.3 Afis ¸eaza un mesaj
8

Analiza software a sistemului Modelul funct ¸ional
F4 Vizualizare locat ¸ie autobuz
F 4.1 Afis ¸eaz ˘a autobuzele disponibile ˆın momentul curent
F 4.2 Permite selectarea unui autobuz, s ¸i vizualizarea detaliilor acestuia
F5 Achizit ¸ionare bilet
F5.1 Afis ¸eaz ˘a o list ˘a cu cu liniile disponibile s ¸i tipurile de bilete
F5.2 Permite selectarea unei linii s ¸i a unui tip de bilet
F5.3 Verific ˘a dac ˘a opt ¸iunile selectate sunt valide
F5.4 Dac ˘a utilizatorul are credit suficient, realizeaz ˘a achizit ¸ionarea unui bilet
F5.5 Memoreaz ˘a datele biletului achizit ¸ionat
F5.6 Dac ˘a opt ¸iunile selectate nu sunt valide, afis ¸eaz ˘a un mesaj de eroare
F5.7 Dac ˘a utilizatorul nu are credit suficient, afis ¸eaz ˘a un mesaj de eroare
F6 Vizualizare bilete achizit ¸ionate
F6.1 Afis ¸eaz ˘a lista biletelor achizit ¸ionate.
F6.2 Afis ¸eaz ˘a detalii despre biletele cump ˘arate.
4.Cerint ¸e nefunct ¸ionale(CN):
CN1 Aplicat ¸ia trebuie s ˘a foloseasc ˘a o baz ˘a de date pentru a memora datele.
CN2 Utilizare:
S ¸oferii nu trebuie s ˘a urmeze un curs pentru a folosi aplicat ¸ia, deoarece este bazat ˘a
pe interfet ¸e grafice.
Aplicat ¸ia trebuie s ˘a ruleze pe sisteme de operare Android cu versiune cel put ¸in
egal˘a cu 4.0.
CN3 Robustet ¸e:
Aplicat ¸ia trebuie s ˘a verifice datele introduse de c ˘atre˘sofer. Dac ˘a sunt incorecte,
aplicat ¸ia trebuie s ˘a afis ¸eze mesaje de eroare s ¸i s ˘a permit ˘a s ¸oferului reintroducerea
datelor corecte.
CN4 Portabilitate:
Aplicat ¸ia trebuie s ˘a fie implementat ˘aˆın limbajul de programare Java.
3.3 Modelul funct ¸ional
ˆIn cadrul fazei de analiz ˘a este creat modelul funct ¸ional, care cont ¸ine descrierea cazurilor de
utilizare software s ¸i diagrama cazurilor de utilizare.
Un caz de utilizare software descrie comportamentul potent ¸ial al unui clasificator (sistem/-
subsistem/clas ˘a),ˆın interact ¸iunea lui cu unul sau mai mult ¸i actori software.
Un caz de utilizare furnizeaz ˘a o secvent ¸ ˘a coerent ˘a de funct ¸ionalitate a unui clasificator prin
mesajele schimbate de clasificator, cu unul sau mai mult ¸i actori software.
9

Analiza software a sistemului Modelul funct ¸ional
Conform sursei [CBMFP], orice caz de utilizare poate fi descris textual, printr-un s ¸ablon:
1.Nume: este numele cazului de utilizare software
2.Descriere: descrie comportamentul sistemului s ¸i interact ¸iunea lui cu actorii software
implicat ¸i, pentru ˆındeplinirea unui obiectiv.
3.Actori software: sunt enumerat ¸i actorii software implicat ¸i. Poate exista un actor prin-
cipal care determin ˘aˆınceperea execut ¸iei acestui caz de utilizare.
4.Eveniment declans ¸ator: se specific ˘a act ¸iunea realizat ˘a de actorul principal.
5.Precondit ¸ii: descriu starea sistemului ˆınainte de ˆınceperea execut ¸iei cazului de uti-
lizare.
6.Postcondit ¸ii: descriu starea sistemului dup ˘a executarea acestui caz de utilizare.
7.Referint ¸e ˆıncrucis ¸ate: sunt enumerate cerint ¸ele funct ¸ionale ˆındeplinite de sistem, ˆın
acest caz de utilizare.
8.Flux principal: descriu interact ¸iunea dintre actori s ¸i sistem, prin act ¸iunile pe care le
face fiecare participant.
9.Flux alternativ: descrie act ¸iunea sistemului s ¸i a actorilor ˆın anumite situat ¸ii.
10.Flux de eroare: descrie act ¸iunea sistemului ˆın situat ¸ii except ¸ionale.
S-a realizat aceast ˘a descriere am ˘anunt ¸ita a cazurilor de utilizare ale sistemului FutureBus
ca urmare a s ¸ablonului prezentat anterior:
Caz de utilizare 1
Nume: Autentificare s ¸ofer
Descriere: Descrie comportamentul sistemului s ¸i interact ¸iunea acestuia cu s ¸oferul pen-
tru a putea realiza autentificarea ˆın sistem
Actori software: S ¸ofer
Eveniment declans ¸ator: S ¸oferul cere autentificarea ˆın sistem
Precondit ¸ii: Sistemul a verificat datele de autentificare ale s ¸oferului
Postcondit ¸ii: Sistemul a memorat locat ¸ia autobuzului s ¸i a afis ¸at un mesaj
Referint ¸e ˆıncrucis ¸ate: F2.1-F2.5,F3.1,F3.3
10

Analiza software a sistemului Modelul funct ¸ional
Flux principal
Sofer Sistem
1.Cere autentificarea ˆın sistem 2. Cere introducerea datelor de autentificare.
3. Introduce datele de autentificare s ¸i le trimite. 4.Verific ˘a corectitudinea datelor [A1] .
5.Memoreaz ˘a datele de autentificare.
6.Afis ¸eaz ˘a dou ˘a opt ¸iuni ˆıntr-o fereastr ˘a.
7.Alege opt ¸iunea Pornes ¸te localizare autobuz. 8.Memoreaz ˘a datele localiz ˘arii autobuzului.
9.Afis ¸eaz ˘a un mesaj.
Flux alternativ
[A1] Datele nu sunt corecte:
1.Sistemul afis ¸eaz ˘a un mesaj de eroare.
2.Fluxul continu ˘a cu pasul 2 din fluxul principal.
Caz de utilizare 2
Nume: Vizualizare autobuze
Descriere: Descrie comportamentul sistemului s ¸i interact ¸iunea acestuia cu c ˘al˘atorul
pentru a putea reda locat ¸ia curent ˘a a autobuzelor.
Actori software: C˘al˘ator
Eveniment declans ¸ator: C˘al˘atorul solicit ˘a vizualizarea autobuzelor ˆın momentul curent
Precondit ¸ii: Sistemul a verificat existent ¸a autobuzelor ˆın trafic
Postcondit ¸ii: Sistemul a afis ¸at autobuzele disponibile ˆın momentul curent
Referint ¸e ˆıncrucis ¸ate: F4.1-F4.2
Flux principal:
C˘al˘ator Sistem
1.Cere vizualizarea autobuzelor prezente ˆın trafic. 2.Verific ˘a autobuzele prezente ˆın trafic s ¸i le
afis ¸eaz ˘a pe hart ˘a.
3.Cere vizualizarea unui autobuz din cele furnizate. 4.Afis ¸eaz ˘a detalii despre autobuzul selectat.
11

Analiza software a sistemului Modelul funct ¸ional
Caz de utilizare 3
Nume: Achizit ¸ionare bilet
Descriere: Descrie comportamentul sistemului s ¸i interact ¸iunea acestuia cu c ˘al˘atorul
pentru a putea cump ˘ara un bilet pe o anumita rut ˘a de c ˘al˘atorie.
Actori software: C˘al˘ator
Eveniment declans ¸ator: C˘al˘atorul cere achizit ¸ionarea unui bilet.
Precondit ¸ii: Sistemul a verificat datele selectate de c ˘atre c ˘al˘ator.
Postcondit ¸ii: Sistemul a memorat datele s ¸i a furnizat un bilet de c ˘al˘atorie.
Referint ¸e ˆıncrucis ¸ate: F5.1-F5.7,F6.1-F6.2
Flux principal
C˘al˘ator Sistem
1.Cere achizit ¸ionarea unui bilet. 2.Afis ¸eaz ˘a o list ˘a cu liniile s ¸i tipurile de bilete
3.Selecteaz ˘a linia s ¸i tipul biletului dorit. 4.Verific ˘a validitatea optiunilor selectate de c ˘atre
c˘al˘ator.
5.ˆIn funct ¸ie de opt ¸iunile alese, verific ˘a dac ˘a are credit
suficient s ¸i achizit ¸ioneaz ˘a un bilet [A2] .
6.Memoreaz ˘a biletul cump ˘arat.
7.Afis ¸eaz ˘a detalii despre biletul curent.
8.Cere vizualizarea biletelor achizit ¸ionate. 9.Afis ¸eaz ˘a biletele cumparate.
Flux alternativ
[A1] Nu a selectat linia s ¸i tipul biletului:
1.Afis ¸eaz ˘a un mesaj de eroare.
2.Continu ˘a cu pasul 2 din fluxul principal.
[A2] Nu are credit suficient:
1.Afis ¸eaz ˘a un mesaj de informare.
2.Continu ˘a cu pasul 2 din fluxul principal.
12

Analiza software a sistemului Modelul funct ¸ional
Caz de utilizare 4
Nume: Creare cont s ¸ofer
Descriere: Descrie comportamentul sistemului s ¸i interact ¸iunea acestuia cu administra-
torul pentru a crea un cont pentru s ¸ofer.
Actori software: Administrator
Eveniment declans ¸ator: Administratorul cere crearea unui cont unui s ¸ofer
Precondit ¸ii: Sistemul a verificat datele introduse de c ˘atre administrator.
Postcondit ¸ii: Sistemul a memorat datele s ¸i a furnizat informat ¸iile despre noul cont
creat.
Referint ¸e ˆıncrucis ¸ate: F1.1-F1.5
Flux principal
Administrator Sistem
1.Cere crearea unui cont nou 2.Afis ¸eaz ˘a un formular
3.Completeaz ˘a formularul 4.Verific ˘a datele introduse [A1]
5.Creaz ˘a un cont de utilizator s ¸i parol ˘a
6.Memoreaza contul creat
7.Trimite datele noului cont c ˘atre s ¸ofer s ¸i afis ¸eaz ˘a un mesaj
Flux alternativ
[A1] A introdus un e-mail invalid sau contul deja exist ˘a.
1.Afis ¸eaz ˘a un mesaj de eroare.
2.Continu ˘a cu pasul 2 din fluxul principal.
Modelul funct ¸ional cont ¸ine, totodat ˘a, diagrama cazurilor de utilizare, cazurile de utilizare s ¸i
relat ¸iile dintre aceastea. Leg ˘aturile dintre ele sunt de mai multe feluri s ¸i sunt prezentate ˆın
13

Analiza software a sistemului Modelul funct ¸ional
tabelul urm ˘ator[UMLS]:
Denumire Semantic ˘a Sintaxa concret ˘a
UML
Relat ¸ia de asociere Descrie comunicarea dintre
actori s ¸i sistem
Relatia de dependent ¸ ˘a mar-
cat˘a cu stereotipul includeOri de cate ori va fi executat
cazul de utilizare A, va fi exe-
cutat s ¸i cazul de utilizare B
Relat ¸ia de dependent ¸ ˘a mar-
cat˘a cu stereotipul extendDac˘a se execut ˘a cazul A s ¸i
esteˆındeplinit ˘a o condit ¸ie, se
execut ˘a s ¸i cazul B
Relat ¸ia de generalizare Are loc ˆıntre actori sau ˆıntre
cazuri de utilizare
Diagrama cazurilor de utilizare software pentru aplicat ¸ia FutureBus este prezentat ˘aˆın
Figura 3.1.
Figura 3.1 : Diagrama cazurilor de utilizare software
14

Analiza software a sistemului Diagrama de secvent ¸e de sistem
3.4 Diagrama de secvent ¸e de sistem
3.4.1 Evenimente de sistem
Aparit ¸ia evenimentelor de sistem este determinat ˘a de c ˘atre act ¸iunile actorilor asupra sis-
temului software, furniz ˆand un r ˘aspuns vizibil actorului declans ¸ator. Avem trei tipuri de
evenimente:
1.flux de date(determinate de act ¸iuni ce cont ¸in transmiterea datelor sau a informat ¸iilor)
2.control(apar ca urmare a act ¸iunilor ce nu cont ¸in explicit date)
3.temporale(ap ˘arute datorit ˘a trecerii timpului)
Important este c ˘a act ¸iunile efectuate de actorii software produc evenimente de sistem [CBDAS].
ˆIn urma analizei cazului de utilizare Autentificare s ¸ofer a aplicat ¸iei FutureBus
s-au dedus urm ˘atoarele evenimente de sistem:
Evenimente flux de date Evenimente de control
Cere autentificarea ˆın sistem Trimite date din formularul de autentificare
Completeaz ˘a formularul Trimite opt ¸iunea selectat ˘a
3.4.2 Diagrame de secvent ¸e de sistem
Conform sursei [CBDAS], diagramele de secvent ¸e de sistem sunt o specializare a diagramelor
de secvent ¸e, deoarece arat ˘a interact ¸iunea dintre actori s ¸i sistem, prin intermediul mesajelor
trimise ˆıntre ei. Mesajul este comunicarea ˆıntre dou ˘a obiecte ˆıntr-un sens. Destinatarul ˆın
aceast ˘a comunicare poate fi chiar expeditorul (datorit ˘a modific ˘arii st ˘arii obiectului curent).
ˆIn tabelul urm ˘tor facem o trecere ˆın revist ˘a a conceptelor diagramei de secvent ¸e s ¸i a sintaxei
15

Analiza software a sistemului Diagrama de secvent ¸e de sistem
lorˆın limbajul UML.
Concept-Semantic ˘a Sintaxa UML
Linia de viat ¸ ˘a – indic ˘a existent ¸a unui obiect pe o pe-
rioad ˘a de timp
Mesajul<<create>> -ˆın aceast ˘a perioad ˘a este
creat un obiect
Mesajul<<destroy>> – descrie distrugerea unui
obiect
Activare – indic ˘a executarea unei operat ¸ii de c ˘atre
obiectul ˆınsus ¸i sau prin intermediul altor obiecte
Mesajul<<return>> – indic ˘a tipul de date al
informat ¸iilor returnate de destinatar
Diagramele de secvente de sistem realizate ˆın urma analizei aplicat ¸iei FutureBus le vom
prezenta ˆın cele ce urmeaza. ˆIn Figura 3.2 este prezentat ˘a diagrama de secvent ¸e de sistem
pentru cazul de utilizare Achizit ¸ionare Bilet .
16

Analiza software a sistemului Diagrama de secvent ¸e de sistem
Figura 3.2 : Diagrama de secvent ¸e de sistem pentru Achizit ¸ionare Bilet
Diagrama de secvent ¸e de sistem pentru cazul de utilizare Autentificare S ¸ofer
este prezentat ˘aˆın Figura 3.3.
Figura 3.3 : Diagrama de secvent ¸e de sistem pentru Autentificare S ¸ofer
Diagrama de secvente de sistem pentru cazul de utilizare Creare cont s ¸ofer este
prezentat ˘aˆın Figura 3.4.
17

Analiza software a sistemului Diagrama de secvent ¸e de sistem
Figura 3.4 : Diagrama de secvent ¸e de sistem pentru Creare cont s ¸ofer
Diagrama de secvent ¸e de sistem pentru cazul de utilizare Vizualizare Autobuze
este prezentat ˘aˆın Figura 3.5.
Figura 3.5 : Diagrama de secvent ¸e de sistem pentru Vizualizare Autobuze
18

Analiza software a sistemului Diagrama de secvent ¸e de sistem
3.4.3 Diagrama de context
Diagrama de context a sistemului software poate fi reprezentat ˘a prin actorii software ce
interact ¸ioneaz ˘a cu sistemul s ¸i operat ¸iile acestuia. Este realizat ˘a din perspectiv ˘a structural ˘a,
unde sistemul este reprezentat printr-o clas ˘a ale c ˘arei operat ¸ii sunt operat ¸ii de sistem. ˆIn
Figura 3.6 putem vedea diagrama de context a sistemului FutureBus .
Figura 3.6 : Diagrama de context a sistemului FutureBus
3.4.4 Modelul domeniului
ˆIn realizarea unui sistem software, un pas important ˆıl reprezint ˘a modelul domeniului care
are la baz ˘a diagrama de clase. Acest model cont ¸ine obiecte ale unei companii: c ˘al˘atori,
directori, controlori, s ¸oferi, informat ¸ii structurate, etc. Pentru a se realiza o diagram ˘a de
clase, se utilizeaz ˘a urm ˘atoarele concepte:
1.Clas˘a: descrierea unui grup de obiecte cu propriet ˘at ¸i similare, cu acelas ¸i comporta-
ment, cu aceleas ¸i relat ¸ii cu alte obiecte s ¸i cu o aceeas ¸i semantic ˘a;
2.Atribut: caracteristici ale obiectelor det ¸inute de clase;
3.Operatie: funct ¸ie sau transformare aplicat ˘a unui obiect;
19

Analiza software a sistemului Diagrama de secvent ¸e de sistem
Clasele sunt legate prin relat ¸ii, fiecare tip av ˆand semantica ei, pe care o explic ˘amˆın
urm˘atorul tabel [TUMLR1999]:
Denumire Semantic ˘a Sintaxa concret ˘a
UML
Relat ¸ia de asociere Mult ¸imea de leg ˘aturi ˆıntre
obiectele claselor implicate
Relat ¸ia de agregare Reprezint ˘a formarea unui lu-
cru din p ˘art ¸ile sale
Relat ¸ia de compozit ¸ie Este o relat ¸ie de agregare mai
puternic ˘a, deoarece un obiect
agregat are responsabiltatea
cre˘arii s ¸i distrugerii p ˘art ¸ilor
sale
Relat ¸ia de generalizare/spe-
cializareFace leg ˘atura ˆıntre dou ˘a clase
ˆın care una este supraclas ˘a s ¸i
cealalt ˘a este subclas ˘a
Relat ¸ia de dependent ¸ ˘a Relat ¸ie prin care dac ˘a se
modific ˘a o clas ˘a duce la
afectarea altei clase cu care
este legat ˘a
Pentru a realiza diagrama de clase, se identific ˘a substantivele din descrierea problemei,
sunt analizate s ¸i transformate ˆın clase sau atribute. Prin analiza descrierii problemei, a fost
realizat ˘a diagrama de clase pentru sistemul FutureBus. Aceasta diagram ˘a este prezentat ˘a
in Figura 3.7.
20

Analiza software a sistemului Diagrama de secvent ¸e de sistem
Figura 3.7 : Diagrama de clase a sistemului FutureBus
21

Capitolul 4
Proiectarea s ¸i implementarea
aplicat ¸iei
Proiectarea reprezint ˘a o activitate de baz ˘a, esent ¸ial ˘aˆın construirea unei solut ¸ii conceptuale
rezultat ˘aˆın urma cerint ¸elor identificate s ¸i descrise ˆın faza de analiz ˘a prezentat ˘aˆın capitolul
anterior. ˆIn faza de proiectare este realizeaz ˘a arhitectura software a sistemului dezvoltat.
4.0.1 Arhitecturi s ¸i stiluri arhitecturale
Arhitectura software reprezint ˘a un model de organizare a sistemelor software. Acest model
cont ¸ine subsisteme, clase sau servicii web, relat ¸iile dintre ele s ¸i mediul ˆın care se afl ˘a, s ¸i
principiile care realizeaz ˘a proiectarea s ¸i evolutia arhitecturii. Arhitectura software ajut ˘a la
ˆıntelegerea, construct ¸ia, managementul s ¸i evolut ¸ia unui sistem software [CBDAS].
ˆIn realizarea unui sistem software, se utilizeaz ˘a unul sau mai multe stiluri arhitecturale.
Un stil aritectural are la baz ˘a un vocabular de proiectare, o descriere a semanticii lui s ¸i
constr ˆangeri asupra modului ˆın care este folosit.
22

Proiectarea s ¸i implementarea aplicat ¸iei Proiectarea s ¸i implementarea aplicat ¸iei
Se cunosc mai multe stiluri arhitecturale, prezentate succint ˆın cele ce urmeaza:
1.Stilul arhitectural conducte s ¸i filtre
Fluxul de date este citit de c ˘atre filtre iar transmiterea datelor se face cu ajutorul con-
ductelor. Acest stil poate fi reutilizat, suport ˘a atˆat concurent ¸ ˘a cˆat s ¸i anumite tipuri de
analiz ˘a. Cu toate acestea, se poate ajunge la o organizare dificil ˘a a calculului s ¸i nu se
recomand ˘a pentru aplicat ¸iile bazate pe evenimente.
2.Stilul arhitectural client-server
Pentru a fi utilizat acest stil, sistemul trebuie s ˘a fie format dintr-un num ˘ar de procese
client s ¸i un num ˘ar de procese server ce interact ¸ioneaz ˘a realiz ˆand o activitate. Orga-
nizarea aceasta este benefic ˘a deoarece faciliteaz ˘a independent ¸a client ¸ilor, oferind un
puternic control asupra resurselor serverului. Cu toate acestea, nu este la fel de puter-
nic ca s ¸i ret ¸eaua peer to peer.
3.Stilul arhitectural bazat pe evenimente
Evenimentele rezult ˘a din comunicarea componentelor. O component ˘a anunt ¸ ˘a o alta de
aparitia unui eveniment, dac ˘a acesta s-a inregistrat. Avantajul utiliz ˘arii acestui stil este
c˘a poate fi reutilizat. Totus ¸i apar probleme la corectitudinea funct ¸ionalit ˘at ¸ii sistemului
sauˆın timpul schimbului de date.
4.Stilul arhitectural pe straturi
ˆIn cadrul acestui stil, organizarea se face pe nivele, fiecare nivel furnizeaz ˘a servicii
stratului superior s ¸i ˆıi este client celui inferior. ˆIn cadrul acestui stil, baza o reprezint ˘a
izolarea logicii fat ¸ ˘a de considerentele interfet ¸ei cu utilizatorul. Astfel rezult ˘a o aplicat ¸ie
a c˘arei aspect vizual se modific ˘a usor, neafect ˆandu-se alte nivele. Un avantaj al uti-
liz˘arii acestui stil, este faptul c ˘a suport ˘a reutilizarea ˆıns˘a nu toate sistemele pot fi struc-
turate us ¸or pe straturi.
5.Stilul Model-View-Controller
ˆIn cadrula cestui stil, baza o reprezint ˘a izolarea logicii fat ¸ ˘a de considerentele interfet ¸ei
cu utilizatorul. Astfel rezult ˘a o aplicat ¸ie a c ˘arei aspect vizual se modic ˘a us ¸or, nea-
fectˆandu-se alte nivele[CBDAS].
MVC descompune obiectele aplicai ¸ei ˆın 3 categorii:
(a)Model – cu rol ˆın ment ¸inerea st ˘arii curente a aplicat ¸iei
(b)View – are rol ˆın verificarea componentelor interesate ˆın mod direct de starea
actual ˘a a aplicat ¸iei
(c)Controller – are rol procesarea s ¸i r ˘aspunderea la evenimente
ˆIn funct ¸ie de arhitectura sistemului, aceste stiluri pot fi combinate. ˆIn proiectarea
arhitecturii sistemului FutureBus , ca s ¸i stiluri arhitecturale am utilizat stilul client-
server combinat cu stilul MVC(Model-View-Controller)[CBDAS].
23

Proiectarea s ¸i implementarea aplicat ¸iei Modele de proiectare de atribuire a responsabilit ˘at ¸ilor
4.1 Modele de proiectare de atribuire a respons-
abilit ˘at ¸ilor
Cu ajutorul acestor modele se descriu principii fundamentale ale proiect ˘arii orientate spre
obiecte s ¸i atribuirii responsabilit ˘at ¸ilor claselor.O responsabilitate reprezint ˘a obligat ¸ia pe care
o anumit ˘a clas ˘a trebuie s ˘a oˆındeplineasc ˘a.
Exist ˘a probleme pentru a c ˘aror rezolvare este g ˘asit˘a cu ajutorul anumitor modele de
proiectare [CBDAS].
ˆIn continuare vom enumera modelele de proiectare utilizate ˆın realizarea arhitecturii
sistemului FutureBus s ¸i problemele generale pe care acestea le rezolv ˘a.ˆIn sect ¸iunea
4.1.2 urmeaz ˘a s˘a explic ˘am modul ˆın care am folosit aceste modele la proiectarea sistemului
FutureBus .
1.Expert(Information Expert)
Pentru a s ¸ti c ˘arei clase i se atribuie o anumit ˘a responsabilitate, utiliz ˘am acest model.
Asadar, o anumit ˘a responsabilitate este atribuit ˘a acelei clase ce det ¸ine toate informat ¸iile
necesare ˆındeplinirii ei.
2.Creator
Acest model se foloses ¸te pentru a atribui unei clase B responsabilitatea cre ˘arii unui
obiect al altei clase A. Pentru a putea da aceast ˘a responsabilitate trebuie ca o clasa B sa
verifice dac ˘a agreg ˘a obiectele lui A sau contine obiecte ale lui A sau foloses ¸te obiecte
ale lui A sau are date de init ¸ializare ce vor fi transmise lui A atunci c ˆand obiectul este
creat.
3.Cuplare slab ˘a(Low Coupling)
ˆIn cele mai multe cazuri, cuplarea se utilizeaz ˘a pentru a vedea leg ˘atura dintre elemente
sau c ˆate cunos ¸tinte are un element despre alte elemente. Pentru a realiza cuplarea ˆıntre
dou˘a clase A s ¸i B, una din urm ˘atoarele afirmat ¸ii trebuie s ˘a fie adevarata:
(a)A are un atribut de tip B;
(b)un obiect al clasei A apeleaz ˘a servicii ale unui obiect din clasa B;
(c)A are o operat ¸ie ce refer ˘a un obiect al clasei B;
(d)A este o subclas ˘a direct ˘a sau indirect ˘a a lui B;
(e)B este o interfat ¸ ˘a s ¸i A este o clas ˘a ce realizeazt ˘a interfat ¸a lui B;
4.Coeziune ˆınalt˘a(High Coesion)
ˆIn programarea orientat ˘a spre obiecte, pentru a putea vedea c ˆat de corelate sunt re-
sponsabilit ˘at ¸ile unei clase, se utilizeaz ˘a coeziunea. Astfel c ˘a o clas ˘a cu coeziune ˆınalt˘a
are responsabilit ˘at ¸ile str ˆans legate ˆıntre ele nepun ˆand accentul pe prea multe obiective.
24

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
5.Controller
Atunci c ˆandˆın sistem se primesc evenimente externe, se adaug ˘a cˆate o clas ˘a numit ˘a
controller care decupleaz ˘a sursa evenimentelor externe de clasele interne ce se ocup ˘a
cu gestionarea evenimentului sau evenimentelor, dup ˘a caz. ˆIn proiectarea aplicat ¸iei,
fiec˘arui caz de utilizare ˆıi este asociat unul sau mai mult ¸i controlleri, ˆın funct ¸ie de
complexitatea cazului de utilizare. Astfel se ˆımp˘art ¸e fluxul de control ˆın p˘arti gestion-
abile.
6.Polimorfism
Polimorfismul foloses ¸te supraclase abstracte sau interfet ¸e. Atunci c ˆand apar probleme
ˆın crearea de clase reutilizabile sau ˆın rezolvarea unei reponsabilit ˘at ¸iˆın clase diferite,
se utilizeaz ˘a acest model ce foloses ¸te operat ¸ii specifice claselor al c ˘aror comportament
variaz ˘a.
7.Invent ¸ie (en: Pure Invention)
Atunci c ˆand unei clase ˆıi revine o responsabilitate astfel ˆıncat s ˘a nu fie ˆınc˘alcate prin-
cipiile de coeziune ˆınalt˘a s ¸i cuplare slab ˘a, solut ¸ia problemei ˆıi revine acestui model
de proiectare. Astfel c ˘a acesta atribuie responsabilit ˘at ¸ile unei clase artificial ˘a pentru a
p˘astra un echilibru pe baza acelor principii. Clasa software artificial ˘a este inventat ˘a de
c˘atre proiectant[CBDAS].
4.2 Diagrama de interact ¸iune
Modul ˆın care interact ¸ioneaz ˘a dou ˘a sau mai multe obiecte ˆın cadrul unui caz de utilizare, este
descris prin intermediul diagramelor de interact ¸iune.
Diagramele de interact ¸iune sunt de doua tipuri:
1.diagrama de secvent ¸e;
2.diagrama de comunicare;
Avantajul utiliz ˘arii diagramelor de secvent ¸e este faptul c ˘a acestea indic ˘a ordinea ˆın care sunt
transmise mesajele, av ˆand astfel s ¸i o flexibilitate mult mai mare dec ˆatˆın cazul diagramelor
de comunicare.
Cele dou ˘a diagrame evident ¸iaz ˘a acelas ¸i lucru s ¸i anume colaborarea obiectelor c ˆand este
realizat fiecare caz de utilizare cu diagrama de interact ¸iune aferent ˘a[CBDAS]. Diferent ¸a din-
tre cele dou ˘a tipuri de diagrame o vom exemplifica dup ˘a cum urmeaz ˘a: Figura 4.1 reprezint ˘a
diagrama de secvent ¸e, iar Figura 4.2 reprezint ˘a diagrama de comunicare.
25

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Figura 4.1 : Diagrama secvent ¸e
Figura 4.2 : Diagrama de comunicare
ˆIn continuare vom prezenta ˆın faza de proiectare diagrama de secvente pentru cazul de uti-
lizareAchizit ¸ionare bilet ˆın Figura 4.3.
26

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Figura 4.3 : Diagrama de secvent ¸e pentru cazul de utilizare Achizit ¸ionare bilet
27

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Pentru a realiza interfat ¸a cu utilizatorul s-a folosit limbajul XML care a facilitat modul
de interact ¸iune cu utilizatorul. O parte demonstrativ ˘a a codului XML este prezentat ˘aˆın codul
surs˘a ce urmeaz ˘a:
<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout
xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:tools="http://schemas.android.com/tools"
android:layout_width="match_parent"
android:layout_height="match_parent"
android:background="drawable/backsms"
tools:context=".ControllerBilete">
<ImageView
android:layout_width="180px"
android:layout_height="50px"
android:src="drawable/btnc"
android:id="+id/button"
android:layout_below="+id/spinner"
android:layout_centerHorizontal="true"
android:layout_marginTop="26dp" />
<Spinner
android:id="+id/spinner"
android:layout_width="280dp"
android:layout_height="43px"
android:background="drawable/spinner"
android:layout_marginBottom="34dp"
android:layout_alignBottom="+id/spinner_calatorie"
android:layout_centerHorizontal="true">
</Spinner>
<Spinner
android:id="+id/spinner_calatorie"
android:layout_width="280dp"
android:layout_height="43px"
android:background="drawable/spinner"
android:layout_alignParentBottom="true"
android:layout_alignLeft="+id/spinner"
android:layout_alignStart="+id/spinner"
android:layout_marginBottom="184dp">
</Spinner>
<TextView android:text="string/message_received"
android:id="+id/txtmesaj"
android:layout_width="350dp"
android:layout_height="200dp"
28

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
android:textSize="25dp"
android:textAlignment="center"
android:textColor="color/colorPrimaryDark"
android:layout_below="+id/button"
android:layout_alignParentLeft="true"
android:layout_alignParentStart="true"
android:layout_marginTop="33dp" />
</RelativeLayout>
ˆIn Figura 4.4 afis ¸ ˘am o fereastr ˘a rezultat ˘aˆın urma codului inserat mai sus, din care utilizatorul
poate selecta linia s ¸i tipul biletului pentru a-s ¸i achizit ¸iona un bilet.
Figura 4.4 : Fereastr ˘a achizit ¸ionare bilet
Pentru implementarea acestui caz de utilizare, conform diagramei de secvent ¸e regasit ˘a
ˆın Figura 4.3, am folosit clasa ControllerBilete, pentru a gestiona cu us ¸urint ¸ ˘a fluxul de con-
trol.
Conform sursei [CBLDPOO], aceast ˘a clas ˘a decupleaz ˘a sursa evenimentelor externe de
cele interne, gestion ˆand evenimentul.
Aceast ˘a clas ˘a cont ¸ine mai multe metode pentru a putea realiza achizit ¸ionarea unui bilet.
MetodaonCreate(Bundle savedInstanceState) care creeaz ˘a o instant ¸ ˘a nou ˘a a
ferestrei de achizit ¸ie a biletului, acest lucru put ˆand fi vizibil ˆın codul urm ˘ator:
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_bilet);
getSupportActionBar().setTitle("");
29

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
getSupportActionBar().setBackgroundDrawable(getResources()
.getDrawable(R.drawable.toolbar));
mydb = new ManagerBazaDeDate(this);
creareMesaj();
}
Figura 4.5 prezint ˘a o demonstrat ¸ie a unei achizit ¸ion ˘ari de bilet.
Figura 4.5 : Selectare linie si tip bilet pentru achizit ¸ionare de bilet
30

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Dac˘a utilizatorul aplicat ¸iei nu a selectat linia sau tipul biletului, aplicat ¸ia afis ¸eaz ˘a un
mesaj de informare, acest lucru fiind vizibil ˆın Figura 4.6.
Figura 4.6 : C˘al˘atorul nu a selectat nici linia s ¸i nici coloana
Dac˘a au fost selectate at ˆat linia c ˆat s ¸i tipul biletului, atunci se primes ¸te un cod de
c˘al˘atorie care este afis ¸at pe ecran (Figura 4.7).
Figura 4.7 : C˘al˘atorul a primit un cod de c ˘al˘atorie
31

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
MetodacreareMesaj() creeaz ˘a un mesaj ˆın funct ¸ie de ceea ce c ˘al˘atorul selecteaz ˘a
din fereastra de Achizit ¸ionare bilet. Aceast ˘a metod ˘a este prezentat ˘a dup ˘a cum urmeaz ˘a:
protected void creareMesaj(){
intentFilter = new IntentFilter();
intentFilter.addAction("SMS_RECEIVED_ACTION");
spinner=(Spinner)findViewById(R.id.spinner);
adapter=ArrayAdapter.createFromResource(this,
R.array.linie,android.R.layout.simple_spinner_item);
adapter.setDropDownViewResource(android.R.
layout.simple_spinner_dropdown_item);
spinner.setAdapter(adapter);
spinner.setOnItemSelectedListener(new
AdapterView.OnItemSelectedListener() {
public void onItemSelected(AdapterView<?> parent, View view, int
position, long id) {
if(position==0){
msg1="neselectat";
return;
}else {
if (position == 6) {
msg1 = "540";
} else {
if (position == 9) {
msg1 = "243";
} else {
msg1 = (String) parent.getItemAtPosition(position);
}
}
}
}
public void onNothingSelected(AdapterView<?> parent) {
Toast.makeText(getBaseContext(), "Selecteaza linia pe care doresti
calatoria!", Toast.LENGTH_LONG).show();
}
});
spinner_calatorie=(Spinner)findViewById(R.id.
spinner_calatorie);
adapter_calatorie=ArrayAdapter.createFromResource(this,R.
array.calatorie,android.R.layout.simple_spinner_item);
adapter_calatorie.setDropDownViewResource(android.R.
layout.simple_spinner_dropdown_item);
spinner_calatorie.setAdapter(adapter_calatorie);
spinner_calatorie.setOnItemSelectedListener(new
AdapterView.OnItemSelectedListener() {
Override
public void onItemSelected(AdapterView<?> parent, View view, int
position1, long id) {
32

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
if(position1==0){
msg2="neselectat";
return;
}else{
if(position1==1){
msg2="L";
}else {
if (position1 == 2) {
msg2 = "ZI";
} else {
if (position1 == 3) {
msg2 = "ESTIVAL";
}
}
}
}
}
Override
public void onNothingSelected(AdapterView<?> parent) {
Toast.makeText(getBaseContext(), "Selecteaza tipul calatoriei!",
Toast.LENGTH\_LONG).show();
}
});
no="0747193218";
btnSendSms=(ImageView)findViewById(R.id.button);
btnSendSms.setOnClickListener(new View.OnClickListener() {
Override
public void onClick(View v) {
if(msg1!="neselectat" msg2!="neselectat") {
if (msg2 == "ESTIVAL") {
mesaj = msg2;
sendSms(mesaj);
} else {
mesaj = msg2 + msg1;
sendSms(mesaj);
}
}
else
Toast.makeText(getBaseContext(), "Selecteaza linia si tipul
biletului!", Toast.LENGTH\_LONG).show();
}
});
Dup˘a ce se creeaz ˘a mesajul, acesta trebuie s ˘a fie trimis c ˘atre num ˘arul de telefon de la care se
primes ¸te un mesaj ce cont ¸ine un cod de c ˘al˘atorie.
protected void sendSms(String message){
String number=no;
message=mesaj;
33

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
SmsManager manager= SmsManager.getDefault();
manager.sendTextMessage(number, null, message, null, null);
Context context = getApplicationContext();
CharSequence text = "Va rugam sa asteptati mesajul de confirmare!";
int duration = Toast.LENGTH_LONG;
Toast toast = Toast.makeText(context, text, duration);
toast.show();
}
ˆInAnexa1 este prezentat codul surs ˘a care face posibil ˘a inserarea ˆın baza de date a
informat ¸iilor biletului nou achizit ¸ionat.
ˆIn cadrul urm ˘atoarei ferestre, exist ˘a posibilitatea select ˘arii unei opt ¸iuni dintr-un meniu
creat special pentru utilizatorii care frecventeaz ˘a aplicat ¸ia. Astfel c ˘aˆın Figura 4.8 se poate
observa acest meniu simplu din care se pot vizualiza biletele achizit ¸ionate.
Figura 4.8 : Meniul aplicat ¸iei s ¸i biletele achizit ¸ionate
ˆIn continuare vom prezenta ˆın faza de proiectare diagrama de secvente pentru cazul de
utilizareAutentificare S ¸ofer ˆın Figura 4.9.
34

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Figura 4.9 : Diagrama de secvent ¸e pentru cazul de utilizare Autentificare S ¸ofer
Preluarea datelor ˆın cadrul aplicat ¸iei se face ˆın clasaAutentificare S ¸ofer . Co-
dul surs ˘a care face posibil acest lucru este prezentat dup ˘a cum urmeaz ˘a:
bLogin.setOnClickListener(new View.OnClickListener() {
35

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Override
public void onClick(View v) {
final String username = etUsername.getText().toString();
final String password =
MD5.encrypt(etPassword.getText().toString());
Response.Listener<String> responseListener = new
Response.Listener<String>() {
Override
public void onResponse(String response) {
try {
System.out.print("aici");
JSONObject jsonResponse = new JSONObject(response);
boolean success = jsonResponse.getBoolean("success");
System.out.println("test pentru succes:"+success);
if (success) {
AlertDialog.Builder builder = new
AlertDialog.Builder(AutentificareSofer.this);
builder.setMessage("Login Success")
.setNegativeButton("Ok", null)
.create()
.show();
Intent intent = new Intent(AutentificareSofer.this,
FereastraPrincipala.class);
intent.putExtra("username", username);
AutentificareSofer.this.startActivity(intent);
} else {
AlertDialog.Builder builder = new
AlertDialog.Builder(AutentificareSofer.this);
builder.setMessage("Date de autentificare gresite")
.setNegativeButton("Reincearca", null)
.create()
.show();
}
} catch (JSONException e) {
e.printStackTrace();
}
}
};
CerereAutentificare cerereAutentificare = new
CerereAutentificare(username, password, responseListener);
RequestQueue queue =
Volley.newRequestQueue(AutentificareSofer.this);
queue.add(cerereAutentificare);
}
});
36

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Constructorul CerereAutenficare creeaz ˘a obiectulcerereAutentificare
cu ajutorul c ˘aruia realizeaz ˘a o cerere c ˘atre server. Mai jos este codul constructorului:
public class CerereAutentificare extends StringRequest {
private static final String LOGIN_REQUEST_URL =
"https://svasile.ro/closcaru/login.php"
private Map<String, String> params;
public CerereAutentificare(String username, String password,
Response.Listener<String> listener) {
super(Method.POST, LOGIN_REQUEST_URL, listener, null);
params = new HashMap<>();
params.put("Nume", username);
params.put("Parola", password);
}
Override
public Map<String, String> getParams()
{
return params;
}
}
Descrierea de mai sus poate fi urm ˘arit˘aˆın Figura 4.10
Figura 4.10 : Autentificare S ¸ofer
ˆIn figura 4.11, dac ˘a s ¸oferul gres ¸es ¸te datele de autentificare, aplicat ¸ia afis ¸eaz ˘a un mesaj
informativ.
37

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Figura 4.11 : Autentificare S ¸ofer, credent ¸iale gres ¸ite
Dac˘a s ¸oferul a introdus datele de autentificare corecte, fereastra nou afis ¸at ˘a permite
acestuia s ˘a porneasc ˘a localizarea sau, dup ˘a caz, sa o opreasc ˘a, acest lucru fiind vizibil ˆın
Figura 4.12.
Figura 4.12 : Fereastra de localizare autobuz
Odat ˘a pornit ˘a localizarea, se realizeaz ˘a o conectare la server ˆın care se executa interog ˘ari
asupra bazei de date pentru a se modifica c ˆampurile latitudine, longitudine s ¸i vitez ˘a.
38

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
ˆIn codul urm ˘ator se prezint ˘a conectarea la server care se face ˆın clasaCereriUpdate .
public class CereriUpdate extends StringRequest {
private static final String REGISTER_REQUEST_URL =
"https://svasile.ro/closcaru/update_autobuz.php";
private Map<String, String> params;
public CereriUpdate(String nume, Double latitudine, Double
longitudine, long viteza, Response.Listener<String> listener) {
super(Method.POST, REGISTER_REQUEST_URL, listener, null);
params = new HashMap<>();
params.put("Nume", nume);
params.put("Latitudine", latitudine + "");
params.put("Longitudine", longitudine + "");
params.put("Viteza", viteza + "");
}
Override
public Map<String,String> getParams(){
return params;
}
}
Fis ¸ierul PHP care realizeaz ˘a conectarea la baza de date s ¸i realizeaz ˘a modificarea c ˆampurilor
ment ¸ionate mai sus, este redat ˆın cele ce urmeaz ˘a:
<?php
$con = mysqli_connect("localhost:3306", "svasiler_closcar",
"Closcaru95", "svasiler_closcaru_autobuze");
$nume = $_POST["Nume"];
$parola = $_POST["Parola"];
$latitudine = $_POST["Latitudine"];
$longitudine = $_POST["Longitudine"];
$viteza= $_POST["Viteza"];
$statement = mysqli_prepare($con, "Update locatii INNER JOIN
autobuze ON locatii.Id_autobuz=autobuze.Id SET
locatii.Latitudine=?, locatii.Longitudine=?, locatii.Viteza=?
Where autobuze.Nume =?");
mysqli_stmt_bind_param($statement, "ddss", $latitudine,
$longitudine, $viteza, $nume);
mysqli_stmt_execute($statement);
$response = array();
$response["success"] = false;
if(mysqli_stmt_execute($statement)){
$response["success"] = true;
39

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
}
echo json_encode($response);
?>
Clasa care preia informat ¸iile de la s ¸ofer, le proceseaz ˘a s ¸i le trimite c ˘atre baza de date
esteLocalizareAutobuz . MetodagetLocation() seteaz ˘a perioada, acuratet ¸ea cu
care se realizeaz ˘a localizarea s ¸i priorit ˘at ¸ile de localizare.
private void getLocation() {
locationRequest = LocationRequest.create();
locationRequest.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);
locationRequest.setInterval(LOCATION_INTERVAL);
locationRequest.setFastestInterval(LOCATION_INTERVAL);
fusedLocationProviderApi = LocationServices.FusedLocationApi;
googleApiClient = new GoogleApiClient.Builder(this)
.addApi(LocationServices.API)
.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.build();
if (googleApiClient != null) {
googleApiClient.connect();
}
}
Google Maps API are o mult ¸ime de funct ¸ionalit ˘at ¸i. Pentru a putea s ¸ti c ˘a autobuzul se
deplaseaz ˘a, am folosit metoda onLocationChanged(Location location) . Dupa
cum observam ˆın codul de mai jos, ˆın interiorul acestei metode, se preiau coordonatele au-
tobuzului care sunt trecute ˆın baza de date cu ajutorul constructorului CereriUpdate
(numeAutobuz, Latitudine, Longitudine, Viteza, responseListener) .
public void onLocationChanged(Location location) {
Toast.makeText(mContext, "Driver location :" +
location.getLatitude() + " , " + location.getLongitude(),
Toast.LENGTH_SHORT).show();
System.out.println("lat: " + location.getLatitude() + " lang:" +
location.getLongitude());
final Double Latitudine = location.getLatitude();
final Double Longitudine = location.getLongitude();
final long Viteza = (long) location.getSpeed();
LocationManager locationManager = (LocationManager)
getSystemService(Context.LOCATION_SERVICE);
Criteria criteria = new Criteria();
criteria.setAccuracy(Criteria.ACCURACY_FINE);
40

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
String bestprovider = locationManager.getBestProvider(criteria,
true);
if (ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION) !=
PackageManager.PERMISSION_GRANTED &&
ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_COARSE_LOCATION) !=
PackageManager.PERMISSION_GRANTED) {
return;
}
currentlocation =
locationManager.getLastKnownLocation(bestprovider);
double speed = 0;
if (this.mLastLocation != null)
{
Location loc = new Location("");
loc.setLatitude(44.205256);
loc.setLongitude(28.6438805);
double dist = location.distanceTo(loc);
speed = location.getSpeed();
float timp = (float) (dist/speed);
Toast.makeText(mContext, speed+" t:"+timp,
Toast.LENGTH_SHORT).show();
}
if (location.hasSpeed())
{
speed = location.getSpeed();
}
this.mLastLocation = location;
Response.Listener<String> responseListener = new
Response.Listener<String>() {
Override
public void onResponse(String response) {
try {
JSONObject jsonResponse = new JSONObject(response);
boolean success = jsonResponse.getBoolean("success");
if (success) {
Log.e(TAG,"Update reusit");
} else {
Log.e(TAG,"Update nereusit");
}
41

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
} catch (JSONException e) {
e.printStackTrace();
}
}
}
CereriUpdate cereriUpdate = new CereriUpdate(numeAutobuz,
Latitudine, Longitudine, Viteza, responseListener);
RequestQueue queue =
Volley.newRequestQueue(LocalizareAutobuz.this);
queue.add(cereriUpdate);
}
Urm ˘atorul caz de utilizare descris este Vizualizare autobuze . Diagrama de
secvent ¸e a acestui caz de utilizare este prezentat ˘aˆın Figura 4.13.
42

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Figura 4.13 : Diagrama in faz ˘a de proiectare pentru cazul de utilizare Vizualizare autobuze
43

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Pentru implementarea acestui caz de utilizare am folosit clasele ControllerAutobuze ,
Fereastr ˘a principal ˘asiFereastr ˘a autobuze , iar pentru vizualizarea auto-
buzelor din trafic, clasa VizualizareInformatii .
Atunci c ˆand c ˘al˘atorul selecteaz ˘a din FereastraPrincipal ˘a vizualizarea autobuzelor, se
apeleaz ˘a metodacereVizualizareAutobuze() , care prin intermediul controller-ului
ControllerAutobuze creeaz ˘a o fereastr ˘aˆın care sunt afis ¸ate autobuzele din trafic (Figura
4.14).
Figura 4.14 : Meniul principal s ¸i fereastra de vizualizare a autobuzelor
Cˆand este creat ˘a fereastra cu autobuze se apeleaz ˘a o funct ¸ie built-in onCreate(Bundle
savedInstanceState) ˆın interiorul c ˘areia se seteaz ˘a cont ¸inutul ferestrei si daca este
necesar, se ˆıncarc ˘a harta(cu ajutorul metodei setMapIfNeeded() ). Codul surs ˘a este
prezentat ˆın continuare:
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_maps);
SupportMapFragment mapFragment = (SupportMapFragment)
getSupportFragmentManager()
.findFragmentById(R.id.map);
mapFragment.getMapAsync(this);
setUpMapIfNeeded();
client = new
GoogleApiClient.Builder(this).addApi(AppIndex.API).build();
}
Metoda principal ˘a care realizeaz ˘a conectarea la baza de date s ¸i afis ¸eaz ˘a autobuzele
prezente ˆın trafic, se numeste verficaAutobuze . Aceast ˘a clas ˘a se foloses ¸te de clasa
LocalizareAutobuz pentru a manipula datele de la baza de date.
44

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Codul surs ˘a este prezentat ˆın continuare:
public void verificaAutobuz(){
mMap.clear();
mMap.setBuildingsEnabled(true);
final String[] str = {""};
Response.Listener<String> responseListener = new
Response.Listener<String>() {
public void onResponse(String response) {
try {
JSONArray jArray = new JSONArray(response);
String[] Nume = new String[jArray.length()];
String[] Latitudine = new String[jArray.length()];
String[] Longitudine = new String[jArray.length()];
String[] Timp = new String[jArray.length()];
for (int i = 0; i < jArray.length(); i++) {
JSONObject explrObject = jArray.getJSONObject(i);
Nume[i] = explrObject.getString("Nume");
Latitudine[i] = explrObject.getString("Latitudine");
Longitudine[i] = explrObject.getString("Longitudine");
Timp[i] = explrObject.getString("Timp");
}
for(int i=0;i<jArray.length();i++){
System.out.println("ajunge aici");
mMap.addMarker(new MarkerOptions().position(new
LatLng(Float.parseFloat(Latitudine[i]),
Float.parseFloat(Longitudine[i])))
.title("Autobuz").snippet("Nume:"+Nume[i]+" Timp ramas:"+Timp[i])
.icon(BitmapDescriptorFactory.fromResource(R.drawable.busicon)));
}
} catch (JSONException e) {
e.printStackTrace();
}
}
};
LocalizareAutobuz localizareAutobuz = new
LocalizareAutobuz(str[0], responseListener);
RequestQueue queue =
Volley.newRequestQueue(FereastraAutobuze.this);
queue.add(localizareAutobuz);
}
ˆIn metodaonResponse() se interpreteaz ˘a obiectul de tip JSON primit de la server.
45

Proiectarea s ¸i implementarea aplicat ¸iei Diagrama de interact ¸iune
Urm ˘atorul cod surs ˘a reprezint ˘a clasaManagerAutobuze care conecteaz ˘a aplicat ¸ia la
fis ¸ierul localizare.php pentru a selecta datele necesare afis ¸ ˘arii autobuzelor.
public class LocalizareAutobuz extends StringRequest {
private static final String REGISTER_REQUEST_URL =
"https://svasile.ro/closcaru/localizare.php";
private Map<String, String> params;
public LocalizareAutobuz(String sir, Response.Listener<String>
listener) {
super(Method.POST, REGISTER_REQUEST_URL, listener, null);
params = new HashMap<>();
params.put("r",sir);
}
Override
public Map<String,String> getParams(){
return params;
}
}
Fis ¸ierul localizare.php este prezentat ˆın continuare:
<?php
$con = mysqli_connect("localhost:3306", "svasiler_closcar",
"Closcaru95", "svasiler_closcaru_autobuze");
$query="SELECT
autobuze.Nume,locatii.Latitudine,locatii.Longitudine,locatii.Viteza
FROM autobuze INNER JOIN locatii ON
autobuze.Id=locatii.Id_autobuz";
$return_arr = array();
if($result=mysqli_query($con, $query)){
while ($row=mysqli_fetch_array($result)) {
$response["Nume"] = $row["Nume"];
$response["Latitudine"] = $row["Latitudine"];
$response["Longitudine"] = $row["Longitudine"];
$response["Viteza"] = $row["Viteza"];
array_push($return_arr,$response);
}
}
mysqli_close($con);
echo json_encode($return_arr);
?>
La init ¸ializarea acestei clase, atunci c ˆand se creeaz ˘a contextul curent, se utilizeaz ˘a
46

Proiectarea s ¸i implementarea aplicat ¸iei Diagrame de clase ˆın faza de proiectare
metodasetMapIfNeeded() , al c ˘arei cod il vom prezenta mai jos:
private void setUpMapIfNeeded() {
if (mMap == null) {
mMap = ((SupportMapFragment)
getSupportFragmentManager().findFragmentById(R.id.map))
.getMap();
if (ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_FINE_LOCATION) !=
PackageManager.PERMISSION_GRANTED &&
ActivityCompat.checkSelfPermission(this,
Manifest.permission.ACCESS_COARSE_LOCATION) !=
PackageManager.PERMISSION_GRANTED) {
return;
}
mMap.setMyLocationEnabled(true);
mMap.setMapType(GoogleMap.MAP_TYPE_SATELLITE);
mMap.setBuildingsEnabled(true);
mMap.setTrafficEnabled(true);
if (mMap != null) {
LatLng constanta = new LatLng(44.1983174, 28.6394311);
mMap.moveCamera(CameraUpdateFactory.newLatLng(constanta));
float zoomLevel = (float) 15.0;
CameraPosition position = new CameraPosition.Builder()
.target(constanta)
.zoom(zoomLevel)
.bearing(-5)
.tilt(45)
.build();
mMap.animateCamera(CameraUpdateFactory.newCameraPosition(position));
}
}
}
ˆIn interiorul acestei metode se realizeaz ˘a harta s ¸i modul ˆın care utilizatorul are contact cu
harta. Anexa2 cuprinde informat ¸ii cu privire la codul surs ˘a al acestui caz de utilizare.
4.3 Diagrame de clase ˆın faza de proiectare
Acest tip de diagrame reprezint ˘a o descriere a claselor s ¸i a interfet ¸elor unui sistem ˆımpreun ˘a
cu relat ¸iile dintre ele. Diagramele de clase de proiectare cont ¸in clase, interfet ¸e cu operat ¸ii s ¸i
constante, dar s ¸i relat ¸iile dintre acestea. Se creeaz ˘a foarte us ¸or s ¸i anume prin identificarea
claselor din diagramele de interact ¸iune la care se adaug ˘a relat ¸iile.
47

Proiectarea s ¸i implementarea aplicat ¸iei Diagrame de clase ˆın faza de proiectare
ˆIn continuare vom prezenta diagramele de proiectare pentru fiecare caz de utilizare ale
aplicat ¸ieiFutureBus .
ˆIn Figura 4.15 este redata diagrama de clase de proiectare pentru cazul de utilizare
Achizit ¸ionare bilet .
Figura 4.15 : Diagrama de clase de proiectare pentru cazul de utilizare Achizit ¸ionare bilet
48

Proiectarea s ¸i implementarea aplicat ¸iei Diagrame de clase ˆın faza de proiectare
ˆIn Figura 4.16 este redata diagrama de clase de proiectare pentru cazul de utilizare
Vizualizare autobuze .
Figura 4.16 : Diagrama de clase de proiectare pentru cazul de utilizare Vizualizare-autobuze
ˆIn Figura 4.17 este redata diagrama de clase de proiectare pentru cazul de utilizare
Autentificare s ¸ofer .
49

Proiectarea s ¸i implementarea aplicat ¸iei Diagrame de clase ˆın faza de proiectare
Figura 4.17 : Diagrama de clase de proiectare pentru cazul de utilizare Autentificare S ¸ofer
50

Proiectarea s ¸i implementarea aplicat ¸iei Modelarea bazei de date
4.4 Modelarea bazei de date
Conform sursei [Man2010], Sistemele de Gestiune a Bazelor de Date (SGBD) reprezint ˘a
programe cu ajutorul c ˘arora se proceseaz ˘a date. Aceste programe ajut ˘a utilizatorii s ˘a struc-
tureze datele ˆın baze de date (denumite astfel bd) s ¸i ˆın acelas ¸i timp permit exploatarea datelor
ˆın mod concurent, de c ˘atre mai muli utilizatori. SGBD-urile asigur ˘a mecanisme pentru:
1.memorarea (structurat ˘a a) datelor
2.accesul la date
3.protect ¸ia datelor ( ˆımpotriva accesului neautorizat)
4.p˘astrarea integrit ˘at ¸ii datelor
5.recuperarea din erori.
Pentru a realiza aplicat ¸ia, am utilizat structura de baz ˘a de date a cazului de utilizare
Vizualizare autobuze , regasit ˘aˆın Figura 4.18.
Figura 4.18 : Diagrama bazei de date de tip Mysql
Pentru cazul de utilizare Achizit ¸ionare bilet , SGBD-ul utilizat este SqLite iar
structura acestuia este redat ˘a dup ˘a cum urmeaz ˘a:
public static final String DATABASE_NAME = "Bilete.db";
public static final String TABLE_NAME = "bilet_tabel";
public static final String COL_1 = "ID";
public static final String COL_2 = "LINIE";
public static final String COL_3 = "TIP_BILET";
public static final String COL_4 = "COD_BILET";
public static final String COL_5 = "DATA_CUMPARARE";
public static final String COL_6 = "DATA_EXPIRARE";
Pentru a defini structura s ¸i schema bazei de date, am utilizat sintaxa DDL de creare a
unui tabel, prin metoda onCreate(SQLiteDatabase db) .
51

Proiectarea s ¸i implementarea aplicat ¸iei Modelarea bazei de date
public void onCreate(SQLiteDatabase db) {
db.execSQL("create table " + TABLE_NAME + " (ID INTEGER PRIMARY
KEY AUTOINCREMENT,LINIE TEXT,TIP_BILET TEXT,COD_BILET
TEXT,DATA_CUMPARARE TEXT,DATA_EXPIRARE TEXT)");
}
Metoda care se ocup ˘a cu inserarea datelor ˆın tabele este insereazaDate(String linie,
String tip bilet, String cod bilet, String data cumparare, String
dataexpirare) .
public boolean insereazaDate(String linie, String tip_bilet,
String cod_bilet, String data_cumparare, String data_expirare){}
SQLiteDatabase db = this.getWritableDatabase();
ContentValues contentValues = new ContentValues();
contentValues.put(COL_2,linie);
contentValues.put(COL_3,tip_bilet);
contentValues.put(COL_4,cod_bilet);
contentValues.put(COL_5,data_cumparare);
contentValues.put(COL_6,data_expirare);
long result = db.insert(TABLE_NAME,null,contentValues);
if(result == -1)
return false;
else
return true;
}
Metoda getBilete() preia toate informat ¸iile existente ˆın baza de date de tip SqLite s ¸i le
afis ¸eaz ˘a:
public Cursor getBilete(){
SQLiteDatabase db = this.getWritableDatabase();
Cursor res = db.rawQuery("select *from "+ TABLE_NAME+ " ORDER BY
"+ COL_1+" DESC",null);
return res;
}
ˆIn cadrul cazului de utilizare Vizualizare Autobuze , baza de date de tip MySql
cont ¸ine tabelele mai sus ment ¸ionate.
Pentru a gestiona datele am utilizat fis ¸iere PHP. Acestea se conecteaz ˘a la baza de date
s ¸i prin intermediul unui JSON(JavaScript Object Notation) realizez tranzact ¸ii ˆıntre client s ¸i
server.
Fis ¸ierullogin.php realizeaz ˘a conexiunea la baza de date s ¸i ˆın funct ¸ie de informat ¸iile
primite de la aplicat ¸ie ˆıncapsuleaz ˘a aceste informat ¸ii ˆıntr-un obiect de tip JSON. Codul aces-
52

Proiectarea s ¸i implementarea aplicat ¸iei Modelarea bazei de date
tui fis ¸ier este prezentat mai jos:
<?php
$con = mysqli_connect("localhost:3306", "svasiler_closcar",
"Closcaru95", "svasiler_closcaru_autobuze");
$nume = $_POST["Nume"];
$parola = $_POST["Parola"];
$statement = mysqli_prepare($con, "SELECT Nume,Parola FROM
autobuze WHERE Nume = ? AND Parola = ?");
mysqli_stmt_bind_param($statement, "ss", $nume, $parola);
mysqli_stmt_execute($statement);
mysqli_stmt_store_result($statement);
mysqli_stmt_bind_result($statement, $nume, $parola);
$response = array();
$response["success"] = false;
while(mysqli_stmt_fetch($statement)){
$response["success"] = true;
}
echo json_encode($response);
?>
53

Capitolul 5
Concluzii
Rezultatele prezentate ˆın aceast ˘a lucrare au fost trimise spre publicare la ”Conferint ¸a de
Interact ¸iune Om-Calculator”,Rochi 2017.
Pentru a putea crea aceast ˘a aplicat ¸ie am realizat descrierea problemei ˆın care am in-
trodus informat ¸ii obt ¸inute din diverse surse citate ˆın bibliografie. Baz ˆandu-m ˘a pe aceast ˘a
descriere am urmat etapele necesare cre ˘arii unei aplicat ¸ii software.
O alt ˘a etap ˘a important ˘aˆın realizarea aplicat ¸iei este etapa de analiz ˘a.ˆIn cadrul acestei
etape am realizat documentul de cerint ¸e. Tot aici am realizat modelul funct ¸ional care cont ¸ine
diagrama cazurilor de utilizare software dar s ¸i descrierea acestora. Cu ajutorul descrierii
problemei, am reusit s ˘a reprezint diagrama de clase care apart ¸ine modelului domeniului.
Urm ˘atorul pas ˆın dezvoltarea sistemului este reprezentat de c ˘atre construct ¸ia diagramelor
de secvent ¸e de sistem, utile deoarece furnizeaz ˘a mesaje ˆıntre actorii software si sistemul
FutureBus .
Pentru realizarea codului surs ˘a, am creat diagramele de secvent ¸e ˆın faza de proiectare
pentru fiecare caz de utilizare ˆın parte, acest pas realiza ˆandu-se ˆın etapa de proiectare. Tot ˆın
aceast ˘a etap ˘a am creat diagrame de clase software s ¸i am proiectat baza de date ˆın MySQL.
Aceasta din urm ˘a a fost utilizat ˘a de sistem pentru gestiunea datelor persistente.
ˆIn realizarea diagramelor am utilizat programul Astah[Astah], un program prietenos s ¸i
us ¸or de utilizat.
ˆImbin ˆand cele mai sus ment ¸ionate am reus ¸it implementarea sistemului FutureBus
folosind limbajele Java s ¸i PHP. Aplicat ¸ia ruleaz ˘a pe sistemul de operare Android, versiunea
cel put ¸in 4.0.
Pentru a testa funct ¸ionalitatea aplicat ¸iei am folosit 3 persoane care au realizat teste din
punctele de vedere ale actorilor software ai aplicat ¸iei. Rezultatul furnizat de c ˘atre cele 3
persoane au fost favorabile s ¸i nu au existat probleme, aplicat ¸ia furniz ˆand rezultate corecte.
54

Capitolul 6
Anexe
6.1 Anexa 1
Cod surs ˘a pentru cazul de utilizare Achizit ¸ionare bilet
Override
public boolean onCreateOptionsMenu(Menu menu) {
MenuInflater inflater = getMenuInflater();
inflater.inflate(R.menu.main_menu, menu);
return super.onCreateOptionsMenu(menu);
}
Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case R.id.bilete_id:
Cursor resursa = mydb.getBilete();
if (resursa.getCount() == 0) {
afiseazaMesaj("Bilete Achizitionate", "Nu ai niciun bilet
cumparat!");
return true;
}
StringBuffer buffer = new StringBuffer();
while (resursa.moveToNext()) {
buffer.append("Id: " + resursa.getString(0) + "\n");
buffer.append("Linie: " + resursa.getString(1) + "\n");
buffer.append("Tip Abonament: " + resursa.getString(2) + "\n");
buffer.append("Cod: " + resursa.getString(3) + "\n");
buffer.append("Data cumparare: " + resursa.getString(4) + "\n");
buffer.append("Data expirare: "+resursa.getString(5)+"\n");
buffer.append("––––––––––––––––
55

Anexe Anexa 1
––-"+"\n\n\n");
}
afiseazaMesaj("Bilete Achizitionate", buffer.toString());
return true;
case R.id.about_id:
setContentView(R.layout.activity_contact);
return true;
case R.id.harta_id:
Intent homeIntent = new Intent(ControllerBilete.this,
FereastraAutobuze.class);
startActivity(homeIntent);
return true;
default:
return super.onOptionsItemSelected(item);
}
}
private BroadcastReceiver intentReceiver = new
BroadcastReceiver() {
Override
public void onReceive(Context context, Intent intent) {
TextView texttxt = (TextView)findViewById(R.id.txtmesaj);
DateFormat formatData = new SimpleDateFormat("dd/MM/yyyy
HH:mm:ss");
DateFormat formatDataNou = new SimpleDateFormat("MM/yyyy");
Date astazi = Calendar.getInstance().getTime();
Date astaziNou = Calendar.getInstance().getTime();
String data_cumparare = formatData.format(astazi);
String data_expirare = formatDataNou.format(astaziNou);
System.out.println("Report Date: " + data_cumparare + " si " +
astazi.getDate() + "/" + data_expirare + " " +
astazi.getHours() + ":" + astazi.getMinutes() + ":" +
astazi.getSeconds());
getCod(intent);
System.out.println(getCod(intent));
texttxt.setText("Cod de calatorie:\n"+ getCod(intent));
int calatorie;
int abonament = astazi.getDate()+1;
int estival = astazi.getHours()+1;
int ora = astazi.getHours()+1;
calatorie = astazi.getMinutes()+40;
System.out.println(estival+"si"+ora);
boolean isInserted;
56

Anexe Anexa 1
if(msg2=="L") {
if(calatorie>=60){
calatorie=calatorie-60;
isInserted = mydb.insereazaDate(msg1, msg2, getCod(intent),
data_cumparare, astazi.getDate()+"/"+data_expirare+"
"+estival+":"+calatorie+":"+astazi.getSeconds());
}else {
isInserted = mydb.insereazaDate(msg1, msg2, getCod(intent),
data_cumparare, astazi.getDate() + "/" + data_expirare + " " +
astazi.getHours() + ":" + calatorie + ":" +
astazi.getSeconds());
}
}else {
if (msg2 == "ZI") {
isInserted = mydb.insereazaDate(msg1, msg2, getCod(intent),
data_cumparare, abonament+"/"+data_expirare+"
"+astazi.getHours()+":"+astazi.getMinutes()+":"+astazi.getSeconds());
}else{
isInserted = mydb.insereazaDate(msg1, msg2, getCod(intent),
data_cumparare,astazi.getDate()+"/"+data_expirare+"
"+estival+":"+astazi.getMinutes()+":"+ astazi.getSeconds());
}
}
if (isInserted == true)
Toast.makeText(ControllerBilete.this, "Data inserata",
Toast.LENGTH_LONG).show();
else
Toast.makeText(ControllerBilete.this, "Data neinserata",
Toast.LENGTH_LONG).show();
}
};
public void onResume(){
registerReceiver(intentReceiver,intentFilter);
super.onResume();
}
public void onPause(){
unregisterReceiver(intentReceiver);
super.onPause();
}
public void onReceive(Context context, Intent intent) {
Bundle bundle = intent.getExtras();
SmsMessage[] messages = null;
String str = "";
if(bundle!=null){
Object[] pdus = (Object[])bundle.get("pdus");
57

Anexe Anexa 2
messages = new SmsMessage[pdus.length];
for(int i =0;i<messages.length;i++){
messages[i] = SmsMessage.createFromPdu((byte[])pdus[i]);
}
}
Intent broadcastIntent = new Intent();
broadcastIntent.setAction("SMS_RECEIVED_ACTION");
broadcastIntent.putExtra("sms",str);
context.sendBroadcast(broadcastIntent);
}
}
6.2 Anexa 2
Cod surs ˘a pentru cazul de utilizare Autentificare S ¸ofer
private void managePermissions() {
if(ActivityCompat.checkSelfPermission(this,
Manifest.permission.INTERNET)!=
PackageManager.PERMISSION_GRANTED){
ActivityCompat.requestPermissions(this, new
String[]{Manifest.permission.INTERNET},MANIFEST_PERMISSION_INTERNET);
}
else{
showToast();
}
}
private void showToast() {
Toast.makeText(this,"Permisiune pentru
internet",Toast.LENGTH_LONG).show();
}
Override
public void onRequestPermissionsResult(int requestCode, NonNull
String[] permissions, NonNull int[] grantResults) {
super.onRequestPermissionsResult(requestCode, permissions,
grantResults);
switch (requestCode){
case MANIFEST_PERMISSION_INTERNET:
if(grantResults.length>0 && grantResults[0] ==
PackageManager.PERMISSION_GRANTED){
showToast();
}
58

Anexe Anexa 2
else{
if(ActivityCompat.shouldShowRequestPermissionRationale(this,
Manifest.permission.INTERNET)){
new AlertDialog.Builder(this).
setTitle("Internet Permission").
setMessage("Trebuie sa dai permisiune de accesare a internetului!
Reincearca aceasta operatie!").show();
}
else{
new AlertDialog.Builder(this).
setTitle("Internet Permission").
setMessage("Permisiune acordata! Pentru a dezactiva mergi la
setari!").show();
}
}
break;
}
}
public class FereastraPrincipala extends Activity implements
OnClickListener {
Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.user_activity);
Button startButton = (Button)findViewById(R.id.btnStart);
Button stopButton = (Button)findViewById(R.id.btnStop);
stopButton.setEnabled(false);
startButton.setOnClickListener(this);
stopButton.setOnClickListener(this);
}
Override
public void onClick(View v) {
Button startButton = (Button)findViewById(R.id.btnStart);
Button stopButton = (Button)findViewById(R.id.btnStop);
switch (v.getId()) {
case R.id.btnStart:
Intent startIntent = new
Intent(FereastraPrincipala.this,LocalizareAutobuz.class);
startIntent.setAction(Constants.ACTION.STARTFOREGROUND_ACTION);
String user = getUsername();
startIntent.putExtra("name",user);
startService(startIntent);
startButton.setEnabled(false);
stopButton.setEnabled(true);
59

Anexe Anexa 2
break;
case R.id.btnStop:
Intent stopIntent = new Intent(FereastraPrincipala.this,
LocalizareAutobuz.class);
stopIntent.setAction(Constants.ACTION.STOPFOREGROUND_ACTION);
startService(stopIntent);
startButton.setEnabled(true);
stopButton.setEnabled(false);
break;
default:
break;
}
}
public String getUsername(){
Bundle extras = getIntent().getExtras();
String userName="";
if (extras != null) {
userName = extras.getString("username");
}
return userName;
}
}
public class ManagerConexiune {
Context context;
public ManagerConexiune(Context context){
this.context = context;
}
public boolean isConnected(){
ConnectivityManager connectivityManager = (ConnectivityManager)
context.getSystemService(Service.CONNECTIVITY_SERVICE);
if(connectivityManager!=null){
NetworkInfo networkInfo =
connectivityManager.getActiveNetworkInfo();
if(networkInfo!=null){
if(networkInfo.getState() == NetworkInfo.State.CONNECTED) return
true;
}
}
return false;
}
}
60

Anexe Anexa 3
6.3 Anexa 3
Cod surs ˘a pentru cazul de utilizare Vizualizare autobuze
private GoogleMap mMap;
private static int MY_PERMISSION_FINE_LOCATION = 101;
Handler myHandler = new Handler();
int delay = 3000;
Runnable runnable;
private GoogleApiClient client;
public Action getIndexApiAction() {
Thing object = new Thing.Builder()
.setName("Maps Page")
.setUrl(Uri.parse("http://[ENTER-YOUR-URL-HERE]"))
.build();
return new Action.Builder(Action.TYPE_VIEW)
.setObject(object)
.setActionStatus(Action.STATUS_TYPE_COMPLETED)
.build();
}
Override
public void onStart() {
super.onStart();
myHandler.post(myRunnable);
client.connect();
AppIndex.AppIndexApi.start(client, getIndexApiAction());
}
Override
protected void onPause() {
myHandler.removeCallbacks(runnable);
super.onPause();
}
private Runnable myRunnable = new Runnable() {
Override
public void run() {
verificaAutobuz();
runnable=this;
myHandler.postDelayed(runnable, delay);
}
};
Override
public void onStop() {
61

Anexe Anexa 3
super.onStop();
myHandler.removeCallbacks(myRunnable);
AppIndex.AppIndexApi.end(client, getIndexApiAction());
client.disconnect();
}
62

Referint ¸e bibliografice
[CBDAS] Popovici D. M. (coordonator), Bogdan C. M., Rusu A., Chelai O., Nicola A.,
Medii virtuale multimodale distribuite, Editura Universitaria Craiova s ¸i Editura Prouni-
versitaria Bucures ¸ti, 978-606-26-0049-5, 2014, vol 1, 354 pag.
[UMLS] OMG Unified Modelling Language Superstructure,version 2.0, ptc/03-0802, 2003.
[CBMFP] Popovici D. M. (coordonator), Manca C., Bogdan C. M., Zaharescu E., Medii vir-
tuale multimodale distribuite, Editura Universitaria Craiova s ¸i Editura Prouniversitaria
Bucures ¸ti, 978-606-26-0049-5, 2014, vol 2, 271 pag.
[TUMLR1999] Ivar Jacobson, Grady Boocs, James Rumbaugh, The Unified Modelling
Language Reference Manual, Addison-Wesley, 1999.
[CBLDPOO] Crengut ¸a M ˘ad˘alina Bogdan, Luca Dan Serbanati, Programare orientat ˘a spre
obiecte cu exemplific ˘ariˆın limbajul Java, vol.2, 2010.
[Astah] Astah Shortcut Keys, Editor Astah, URL: http://astah.net/tutorials/shortcut-keys ,
site vizitat pe 18 iunie 2017
[Man2010] Christian Mancas ¸ Facultatea de Matematic ˘a s ¸i Informatic ˘a, Universitatea Ovid-
ius , Curs SGBD I III, 2007 – 2008
63