APLICA ȚIE PENTRU TELEFONIA MOBIL Ă DE ORIENTARE INTR -UN ORAȘ Coordonator științific Lect. dr. Crenguța Bogdan Absolvent Drăghicescu Daniel CONSTAN… [618631]
MINISTERUL EDUCAȚIEI ȘI CERCET ǍRII
UNIVERSITATEA “OVIDIUS” CONSTANȚA
FACULTATEA DE MATEMATIC Ǎ ȘI INFORMATIC Ǎ
SPECIALIZAREA INFORMATIC Ǎ
LUCRARE DE LICENȚ Ǎ
APLICA ȚIE PENTRU TELEFONIA MOBIL Ă
DE ORIENTARE INTR -UN ORAȘ
Coordonator științific
Lect. dr. Crenguța Bogdan
Absolvent: [anonimizat]
2007
2 Cuprins
1. Definitia problemei ………………………….. ………………………….. ………………………….. …………………….. 3
1.1 Introducere ………………………….. ………………………….. ………………………….. ………………………….. . 3
1.1.1 Probleme generale ………………………….. ………………………….. ………………………….. …………… 3
1.2 Solutia ………………………….. ………………………….. ………………………….. ………………………….. ……… 3
1.2.1 Scopul proiectului ………………………….. ………………………….. ………………………….. …………… 3
1.2.2 MPF – Mobile Path Finder ………………………….. ………………………….. ………………………….. .. 4
1.2.3 Structura aplicatiei ………………………….. ………………………….. ………………………….. …………… 4
1.2.4 Actor ii software ………………………….. ………………………….. ………………………….. ………………. 5
2. Scenarii software de utilizare a aplicatiei ………………………….. ………………………….. ……………………. 6
3. Analiza si proiectarea sistemului ………………………….. ………………………….. ………………………….. …… 7
3.1 Notiuni generale ………………………….. ………………………….. ………………………….. ……………………. 7
3.1.1 UML ………………………….. ………………………….. ………………………….. ………………………….. …. 7
3.1.2 Cazuri de utilizare ………………………….. ………………………….. ………………………….. …………… 7
3.1.3 Diagrame de clase ………………………….. ………………………….. ………………………….. …………… 8
3.1.4 Diagrame de interactiune ………………………….. ………………………….. ………………………….. …. 8
3.2 Analiza cerintelor software ………………………….. ………………………….. ………………………….. …….. 9
3.2.1 Obiective si interese ………………………….. ………………………….. ………………………….. ………… 9
3.2.2 Cerinte functionale ………………………….. ………………………….. ………………………….. ………… 10
3.2.3 Cerinte nefunctionale ………………………….. ………………………….. ………………………….. …….. 11
3.2.4 Atributele sistemului ………………………….. ………………………….. ………………………….. ……… 11
3.3 Dezvoltarea sistemului ………………………….. ………………………….. ………………………….. …………. 12
3.3.1 Administrarea intersectiilor ………………………….. ………………………….. …………………………. 12
3.3.2 Administrarea drumurilor ………………………….. ………………………….. ………………………….. .. 23
3.3.3 Salvarea datelor ………………………….. ………………………….. ………………………….. …………….. 39
3.3.4 Autentificarea utilizatorilor ………………………….. ………………………….. …………………………. 44
3.3.5 Configurarea conexiunii ………………………….. ………………………….. ………………………….. …. 49
3.3.6 Administrarea oraselor ………………………….. ………………………….. ………………………….. …… 52
3.3.7 Administrarea utilizatorilor ………………………….. ………………………….. …………………………. 62
3.3.8 Identificarea drumurilor dupa nume ………………………….. ………………………….. ……………… 68
3.3.9 Alegerea intersectiei comune ………………………….. ………………………….. ………………………. 70
3.3.10. Gasirea drumului ………………………….. ………………………….. ………………………….. ………… 73
3.4 Proie ctarea bazei de date ………………………….. ………………………….. ………………………….. ………. 74
4. Algoritmul A* ………………………….. ………………………….. ………………………….. ………………………….. 78
5. Tehnologii folosite ………………………….. ………………………….. ………………………….. ……………………. 80
5.1 .NET Framework ………………………….. ………………………….. ………………………….. …………………. 80
5.2 C# ………………………….. ………………………….. ………………………….. ………………………….. …………. 81
5.3 Servicii Web ………………………….. ………………………….. ………………………….. ……………………….. 82
5.4 Ja va 2, Micro Edition (J2ME) ………………………….. ………………………….. ………………………….. .. 84
5.4.1 Servicii Web J2ME (JSR 172) ………………………….. ………………………….. …………………….. 88
5.5 Sony Ericsson – Platforma Java ………………………….. ………………………….. …………………………. 90
6. Contributii personale ………………………….. ………………………….. ………………………….. …………………. 92
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……… 94
3 1. Definitia problemei
1.1 Introducere
Lucrarea de fata incearca sa propu na o solutie a unei problem e care a capata t amploare din
ce in ce mai mare in ziua de astazi: mobilitatea oamenilor. Fie ca este vorba de interese profesionale,
fie ca este vorba de interese personale, de multe ori ne vedem nevoiti sa renuntam o per ioada l a
locurile cunoscute si sa ne adaptam intr -un mediu nou. Nu conteaza ca este vorba despre o intalnire
de afaceri la care trebuie sa mergem sau o excursie neasteptata la munte cu familia; efectul acestor
evenimente este acelasi: trebuie sa invatam repede o zona straina, un oras nou, in care nu ne
permitem sa pierdem timpul ratacind pe strazi necunoscute.
1.1.1 Probleme generale
Problema mobilitatii oamenilor este de mult timp in atentie. Si prin “mult timp” nu ne
referim la ultimii ani, ci la sute de ani in urma , odata cu aparitia primelor harti. Procesul de
cartografiere a inceput treptat sa capete din ce in ce mai multa importanta din cauza expandarii
rapide a asezarilor urbane si rurale si, ca in orice alt domeniu care se dezvolta, din motive
economice.
In ziua de azi, pe langa hartile detaliate la nivel de strada disponibile pana si in ghidurile
turistice, hartile online au inceput sa primeasca si mai multa atentie. Toti furnizorii importanti de
servicii au inceput sa ofere harti online, mai mult sau mai putin detaliate, pentru a ajuta utilizatorii sa
se orienteze in zone necunoscute lor.
O alta dovada a importantei acestui subiect o reprezinta o tehnologie dezvoltata de
Departamentul de Aparare al Statelor Unite si comercializata in ziua de azi, si anum e GPS -ul
(Global Positioning System). Utilizand un numar de 24 de sateliti ce orbiteaza in jurul Pamantului,
tehnologia permite unui receptor GPS sa isi determine locatia pe glob, viteza si directia. Cu aceste
date atasate unei harti locale, problemele de pozitionare se reduc aproape de minim. [1]
1.2 Solutia
1.2.1 Scopul proiectului
Dintotdeauna dezvoltarea tehnologiei a condus la progresul oamenilor . De la aparitia
primului PC pana in ziua de astazi, viata ne -a fost simplificata treptat prin intelegerea si folosirea
instrumentelor informatice . Astazi, odata cu explozia tehnologica pe care o vedem parca in fiecare
zi, a aparut o noua problema a oamenilor: nevoia de mobilitate. Doar asa se poate explica
dezvoltarea mereu in crestere a dispozitivelor mobile. Oamenii nu mai vor doar sa se foloseasca de
puterea enorma de procesare a sistemelor informatice; in ziua de azi, avem nevoie sa folosim aceasta
putere oricand si oriunde vrem.
Gama de produse mobile este diversa: laptop -uri, PDA -uri, Palm -uri, insa intre toate acestea
unul singur exceleaza in popularitate: telefonul mobil. Putini sunt cei care nu au folosit un astfel de
dispozitiv si putini sunt cei care nu isi pot permite unul, daca au nevoie de el. Bineinteles, telefonul
mobil, ca si alte dispozitive m obile de altfel, are un mare dezavantaj: puterea mica de procesare,
aceasta fiind o urmare directa a procesorului si a memoriei insuficiente.
Scopul acestui proiect este de a dezvolta o aplicatie care ruleaza pe un telefon mobil si
exploateaza capacitatea de mobilitate a acestuia, dar fara sa fie afectata de puterea mica de procesare
4 a dispozitivului. Aplicatia va trebui sa ajute un utilizator sa gasesca drumul intre doua puncte ale
unui oras, cunoscut sau necunoscut de el/ea.
Nu se doreste folosirea in c adrului proiectului a tehnologiei GPS existente, ci se incearca
oferirea unei alternative. Daca solutiile GPS sunt mai scumpe si imposibil de implementat de la zero
de catre un dezvoltator, solutia oferita de acest proiect se doreste a fi disponibila la co sturi reduse
pentru orice utilizator si usor de controlat de orice dezvoltator care doreste sa o implementeze.
1.2.2 MPF – Mobile Path Finder
MPF este o aplicatie distribuita, n -tier, structurata pe patru module distin cte, ce ofera solutia
problemei prezen tate in subsectiunea 1.1.1 . Cu ajutorul aplicatiei MPF, un utilizator va putea gasi
drumul intr -un oras, cunoscut sau necunoscut, pentru a ajunge dintr -un punct initial considerat sursa
intr-un punct final considerat destinatie.
Mai precis, vom numi in continuare drum o succesiune de strazi ale unui oras care permit e
plecarea dintr -o intersectie a doua strazi distincte , numita sursa , si parcurgerea strazilor pana la
sosirea intr -o alta intersectie a doua strazi d istincte, denumita destinatie . In plus, impun em conditia
ca sursa nu poate fi niciodata aceeasi cu destinatia.
O aplicatie distribuita este formata din componente distincte, ce ruleaza in medii de executie
separate, de obicei pe platforme diferite conectate printr -o retea. Aplicatiile distribuite ob isnuite sunt
cu doua straturi1 (client -server), trei straturi2 (client -intermediar -server) sau multistrat3 [2].
In ingineria software, arhitectura multistrat (denumita in documentatia de specialitate n -tier)
este o arhitectura client -server in care o apl icatie este executata de mai multi agenti software
distincti. De exemplu, o aplicatie care ofera servicii de comunicare intre un utilizator si o baza de
date foloseste arhitectura multistrat [3] .
Aplicatia va rula pe o arhitectura client -server. Partea cli ent a aplicatiei se executa pe un
telefon mobil; in schimb, procesarea este facuta remote, pe un server dedicat, pentru a nu fi afectata
de contrangerea privind capacitatea insuficienta de procesare a telefonului. Partea server va rula pe
un dizpozitiv fix , la fel ca partea de administrare a sistemului .
1.2.3 Structura aplicatiei
Aplicatia este structurata in patru module distincte :
Modulul client
Acesta ruleaza pe telefonul mobil al utilizatorului si ii permite acestuia sa efectueze cereri
pentru stabilir ea drumului care trebuie parcurs de la o intersectie considerata sursa dintr -un
oras la o intersectie destinatie a aceluiasi oras
Modulul de administrare
Acesta ruleaza pe unul sau mai multe calculato are si permite interactiunea directa i ntre un
utilizator si sistem, in vederea administrarii functiilor sistemului
Modulul server
Acesta este accesat in mod transparent pentru utilizator de catre modulul client si se ocupa cu
procesarea datelor si intoarcerea raspunsului pentru utilizator
Modulul de gestiune a persistentei
Acesta stocheaza datele persistente necesare aplicatiei .
1 two-tier
2 three -tier
3 n-tier
5 Din motive de securitate, modulele Server si de Gestiune a persistentei nu vor putea fi
accesate in mod direct de catre utilizatori. Accesul catre aceste componente este posibil doar pr in
intermediul modulelor Client si Administrare. De asemenea, modificarea modulului server nu poate
fi facuta de nici un utilizator al sistemului.
1.2.4 Actorii software
Un actor software este o entitate ce se identifica prin rolul pe care il „joaca ” fata de un sistem
si cu care interactioneaza . Aceasta entitate trebuie sa aiba un comportament si poate fi o persoana,
un program, o masina, o aplicatie, o organizatie. Un actor ajuta la intelegerea comportamentului
exterior al unui proces [4] [5].
Exista doua roluri distincte pe care un utilizator il poate avea in cadrul sistemului:
User
Acesta este rolul utilizatorului ce foloseste doar modulul client, mai exact componenta
instalata pe telefonul mobil. El nu poate utiliza alte module ale aplicatiei, iar infor matia pe
care o primeste este strict legata de drumul pe care il va parcurge pentru a ajunge de la sursa
la destinatie .
Administrator
Acesta se ocupa cu administrarea sistemului. El poate accesa sistemul prin cadrul unei
aplicatii ce ruleaza local, pe unul sau mai multe calculatoare , si va putea face modificari atat
functionale, legate de utilizatorii sistemului, cat si structurale, legate de informatiile
persistente a le sistemului (orase, strazi, locatii etc). Din motive de securitate, un
administrator nu are aceleasi drepturi ca un user.
Pentru a intari securitatea sistemului, modificarea modulului de gestiune a persistentei poate
fi facuta doar de catre un administrator si doar in cadrul modulului de administrare.
6 2. Scenarii software de u tilizare a aplicatiei
Un scenariu este o serie de evenimente si interac tiuni intre actori si un sistem software .
Actorii dintr -un scenariu pot urm ari o secven ta particular a de ac tiuni in diferite medii externe
(contexte). Un scenariu descrie numai o secven ta. Un scenariu se mai nume ste si o instan ta a
unui caz de utilizare.
Pentru a explica functionalitatea aplicatiei, vom lua ca exemplu o instanta (concretizare) a
unui actor software pentru aplicatia noastra, pe nume Cristina Ionescu. Sa presupunem ca este
chemata la un interviu pentru un post de marketing in cadrul unei companii mari din orasul natal. Ea
cunoaste adresa (denumirea strazii) firmei respective, insa nu stie cum poate ajunge la locatia
respectiva. Folosind aplicatia de pe telefonul ei mobil, C ristina, indeplinind rolul de user, indica
pozitia ei initiala, definita prin intersectia celor mai apropiate doua strazi de locatia ei curenta. Odata
stabilita pozitia initiala , i se va cere destinatia in care doreste sa ajunga, definita ca o intersectie intre
doua strazi. Avand aceste date, aplicatia ii furnizeaza o succesiune de strazi ce trebuie urmate pentru
a ajunge optim la destinatie .
Pentru a explica rolul de administrator, vom presupune ca aplicatia este pusa la dispozitie
abonatilor unei retele de telefonie mobila, drept oferta gratuita, inclusa in pretul abonamentului.
Inainte de lansarea pe piata a aplicatiei, unul sau mai multi administratori trebuie sa asigure
introducerea corecta in baza de date a aplicatiei a datelor despre orasele in care va fi folosit a
aplicatia. In plus, pentru fiecare oras in parte sunt introduse si alte informatii , precum: denumirile
tuturor strazilor din oras, intersectiile dintre acele strazi, si distantele dintre oricare doua intersectii
consecutive. Odata introduse aceste informatii, un utilizator se poate conecta la modulul server al
aplicatiei si poate obtine cu succes datele dorite.
7 3. Analiza si proiectarea sistemului
3.1 Notiuni generale
In acest subcapitol vor fi prezentate unele notiuni de baza din cadrul Ingineriei Programarii,
notiuni fara de care este imposibila analiza si proiectarea unui sistem informatic.
3.1.1 UML
Unified Modeling Language (UML) este limbajul standard de proiectare pentru dezvoltarea
aplica tiilor orientate obiect. Limbajul UML a fost formulat pentru a furniza dezvoltatorilor un limbaj
comun de proiectare a aplica tiilor. El faciliteaz a reprezentarea grafic a a sistemelor orientate -obiect .
UML a fost realizat de OMG (Object Management Group) in 1997, furniz and nota tii comune
care s a faciliteze dezvoltarea aplica tiilor si sa simplific e dezvoltarea proceselor, permitand
modelarea structurii aplica tiilor.
In UML, aplica tiile sunt reprezentate pictografic si formeaz a un model, iar obiectele
reprezint a componente ale modelu lui. Utilizarea UML -ului simplific a conversia modelului in cod.
Proiectarea se face la nivel de detaliu, evit and astfel confuziile din faza de programare.
UML faciliteaz a modelarea aplica tiilor complexe software intr-o form a care este
independent a de lim bajul de programare. UML permite impartirea aplica tiei in sec tiuni simple si
proiectarea lor ca simple task -uri. UML este usor (simplific a intelegerea comportamentului si a
cerin telor) si reutilizabil (identificarea componentelor similare in func tii, carac teristici si structur a).
Limbajul este comun si standardizat.
UML furnizeaz a dezvoltatorilor urm atoarele caracteristici: mecanisme de extensie, fire de
executie si procese, sabloane si colaborari, diagrame de activitate si rafinare.
Arhitectura UML
UML est e bazat pe o arhitectura cu patru straturi. Pe stratul cel mai de jos se gasesc obiectele
utilizatorilor (datele utilizatorilor). La acest strat pot fi g asite instan tele de clase. Urm atorul strat este
numit model. Acest strat con tine clase ce definesc comp ortamentul si structura obiectelor
utilizatorilor. Stratul metamodel define ste ce elemente de modelare sunt acesibile dintr -un model
UML. El con tine elemente cum ar fi Class, Operation, Attribute, Generalization, Actor, UseCase,
Component. Cel mai inalt st rat este meta -metamodel. El define ste limbajul folosit in metamodel.
Obiecte tipice acestui strat sunt MetaClass, MetaAttribute, MetaOperation. Instan tele MetaClass
sunt numite metaclase. Metaclasele apar tin metamodelului.
3.1.2 Cazuri de utilizare
Analiz a cerin telor con tine scenariile care pot avea loc in timp ce sistemul este folosit. Aceste
scenarii sunt documentate sub forma cazurilor de utilizare (use-case) . Cazurile de utilizare sunt
complet realizate in analiza cerin telor deoarece furnizeaz a o trece re in revist a a cerin telor unui
sistem. In continuare se vor prezenta conceptele cheie legate de cazurile de utilizare.
Cazurile de utilizare sunt definite utiliz and scenarii si actori. Un actor este o entitate ce
participa in interactiunile cu sistemul intr-un use -case si se identific a prin rolul pe care il joac a.
Aceasta entitate trebuie sa aiba un comportament si poate fi o persoana, un program, o masina, o
aplicatie, o organizatie. Un actor ajuta la intelegerea comportamentului exterior al unui sistem
pentru a furniza ceva de valoare actorului .
8 Un scenariu este o serie de evenimente si interac tiuni intre actori si un sistem. Actorii dintr –
un scenariu pot urm ari o secven ta particular a de ac tiuni in diferite medii externe (contexte). Un
scenariu descrie nu mai o secven ta. Un scenariu se mai nume ste si o instan ta use-case.
Un use -case este o colec tie de scenarii corelate in care un actor interac tioneaz a cu un sistem
pentru a realiza o activitate sau un task. Scenariile descrise intr-un use -case pot conduce la taskuri de
succes sau insucces.
Cazurile de utilizare nu folosesc o abordare OO. Ele sunt exemple din via ta real a, scrise ca o
povestire. Cazurile de utilizare sunt importante in timpul analizei cerin telor, deoarece ele facilteaz a
comunicarea dintre membr ii echipei unui proiect si viitorii utilizatori. Acestea ajut a la mentinerea
unei abord ari orientate spre utilizator in dezvoltarea produsului, intelegand asteptarile si cerin tele
utilizatorilor.
Cazurile de utilizare sunt scrise intr-un limbaj simplu astfel incat . sa poata fi intelese si de
nespeciali sti. Mai mult, cazurile de utilizare nu pun accentul numai pe cerin tele func tionale, dar ele
pot fi utilizate pentru a reprezenta si urm ari si alte cerin te de utilizabilitate, fiabilitate, performan ta si
supor tabilitate.
3.1.3 Diagrame de clase
O clas a reprezint a descrierea unui grup de obiecte care au propriet ati (atribute),
comportament si relatii cu alte obiecte.
Clasele sunt sabloane de creare a obiectelor, fiecare obiect fiind o instan ta a unei clase.
Obie ctele vor avea o valoare pentru atributele definite de clas a si accesul la opera tiile sale se va
realiza in maniera specificat a de clasa pe care o instantiaz a.
In UML clasele sunt reprezentate sub form a de dreptunghiuri cu trei compartimente:
compartimentu l superior con tine numele clasei , compartimentul din mijloc afi seaza atributele clasei
si compartimentul inferior con tine opera tiile clasei.
Diagramele de clase fac parte din categoria diagramelor statice. Ele descriu structura interna
sistemului informati c prin identificarea claselor, a atributelor si opera tiilor acestora si a rela tiilor
dintre clase. Construc tia diagramelor de clase are loc in faza de elaborare a sistemului informatic ,
fiind cele mai importante din aceasta faza.
Objectory introduce 3 tipu ri de clase (marcate in UML ca stereotipuri) :
Clase entit ati (sau clase domeniu). Ele reprezint a nucleul unei aplica tii, re tin informa tii
legate de entit atile persistente si captureaz a serviciile ce conduc majoritatea interac tiunilor
din aplica tie.
Clase de interfa ta (sau clase view) . Ele reprezint a grani ta dintre actorii care doresc s a
interac tioneze cu aplica tia si clasele entitate. Majoritatea sunt componente ale interfe tei
utilizator.
Clase de control ( sau clase controller). Ele coordoneaz a activitate a in interiorul aplica tiei.
Fiecare caz de utilizare trebuie sa aiba cel putin o clasa controller.
3.1.4 Diagrame de interactiune
Diagramele de interactiune sunt modele ce reprezinta fluxul de mesaje din sistem. Un mesaj
reprezinta o specificatie de comuni care intre obiecte. O diagrama captureaza comportamentul unui
singur caz de utilizare. Exista doua tipuri de diagrame de interactiune: de secvent e si de colaborare.
Diagramele de secvente sunt utilizate pentru a ilustra fluxul cronologic de mesaje. In
diagrama de secvente, obiectele sunt reprezentate de -a lungul axei orizontale, iar mesaje se
reprezinta in ordine cronologica pe axa verticala.
9 Diagramele de colaborare pun accent pe organizarea obiectelor care participa la interactiune,
aratand modul de relat ionare a lor fara ca timpul sa fie explicit reprezentat. Elementele de baza ale
diagramelor de interactiune sunt: obiectul, legatura si mesajul.
Obiectul reprezinta o entitate carui a i se poate aplica un set de operatii. In plus un obiect
poate avea o star e care pastreaza efectele acestor operatii. Un obiect se reprezinta intr -un dreptunghi,
iar numele obiectului se specifica dupa sintaxa numeObiect: numeClasa. Se poate omite numele
obiectului sau clasei, dar se prefera reprezentarea numeClasa. Mesajul repr ezinta o specificare a unei
intructiuni/comenzi executabile, mai exact a unei metode cu parametri. Acesta se reprezinta cu o
sageata cu sensul de transmitere a mesajului.
Diagrama de secvente arata interactiunea cronologica a obiectelor. Elementele compone nte
ale diagramei de secvente sunt: obiectul, linia vietii, mesajul, conditia, iteratia, return, stergerea. Un
mesaj trimis de un obiect lui insusi, auto -delegare, se reprezinta printr -o sageata intoarsa, iar daca
apelul este recursiv, se reprezinta inca o linie de viata suprapusa ce indica o dubla activare.
Intr-o diagrama de secvente, decizia se reprezinta printr -o conditie intre paranteze drepte
inaintea mesajului si indica generarea mesajului doar daca conditia specificata este adevarata.
Mesajele se po t executa paralel si se reprezinta prin *|| inaintea numelui.
Un mesaj de return indica un raspuns la un mesaj receptionat si specifica ca mesajul nu este
nou. Se reprezinta printr -o sageata formata din linie punctata.
Un obiect este sters cand nu mai este necesar in sistem. Stergerea se reprezinta cu un X in
capatul de jos al liniei de viata a unui obiect.
Diagrama de colaborare arata cum obiectele sunt conectate in sistem si folosite pentru a
comunica aspecte structurale ale sistemului. Elementele diagram ei de colaborare sunt: obiectul,
mesajul, numarul de secventa, auto delegarea, conditia si iteratia.
Obiectele sunt reprezentate ca in diagrama de secvente intr -un dreptunghi cu numele
specificat in formatul numeObiect: numeClasa. Mesajele sunt reprezentat e de sageata, nume cu
parametri si numar de secventa ce indica fluxul din sistem. Auto -delegarea, se reprezinta printr -un
arc in acelasi obiect . Decizia si iteratia se specifica ca in diagramele de secventa: * pentru iteratie si
[conditie] pt decizie [4][5].
3.2 Analiza cerintelor software
Scopul aplicatiei MPF este acela de a ajuta un utilizator al acesteia sa gaseasca drumul intr –
un oras, cunoscut sau necunoscut, plecand de la o intersectie initiala, considerata sursa, la o alta
intersectie a aceluiasi o ras, considerata destinatie.
Actorii care pot interactiona cu sistemul software sunt user -ul si administratorul. User -ul nu
poate afecta functionalitatea sistemului, acesta putand efectua numai interogari asupra lui, fara
drepturi de modificare.
3.2.1 Obi ective si interese
Fiecare utilizator foloseste aplicatia cu un anumit scop definit printr -un drept de utilizator.
Pentru a intelege exact functionalitatea fiecarui tip de utilizator, vom defini intersectia a doua strazi
A si B acea zona dintr -un oras care apartine atat strazii A, cat si strazii B. Doua strazi se pot
intersecta intr -un singur punct.
De asemenea, prin cont vom intelege ansamblul format dintr -un nume unic identificat si o
parola, ce permite accesul la unul sau mai multe module ale aplicatiei. Un cont are atasat un drept de
utilizator ce este setat de catre administrator si poate fi user sau administrator.
10 User -ul utilizeaza principala functionalitate a sistemului, aceea de orientare intr -un oras. El
se aboneaza la serviciul ce ii va permite f olosirea modulului client al aplicatiei, primind un user si o
parola pentru autentificare. Pentru a utiliza sistemul, el trebuie sa s tie orasul in care se afla, cat si cea
mai apropiata intersectie aflata de pozitia lui curenta. De asemenea, este necesara si cunoasterea
destinatiei, definita tot ca o intersectie a doua strazi dintr -un oras. User -ul va f olosi aplicatia de pe
telefonul mobil pentru a stabili drumul ce trebuie parcurs intre sursa si destinatie.
Administratorul elibereaza conturi si se ocupa cu introducerea si verificarea datelor in/din
modulul de gestiune a persistentei. El este cel care introduce si verifica orasele in care modulul
client al aplicatiei va fi functional, si pentru fiecare oras in parte introduce si verifica strazile si
intersec tiile ce apartin acelui oras. Deoarece sistemul necesita acesta informatie, administratorul va
trebui sa introduca si distantele intre oricare doua intersectii consecutive ale unui oras.
Administratorul poate elibera noi conturi de acces in sistem, atat cu drept de administrator,
cat si de user, sau poate modifica/sterge conturile deja existente.
3.2.2 Cerinte functionale
Pentru a putea indeplinii functiile dorite, sistemul trebuie sa indeplineasca anumie cerinte.
Pentru actorul Administrator, sistemul tr ebuie sa permita ca toate functiile din paragraful
3.2.1 sa fie disponibile. Astfel, sistemul trebuie sa permita administratorului autentificarea in sistem
cu un nume de utilizator si parola, pentru ca doar un utilizator valid sa poate folosi functiile
sistemului.
Deoarece aplicatia este una distribuita, n -tier, e posibil ca setarile necesare sistemului sa se
modifice pe diferite calculatoare. De aceea, sistemul va permite administratorului sa configureze
toate datele necesare conecarii la modulul de gesti une a persistentei.
Pentru administrarea oraselor, sistemul va afisa atat orasele disponibile pentru a putea fi
modificate/sterse, dar va permite si introducerea de noi orase. Pen tru introducerea unui nou oras
sistemul va cere numele acelui oras si fisier ul harta (de tip grafic) ce va fi folosit pentru
administrarea drumurilor si intersectiilor.
Pentru administrarea drumurilor, sistemul va cere in primul rand orasul ce se vrea a fi
administrat si fisierul -harta ales la introducerea orasului. Cu aceste inf ormatii, el va afisa harta la
detalii maxime si va permite introducerea de noi intersectii si drumuri sau modificarea/stergerea
celor existente. Pentru o intersectie se poate specifica in mod optional un nume, iar pentru un drum
elementele obligatorii sunt nomenclatura, denumirea drumului si lungimea acestuia. Sistemul va
permite si operatia de salvare a datelor introduse. In urma acestei operatii noile date sunt accesibile
atat administratorilor, cat si user -ilor.
Pentru administrarea utilizatorilor din s istem sunt disponibile trei operatii: adaugarea unui
nou utilizator, afisarea tuturor utilizatorilor si cautarea unui utilizator. Pentru adauga, sistemul va
afisa un formular in care va cere introducerea atat a datelor personale despre noul utilizator (num e,
prenume, adresa, numar telefon etc), cat si informatii despre contul acestuia: nume de utilizator,
parola si tipul utilizatorului. Afisarea tuturor utizatorilor va afisa o lista ce cuprinde toti utilizatorii
din sistem, indiferent de tipul acestora. Sis temul va permite selectarea utilizatorului dorit din lista si
va furniza informatii despre acesta, facand posibila si editarea sau stergerea lor. Cautarea unui
utilizator se poate face dupa numele de utilizator sau dupa numele si prenumele acestuia.
Pentru actorul User, sistemul va permite in primul rand alegerea orasului pentru care doreste
sa efectueze cautarea unui drum. Apoi, sistemul va stabili pozitia initiala a acestuia, cerand o
intersectie formata din doua strazi ce se intersecteaza intr -o zona a propiata de pozitia utilizatorului.
Dupa confirmarea intersectiei sursa, prin acelasi procedeu se va stabili intersectia destinatie. Odata
11 confirmata si aceasta, sistemul va calcula si va afisa drumul ce trebuie parcurs pentru a ajunge din
intersectia surs a in cea destinatie. Pentru mai multe informatii, sistemul va face disponibila si o
reprezentare grafica a acestui drum.
3.2.3 Cerinte nefunctionale
Vom prezenta acum cerintele nefunctionale necesare pentru fiecare modul in parte al
sistemului.
Modulul c lient este scris in Java, folosind platforma Java 2 Platform, Micro Edition (J2ME),
si va rula pe orice telefon compatibil J2ME ce include API -ul pentru conectarea la servicii web.
Telefonul pe care ruleaza aplicatia trebuie sa posede o conexiune la intern et mobil prin GPRS/3G
pentru ca aplicatia sa poata fi utilizata.
Modulul server este un serviciu web ASP .NET (ASP .NET Web Service) scris in C# care
ruleaza pe un calculator Windows, sub un server HTTP (de ex. IIS4, inclus in Windows XP
Professional). El va fi accesat in mod transparent de catre modulul client prin intermediul retelei
internet si se va ocupa cu procesarea propriu -zisa a datelor. Comunicarea intre serviciul web si
clientul de pe telefon se va face prin protocolul SOAP, folosind mesaje HTTP .
Modulul de administrare va rula pe un calculator Windows, sub forma unei aplicatii de sine
statatoare. Este obligatorie instalarea a Microsoft .NET Framework 2.0 pentru ca aplicatia sa poata fi
rulata. Modulul d e administrare este scris in C# si cuprind e interfete grafice (GUI) pentru
interactiunea cu utilizatorul.
Modulul de gestiune a persistentei va rula pe un calculator Windows, folosind serverul de
baze de date Microsoft SQL Server 2005. Interogarile in baza de date se vor face folosind proceduri
stocate.
3.2.4 Atributele sistemului
Pentru a satisface cerintele din domeniul IT din ziua de azi, aplicatia MPF va cuprinde
urmatoarele atribute de functionalitate:
Mobilitate
Modulul client al sistemului poate fi rulat pe orice telefon mobil ce suporta a plicatii J2ME,
eliminandu -se astfel dependenta de un dispozitiv fix, cum ar fi un PC.
Usurinta in utilizare
Un utilizator obisnuit nu trebuie sa posede cunostinte avansate pentru a rula aplicatia.
Interfata este sugestiva, iar interactiunea cu utilizatorul este minima.
Performanta
Aplicatia este conceputa in asa fel incat modulul client sa efectueze calcule minime,
deoarece s -a tinut cont de la inceput de puterea mica de procesare a telefoanelor mobile.
Procesarea va fi facuta de un calculator server, pe ca re modulul client il va accesa in mod
transparent pentru utilizator.
Usurinta in administrare
Adminstrarea aplicatiei se face in mod visual, prin elemente grafice sugestive, ce faciliteaza
buna functionare a sistemului.
Siguranta
Aplicatia va verifica toat e datele introduse pentru a preveni introducerea eronata din cauza
greselilor umane de operare. De asemenea, aplicatia va fi disponibila non -stop atat pentru
4 Internet Information Services este un server inclus in Windows XP ce ofera servicii de FTP, SMTP si HTTP/HTTPS
12 administratori, cat si pentru user -i. In cazul unei erori sau a unei intreruperi a aplicatiei,
integritatea modulului de gestiune a persistentei nu va fi compromisa si nicio informatie nu
va fi afectata de intrerupere.
3.3 Dezvoltarea sistemului
Pentru a proiecta in mod eficient sistemul vom utiliza modelul de proces software iterativ si
incremental de dezvoltare.
Modelul incremental este modelul RUP in care se realizeaza parti ale sistemului (o functie,
un grup de functii), utilizandu -se un ciclu in cascada. Metodologia ciclica presupune ca in fiecare
faza se consuma un timp mai scurt, dupa care urm eaza iteratii prin toate fazele. Ideea care sta la
baza acest ui model este gandirea unei parti a problemei, planificarea acesteia, proiectarea ei,
implementarea si testarea. Dupa aceasta faza, procesul se reia pentru urmatoarea parte a sistemului.
Pe masur a ce procesul inainteaza, sunt generate din ce in ce mai multe detalii ale sistemului.
In final, in urma acestui ciclu repetitiv, odata cu finalizarea tuturor partilor sistemului,
produsul poate fi considerat finit.
In continuare vom aborda proiectarea s i implementarea sistemului MPF intr -o maniera
ciclica. Vom prezenta cateva cazuri de utilizare ale sistemului, vom arata diagramele de secvente si
de clase pentru aceste cazuri, vom implementa partea prezentata, vom testa, dupa care vom repeta
ciclul pana la finalizarea aplicatiei.
3.3.1 Administrarea intersectiilor
Caz de utilizare: Administrarea intersectiilor
Nume : Administrarea intersectiilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa efectueze operatii de adaugare/modificare asupra intersectiilor
definite in cadrul modulului de administrare
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras introdus in
sistem
Postconditii : sistemul a efectuat o peratiile cerute
Flux principal :
Administrator Sistem
1. Alege un oras din lista de orase
disponibile.
3. Alege una din optiunile “Adauga
Intersectii” sau “Editeaza”.
2. Incarca toate datele salvate anterior
pentru orasul respectiv. [ E1]
13
4. In functie de optiunea aleasa se executa
cazul de utilizare “Adaugarea
intersectiilor” sau cazul de utilizare
“Modificarea intersectiilor” sau cazul de
utilizare “Stergerea intersectiilor”.
Fluxuri de eroare :
[E1]: conexiunea cu baza de date esueaza. In a cest caz optiunea de salvare a datelor va fi
dezactivata.
Cazurile de utilizare Adaugarea intersectiilor, Modificarea intersectiilor si Stergerea
intersectiilor extind cazul de utilizare Administrarea intersectiilor . Aceasta relatie este prezentata in
diagrama de mai jos.
Administrarea intersectiilor
Adaugarea intersectiilor
Modificarea intersectiilorStergerea intersectiilor<<extend>>
<<extend>><<extend>>
Figura 3.3.1 1. Diagrama cazurilor de utilizare
Caz de utilizare: Adaugarea intersectiilor
Nume : Adaugarea intersectiilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa adauge o noua intersectie
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras introdus in
sistem
Postconditii : sistemul a adaugat noua intersectie
Flux principal :
14
Administrator Sistem
1. Alege optiunea “ Adauga intersectie .
3. Alege locul in care doreste sa adauge
noua intersectie.
2. Seteaza starea curenta ca fiind cea de
adaugare de intersectii.
4. Memoreaza noua intersectie si o
reprezinta vizual.
Avand pasii acestui caz d e utilizare, putem continua prin a desena diagrama de secvente
pentru cazul de utilizare “ Adaugarea intersectiilor ”.
Pentru a crea diagrama acestui caz de utilizare, va trebui mai intai sa introducem urmatoarele
clase cu responsabilitatile lor:
Administrar eDrumuri si AdministrareDrumuri Controller: reprezinta interfata grafica ce
interactioneaza cu utilizatorul si controller -ul acesteia, responsabil cu tratarea
evenimentelor
Intersectie: reprezinta abstractizarea obiectului “Intersectie” ce va fi adaugat de catre
administrator
ListaIntersectii: reprezinta lista in care vor fi memorate toate intersectiile din sesiunea
curenta
Avand aceste clase, rezulta diagrama de secvente pentru cazul de utilizare “ Adaugarea
intersectiilor ”.
15
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerlpp :
LargePicturePanellpp :
LargePicturePaneli : Intersectiei : Intersectie li :
ListaIntersectiili :
ListaIntersectiiliv : Listaliv : Lista
1: adaugaIntersectie( )
2: getInstance( )
3: adaugaIntersectie(Integer, Integer)
4: creaza(Integer, Integer)
5: redeseneaza( )
6: getIntersectiiVizibile(Rectangle)
7: creaza( )
9: return Lista8: adauga(Intersectie)
11: afiseaza( )10: redeseneaza( )
12: redeseneaza( )
Figura 3.3.1 2. Diagrama de secvente – C.U. Adaugare a intersectiilor
Pentru a declansa acest caz de utilizare, administratorul trebuie sa aleaga din meniu optiunea
“Adauga intersectie ” si sa execute click stanga de mouse asupra hartii afisate pe ecran, i n pozitia in
care doreste adaugarea unei noi intersectii. Controller -ul ferestrei preia coordonatele in care s -a
executat click -ul si, folosind pattern -ul Creator , executa operatia adaugaIntersectie () asupra
obiectului ListaIntersectii . Aceasta operatie ne asigura ca responsabilitatea adaugarii unei noi
intesectii revine clasei care gestioneaza toate intersectiile.
ListaIntersectii va crea o noua un nou obiect de tip Intersectie , il va adauga in lista din
sesiunea curenta, dupa care va intoarce obiectul co ntroller -ului care a cerut crearea acestuia.
ListaIntersectii foloseste pattern -ul Singleton pentru a asigura faptul ca intotdeauna vom avea o
singura instanta a listei cu care vom lucra.
Controller -ul ferestrei pricipale va cere controller -ului ferestrei care afiseaza harta sa execute
o operatie de redesenare , ca noua intersectie adaugata sa fie vizibile si pe harta. Acesta va intoarce
din ListaIntersectii numai acele intersectii care sunt vizibile pe ecran in momentul cererii, salvand
astfel timpul inuti l de a desena chiar si acele intersectii care nu sunt vizibile.
Avand aceste informatii, putem prezenta diagrama de clase corespunzatoare acestui caz de
utilizare.
16
Figura 3.3.1 3. Diagrama de clase – C.U. Adaugarea interse ctiilor
Pentru a optimiza procesul de redesenare, componenta LargePicturePanel va trebui sa
redeseneze doar acea portiune din harta si acele intersectii care sunt vizibile pe ecran in momentul
cererii. Astfel se va economisi din timpul necesar desenarii intregii suprafete, atat afisate, cat si
neafisate.
Vom prezenta acum un exemplu in C# prin care putem realiza acest lucru:
protected override void OnPaint( PaintEventArgs e)
{
Rectangle src = new Rectangle (-AutoScrollPosition.X, -AutoScrollPosition.Y,
this.Width, this.Height);
Rectangle dest = new Rectangle (0, 0, this.Width, this.Height);
if (imagine == null) e.Graphics.FillRectangle( new
SolidBrush (this.BackColor), dest);
else
{
e.Graphics.DrawImage(imagine, dest, src, GraphicsUnit .Pixel);
17 ListaIntersectii listaInters = ListaIntersectii .getInstance();
ArrayList intersectiiVizibile = listaInters.getIntersectiiVizibile(src);
if (intersectiiVizibile.Count != 0)
{
foreach (Intersectie inters in intersectiiVizibile)
{
if (!inters.EsteVizibila) continue ;
int x = inters.X;
int y = inters.Y;
int raza = inters.Diametru;
int xOnScreen = x + AutoScrollPosition.X;
int yOnScreen = y + AutoScrollPosition.Y;
e.Graphics.FillEllipse( new SolidBrush (inters.Culoare), xOnScreen
– raza / 2, yOnScreen – raza / 2, raza, raza);
}
}
}
base.OnPaint(e);
}
Caz de utilizare: Modificarea intersectiilor
Nume : Modificarea intersectiilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa modifice proprietarile unei intersectii deja existente
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras cu o intersec tie
in sistem
Postconditii : sistemul a executat modificarile cerute
Flux principal :
Administrator Sistem
1. Alege optiunea “ Editeaza ”.
3. Alege o intersectie existenta.
5. Efectueaza modificarile.
2. Seteaza starea curenta ca fiind cea de
editare.
4. Afiseaza o fereastra in care
administratorul modifica proprietatile
intersectiei.
6. Memoreaza modificarile efectuate
asupra intersectiei.
Administratorul va avea posibilitatea sa seteze un nume semnificativ pentru intersectie si sa
vada anumite i nformatii despre aceasta.
Avand pasii acestui caz de utilizare, putem continua prin a reprezenta diagrama de secvente
pentru cazul “ Modificarea intersectiilor ”.
Pentru acest lucru va trebui sa adaugam urmatoarele clase cu urmatoarele responsabilitati:
18 IntersectieForm si IntersectieFormController: reprezinta fereastra ce va fi afisata
utilizatorului si va contine proprietatile intersectiei selectate, respectiv controller -ul
acestei ferestre, care se va ocupa cu gestiunea evenimentelor.
Avand aceste clase ad augate, rezulta diagrama de secvente pentru cazul de utilizare
“Modificarea intersectiilor ”.
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerif :
IntersectieFormif :
IntersectieFormifc :
IntersectieFormControllerifc :
IntersectieFormControllerinters :
Intersectieinters :
Intersectieli :
ListaIntersectiili :
ListaIntersectii
1: editeazaIntersectie(Integer, Integer)
2: getIntersectieAt(Integer, Integer)
3: return Intersectie
4: creaza(Intersectie)
if Intersectie not null
5: setModificari( )6: stergeIntersectie(Intersectie)
7: setProprietati(String, Boolean, Boolean)
8: adaugaIntersectie(Intersectie)9: notify( )
10: redeseneaza( )
Figura 3.3.1 4. Diagrama de secvente – C.U. Modificarea intersectiilor
Pentru a declansa acest caz de utilizare, administratorul trebuie sa aleaga din meniu optiunea
“Editeaza ” si sa efectueze dublu click de mouse asupra unei intersectii. Daca dublul click se va
executa intr -o zona in care nu exista nicio intersectie, sistemul nu va raspunde in nici un fel.
Controller -ul ferestrei principale va lua din ListaIntersectii intersectia care se afla in zona in
care s -a efectuat dublul click. Aceasta intersectie va fi trimisa ca parametru ferestrei
IntersectieForm , care va afisa pe ecran o fereastra in care administratorul va putea efectu a modificari
asupra intersectiei.
La apasarea butonul OK al ferestrei, controller -ul acesteia va sterge din ListaIntersectii
intersectia, va seta noile proprietati acesteia, dupa care o va adauga din nou in lista. Proprietatile
setate depind si de tipul i ntersectiei: daca este din sesiunea curenta sau daca a fost incarcata din
modulul de gestiune a persistente.
Daca intersectia este din sesiunea curenta, adica ea a fost creata de catre administrator si
asupra ei nu s -a efectuat nicio operatie de salvare, atunci sunt modificate doua atribute: cel de
salvare este trecut pe “ adevarat ”, adica intersectia va trebui salvata (inserata) in modulul de gestiune
a persistentei, iar cel de modificare este “ fals”, adica intersectia nu trebuie modificata in modulul de
gestiune a persistentei (deoarece ea nu exista acolo).
19 Daca intersectia este incarcata din modulul de gestiune a persistentei, atunci cele doua
atribute se schimba: cel de salvare este trecut pe “ fals”, deoarece intersectia nu mai trebuie inserata,
ea exis tand deja, iar cel de modificare este “ adevarat ”, ca sistemul sa stie sa modifice atributele
intersectiei la urmatoarea operatie de salvare.
In final, controller -ul ferestrei principale este notificat de modificari (folosind pattern -ul
Observer ) si forteaz a redesenarea ferestrei principale pentru a afisa modificarile efectuate.
Pentru a desena diagrama de clase pentru acest caz de utilizare, va trebuie sa adaugam noi
metoda claselor deja existente, cat si sa cream alte doua clase noi.
Figura 3.3.1 5. Diagrama de clase – C.U. Modificarea intersectiilor
Stiind ca vom reprezenta pe ecran intersectia ca un cerc ce are un centru si o raza, pentru a
verifica daca coordonatele mouse -ul in care s -a executat dublu click apartin sau nu unei intersectii
existente, vom folosi ecuatia cercului:
foreach (Intersectie inters in lista)
{
if (inters.X >= src.X && inters.Y >= src.Y &&
inters.X <= (src.X + src.Width) && inters.Y <=
(src.Y + src.Height))
return inters;
}
return null;
20 Daca gasim o intersectie ce verifica ecuatia cercului cu coordonatele in care s -a executat
dublu click, atunci intoarcem intersectia gasita. Daca nicio intersectie nu verifica ecuatia, intoarcem
null, iar sistemul nu va raspunde.
Caz de utiliz are: Stergerea intersectiilor
Nume : Stergerea intersectiilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa stearga o intersectie deja existenta
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras cu o intersectie
in sistem
Postconditii : sistemul a sters intersectia
Flux principal :
Administrator Sistem
1. Alege optiunea “Editeaza”.
3. Alege o intersectie existenta.
5. Cere stergerea intersectiei.
7. Raspunde la confirmare.
2. Seteaza starea curenta ca fiind cea de
editare.
4. Afiseaza o fereastra in care
administratorul poate modifica proprietatile
intersectiei sau poate cere stergerea
acesteia.
6. Cere confirmarea stergerii.
8. Daca raspuns ul este afirmativ, intersectia
este stersa.
Actiunea de stergere se diferentiaza in functie de tipul intersectiei, si anume daca aceasta a
fost incarcata sau nu din modulul de gestiune a persistentei. Daca intersectia face parte din sesiunea
curenta (in alte cuvinte, nu este incarcata de pe suport fizic si nici nu s -a efectuat asupra ei operatia
de salvare), atunci ea este stearsa direct din memorie.
Daca intersectia face parte din modulul de gestiune a persistentei, atunci ea este setata sa nu
mai fie vizibila pe ecran si sa fie stearsa la urmatoarea operatie de salvare. Cand utilizatorul va cere
salvarea datelor, intersectia va fi stearsa din modulul de gestiune a persistentei. Daca intersectia este
stearsa, dar nu se executa ulterior nicio operatie de salvare, la urmatoarea pornire a aplicatiei
intersectia va fi din nou disponibila (deoarece modificarile nu au fost salvate).
Trebuie sa tinem cont ca, avand aceste noi informatii, container -ul care afiseaza atat harta,
cat si intersectiile, trebuie sa a fiseze doar acele intersectii care au setat pe “adevarat” atributul de
vizibilitate.
De asemenea, daca intersectia face parte dintr -unul sau mai multe drumuri existente, atunci
va trebui sa stergem toate drumurile care contin aceasta intersectie, deoarece un drum care contine o
intersectie nu mai poate fi definit daca acea intersectie nu mai exista.
21 Avand aceste informatii, putem continua prin a descrie diagrama de secvente pentru cazul de
utilizare Stergerea intersectiilor .
Vom diferentia diagrama de se cvente in functie de modul in care a fost creata intersectie: de
catre utilizator sau incarcata din modulul de gestiune a persistentei.
Scenarii
1. Intersectia a fost creata de catre utilizator in sesiunea curenta si nu a fost executata nicio operatie
de salvare asupra ei.
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerif :
IntersectieFormif :
IntersectieFormifc :
IntersectieFormControllerifc :
IntersectieFormControlleri : Intersectiei : Intersectie li :
ListaIntersectiili :
ListaIntersectii
1: editeazaIntersectie(Integer, Integer)
2: getIntersectieAt(Integer, Integer)
3: return Intersectie
4: creaza(Intersectie)
if Intersectie not null
5: sterge( )
6: stergeIntersectie(Intersectie)
7: notify( )
8: redeseneaza( )
Figura 3.3.1 6. Digrama de secvente – Stergerea intersectiilor din sesiunea curenta
Administratorul selecteaza optiunea de Editare din meniu si efectuaeza dublu click asupra
unei intersectii existent e. Sistemul intoarce intersectia gasita la coordonatele mouse -ului unde s -a
efectuat dublu click. Daca nu exista nicio intersectie in acea zona, sistemul intoarce null si nu
raspunde.
Sistemul afiseaza o fereastra care contine proprietatile intersectiei s electate si care contine,
printre altele, si un buton de stergere. Cand administratorul apasa pe butonul Sterge , dupa afisarea
unei ferestre de confirmare, intersectia este stearsa din ListaIntersectii , iar fereastra principala este
anuntata (folosind patt ern-ul Observer) ca sa afiseze modificarile efectuate.
2. Intersectia a fost incarcata din modulul de gestiune a persistentei.
22
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerif :
IntersectieFormif :
IntersectieFormifc :
IntersectieFormControllerifc :
IntersectieFormControllerinters :
Intersectieinters :
Intersectieli :
ListaIntersectiili :
ListaIntersectii
1: editeazaIntersectie(Integer, Integer)
2: getIntersectieAt(Integer, Integer)
3: return Intersectie
4: creaza(Intersectie)
if Intersectie not null
5: sterge( )
6: setEsteVizibila(Boolean)
7: setTrebuieStearsa(Boolean)
8: notify( )
9: redeseneaza( )
Figura 3.3.1 7. Diagrama de secvente – Stergerea intersectiilor din modulul persistent
Pasii se reproduc identic pentru administrator ca si in cazul (1), diferenta aparand insa in
actiunile pe care le face sistemul. Cand se cere stergerea intersectiei, aceasta nu este stearsa din
ListaIntersectii , dar i se seteaza doua atribute: cel de vizibilitat e, care este trecut pe “fals” , deci
intesectia nu va mai fi desenata pe ecran, si cel de stergere, care este trecut pe “adevarat” , pentru ca
sistemul sa stie sa stearga intersectia din modulul de gestiune a persistentei la urmatoarea operatie de
salvare.
Pentru a reprezenta diagrama de clase pentru acest caz de utilizare, va trebui sa adaugam noi
functionalitati claselor existente.
23
Figura 3.3.1 8. Diagrama de clase – C.U. Stergerea intersectiilor
3.3.2 Administrarea drum urilor
Caz de utilizare: Administrarea drumurilor
Nume : Administrarea drumurilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa efectueze operatii de adaugare/modificare asupra drumurilor
definite in cadrul modulului de administrare
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras cu cel putin
doua intersectii in sistem
Postconditii : sistemul a efectuat operatiile cerute
Flux principal :
Administrator Sistem
1. Alege un oras din lista de orase
disponibile.
2. Incarca toate datele salvate anterior
pentru orasul respectiv. [ E1]
24 3. Alege una din optiunile “Adauga
Drumuri” sau “Editeaza”.
4. In functie de optiunea aleasa se executa
cazul de ut ilizare “Adaugarea drumurilor”
sau cazul de utilizare “Modificarea
drumurilor” sau cazul de utilizare
“Stergerea drumurilor”.
Fluxuri de eroare :
[E1]: conexiunea cu baza de date esueaza. In acest caz optiunea de salvare a datelor va fi
dezactivata.
Cazu rile de utilizare “ Adaugarea drumurilor ”, “ Modificarea drumurilor ” si “ Stergerea
drumurilor ” extind cazul de utilizare “ Administrarea drumurilor ”.
Administrarea drumurilor
Adaugarea drumurilor
Modificarea drumurilorStergerea drumurilor<<extend>>
<<extend>><<extend>>
Figura 3.3.2 1. Diagrama cazurilor de utilizare
Caz de utilizare: Adaugare a drumurilor
Nume : Adaugarea drumurilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa adauge un nou drum
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras cu cel putin
doua intersectii in sistem
Postconditii : sistemul a adaugat noul drum
Flux principal :
Administrator Sistem
1. Alege optiunea “Adauga drum”.
2. Seteaza starea curenta ca fiind cea de
adaugare de drumuri.
25 3. Alege o intersectie existenta, care va
reprezenta un capat al drumului.
5. Alege o alta intersectie, care va
reprezenta celalalt capat al drumului. [ A1]
[E1]
4. Retine intersectia aleasa.
6. Adauga un nou drum intre cele doua
intersectii selectate. [ E2]
Flux uri de eroare :
E1: intersectia aleasa este aceeasi cu prima, caz in care sistemul intoarce un mesaj de eroare.
E2: intre cele doua intersectii exista deja un drum, caz in care sistemul intoarce un mesaj de
eroare si nu creaza un nou drum.
Flux alternativ:
A1: administr atorul efectueaza o actiune in afara unei intersectii existente, iar aceasta actiune
va duce la oprirea cazului de utilizare.
Avand pasii acestui caz de utilizare, putem continua prin a desena diagrama de secvanete
pentru cazul de utilizare “ Adaugarea dru murilor ”.
Pentru a crea aceasta diagrama, avem nevoie sa introducem noi clase cu responsabilitatile
lor:
Drum: reprezinta abstractizarea obiectului “Drum” ce va fi adaugat de catre
administrator
ListaDrumuri: reprezinta lista in care vor si memorate toate drumurile din sesiunea
curenta
Avand aceste clase, putem construi diagrama de secvente pentru cazul de utilizare
“Adaugarea drumurilor ”:
26
Figura 3.3.2 2. Diagrama de secvente – C.U. Adaugarea drumurilor
27
Pentru a declansa acest caz de utilizare, administratorul trebuie sa aleaga din meniu optiunea
“Adauga drumuri ”. Initial, el executa un click stanga pe una din intersectiile existente, care va
reprezenta un capat al drumului. Sistemul va re tine aceasta intersectie si va astepta ca utilizatorul sa
aleaga o alta intersectie, care va fi celalalt capat al drumului. Daca administratorul executa click in
afara unei intersectii, atunci operatia de adaugare se anuleaza si cazul de utilizare se opres te.
Dupa alegerea celor doua intersectii sistemul va crea un obiect de tipul Drum si il va adauga
in lista de drumuri, ListaDrumuri (care foloseste pattern -ul Singleton ).
Deoarece nu stim ordinea in care administratorul va alege cele doua intersectii (ca petele
drumului), inainte de a crea drumul, va trebui sa ordonam datele de intrare. Vom dori sa ordonam
cele doua intersectii “de la stanga la dreapta”, sau mai exact drumul sa inceapa cu intersectia cea
mai din stanga si sa se termine cu intersectia cea m ai din dreapta. Daca cele doua intersectii au
aceeasi abscisa, atunci le vom ordona “de sus in jos”, sau mai exact drumul va incepe cu intersectia
cea mai de sus si se va termina cu intersectia cea mai de jos.
Avand acesta presortare, vom putea defini mai usor modul in care vom reprezenta grafic
drumurile intre doua intersectii. Drumurile vor fi desenate pe ecran sub forma unor dreptunghiuri, si
vor utiliza mereu notatiile care apar si in desenul de mai jos:
Figura 3.3.2 3. Reprezentarea grafica a drumurilor
Avand acesta ordine a intersectiilor de inceput si de sfarsit, punctele A si D ale drumului vor
fi mereu in interiorul cercului ce reprezinta intersectia de inceput a drumului, iar punctele B si C in
interiorul cerculu i ce reprezinta intersectia de sfarsit a drumului.
Dupa sortarea celor doua intersectii, trebuie sa ne asiguram ca definim corect punctele A, B,
C si D care vor delimita reprezentarea grafica a drumului. Vom nota centrul primei intersectii cu
(Xi,Yi), dia metrul acesteia cu D i si centrul celei de -a doua intersectii cu (X s,Ys), iar diametrul cu D s.
Aici intalnim doua cazuri:
Cazul 1 . Intersectia de inceput este “mai jos” decat intersectia de sfarsit. ( Y i ≥ Y s )
28
Figura 3.3.2 4. Reprezentarea grafica a drumurilor in cazul Yi ≥ Ys
In acest caz, coordonatele punctelor A, B, C si D vor fi:
A ( Xi + D i / 4, Y i + D i / 4 )
B ( Xs + D s / 4, Y s + D s / 4 )
C ( Xs – Ds / 4, Y s – Ds / 4 )
D ( Xi – Di / 4, Y i – Di / 4 )
Cazul 2 . Intersectia de inceput este “mai sus” decat intersectia de sfarsit ( Y i < Y s )
Figura 3.3.2 5. Reprezentarea grafica a drumurilor in cazul Yi < Ys
In acest caz, coordonatel e punctelor A, B, C si D vor fi:
A ( Xi – Di / 4, Y i + Di / 4 )
B ( Xs – Ds / 4, Y s + Ds / 4 )
C ( Xs + Ds / 4, Y s – Ds / 4 )
D ( Xi + Di / 4, Y i – Di / 4 )
29 Avand atat capetele drumului, cat si punctele care vor defini reprezentarea grafica stabilite,
putem adauga obiectul de tip “Drum” in ListaDrumuri .
Dupa ce drumul este adaugat in lista, controller -ul ferestrei principale cere controller -ului
care afiseaza harta, intersectiile si drumurile sa se redeseneze. Acesta va prelua din ListaDrumuri
doar acele drumuri care sunt vizibile pe ecran in momentul cererii si le va desena folosind punctele
A, B, C si D care au fost definite mai devreme. Un drum este considerat vizibile pe ecran atunci
cand cel putin un capat de -al sau (de inceput sau de sfarsit) este vi zibil pe ecran. Din motive estetice,
este de preferat ca desenarea drumurilor sa se faca inainte de desenarea intersectiilor.
In final, rezultatul va fi afisat administratorului in fereastra principala.
Avand aceste informatii, putem prezenta diagrama de clase corespunzatoare acestui caz de
utilizare.
Figura 3.3.2 6. Diagrama de clase – C.U. Adaugarea drumurilor
30 Vom prezenta codul care face adaugarea unui nou drum si tine cont de algoritmul de
ordonare prezentat mai sus.
public void adaugaDrum( Intersectie inceput, Intersectie sfarsit)
{
Drum drum;
if (inceput == null || sfarsit == null) return;
if (inceput.X == sfarsit.X)
{
if (inceput.Y < sfarsit.Y)
drum = new Drum(inceput, sfarsit);
else
drum = new Drum(sfarsit, inceput);
}
else
{
if (inceput.X > sfarsit.X)
drum = new Drum(sfarsit, inceput);
else
drum = new Drum(inceput, sfarsit);
}
Intersectie i = drum.Inc eputDrum;
Intersectie s = drum.SfarsitDrum;
foreach (Drum d in drumuriVizibile)
{
if (d.InceputDrum.Equals(i) && d.SfarsitDrum.Equals(s))
{
System.Windows.Forms. MessageBox .Show("Exista deja un drum definit
intre cele doua intersectii." ,
"Eroare" , System.Windows.Forms. MessageBoxButtons .OK,
System.Windows.Forms. MessageBoxIcon .Error);
return;
}
}
if (i.Y >= s.Y)
{
drum.A = new Point(i.X + i.Diamet ru / 4, i.Y + i.Diametru / 4);
drum.B = new Point(s.X + s.Diametru / 4, s.Y + s.Diametru / 4);
drum.C = new Point(s.X – s.Diametru / 4, s.Y – s.Diametru / 4);
drum.D = new Point(i.X – i.Diametru / 4, i.Y – i.Diametru / 4);
}
else
{
drum.A = new Point(i.X – i.Diametru / 4, i.Y + i.Diametru / 4);
drum.B = new Point(s.X – s.Diametru / 4, s.Y + s.Diametru / 4);
drum.C = new Point(s.X + s.Diametru / 4, s.Y – s.Diametru / 4);
drum.D = new Point(i.X + i.Diametru / 4, i.Y – i.Diametru / 4);
}
lista.Add(drum);
}
31 Caz de utilizare: Modificarea drumurilor
Nume : Modificarea drumurilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul dores te sa modifice un drum existent
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un drum in sistem
Postconditii : sistemul a efectuat modificarile cerute
Flux principal :
Administrator Sistem
1. Alege optiunea “Editeaza”.
3. Alege un drum existent.
5. Efectueaza modificarile.
2. Seteaza starea curenta ca fiind cea de
editare.
4. Afiseaza o fereastra in care
administratorul modifica proprietatile
drumului.
6. Memoreaza modificarile efectuate
asupra drumului.
Adminis tratorul va trebui sa seteze in mod obligatoriu pentru fiecare drum in parte
nomenclatura acestuia (strada, bulevard, alee), numele strazii din care face parte si lungimea
portiunii de drum selectate. Toate datele sunt obligatorii si drumurile nu vor putea fi salvate in
modulul de gestiune a persistentei pana ce aceste date nu au fost completate pentru fiecare drum in
parte.
Avand pasii acestui caz de utilizare, putem continua prin a reprezenta diagrama de secvente
pentru cazul “ Modificarea drumurilor”.
Pentru acest lucru va trebui sa adaugam urmatoarele clase cu urmatoarele responsabilitati:
DrumForm si DrumFormController – reprezinta fereastra ce va fi afisata
utilizatorului si va contine proprietatile drumului selectat, respectiv controller -ul
acestei fer estre, care se va ocupa cu gestiunea evenimentelor.
Avand aceste clase adaugate, rezulta diagrama de secvente pentru cazul de utilizare
“Modificarea drumurilor”.
32
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerdf : DrumFormdf : DrumForm dfc :
DrumFormControllerdfc :
DrumFormControllerd : Drumd : Drum ld :
ListaDrumurild :
ListaDrumuri
1: editeazaDrum(Integer, Integer)
2: getDrumAt(Integer, Integer)
3: return Drum
4: creaza(Drum)
if Drum not null
5: setModificari( )
6: valideazaDate( )
7: stergeDrumDupaId(Drum)
8: setProprietati(String, String, Float, Boolean, Boolean, Boolean)
9: adaugaDrum(Drum)10: notify( )
11: redeseneaza( )
Figura 3.3.2 7. Diagrama de secvente – C.U. Modificarea dru murilor
Pentru a declansa acest caz de utilizare, utilizatorul trebuie sa aleaga optiunea “Editeaza” si
sa efectueze dublu click pe un drum existent. Controller -ul ferestrei principale preia coordonatele
locului unde s -a efectuat dublu click si intoarce din ListaDrumuri acel drum care contine
coordonatele respective. Daca nici un drum nu indeplineste conditia, atunci metoda intoarce null si
sistemul nu raspunde.
Pentru a intoarce drumul care contine punctul de dublu click, va trebui sa verificam daca ace l
punct se afla in interiorul vreunui drum. Pentru aceasta vom folosi o metoda din geometria
computationala care ne spune daca un punct se afla sau nu in interiorul unui poligon convex.
Fie 3 puncte A, B si C in plan. Aria triunghiului ABC este data de fo rmula:
Daca punctele sunt in ordine trigonometrica, atunci valoarea determinantului din formula
este pozitiva, iar triunghiul se numeste “pozitiv definit”. Daca punctele sunt in ordine invers
trigonometrica, atunci triunghiul se numeste “negativ defin it”, iar valoarea determinantului este
negativa.
33 Drumul este salvat ca un patrulater convex (paralelogram), nu neaparat paralel cu axele de
coordonate. Vom considera un punct M (punctul in care s -a efectuat dublu click) si dorim sa
verificam daca acel pu nct se afla sau nu in interiorul patrulaterului. Vom tine cont si de faptul ca in
momentul adaugarii drumului s -a efectuat o ordonare a punctelor ce il definesc, astfel incat
patrulaterul va fi mereu definit in sens trigonometric.
Figura 3.3.2 8. Verificarea pozitiei unui punct in plan relativ la un patrulater dat
Punctul M se va afla in interiorul patrulaterului ABCD daca triunghiurile MAB, MBC, MCD
si MDA vor fi pozitiv definite.
Odata stabilit drumul cerut, el este tr imis ca parametru clasei DrumForm, care reprezinta
fereastra grafica ce va fi afisata utilizatorului. Aici el are posibilitatea sa seteze (in mod obligatoriu)
nomenclatura drumului (Strada, Bulevard sau Alee), numele sau si lungimea drumului. Implicit
nome nclatura va fi “Strada”, deoarece cea mai mare parte a drumurilor sunt strazi.
Dupa validarea datelor (lungimea sa contina numai cifre si sa fie un numar pozitiv), drumul
este sters initial din lista de drumuri, ii sunt setate noile proprietati (nomenclat ura, denumirea,
lungimea, daca toate datele sunt sau nu completate, daca trebuie salvat si daca trebuie modificat).
Daca toate datele sunt complete (atat denumirea, cat si lungimea sunt completate), atunci drumul va
fi desenat cu o alta culoare, pentru a a tentiona utilizatorul ca acel drum este complet. Operatia de
salvare a datelor in modulul de gestiune a persistentei se va putea efectua abia dupa ce toate
drumurile vor avea datele complete. Daca drumul provine din sesiunea curenta (nu este incarcat din
modulul de gestiune a persistentei), atunci el va fi setat sa fie salvat la urmatoarea operatie de
salvare a datelor. Daca nu, el va fi setat sa fie modificat.
Dupa setarea noilor proprietati, drumul este din nou adaugat in lista de drumuri, iar
controller -ul ferestrei anunta controller -ul ferestrei principale sa forteze redesenarea, pentru a afisa
corect toate drumurile.
Avand aceste informatii, putem prezenta diagrama de clase corespunzatoare acestui caz de
utilizare.
34
Figura 3.3.2 9. Diagrama de clase – C.U. Modificarea drumurilo r
Caz de utilizare: Stergerea drumurilor
Nume : Stergerea drumurilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa stearga un dr um existent
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un drum in sistem
Postconditii : sistemul a sters drumul cerut
Flux principal:
Administrator Sistem
1. Alege optiunea “Editeaza”.
3. Alege un drum existent.
2. Seteaza starea curenta ca fiind cea de
editare.
4. Afiseaza o fereastra in care
35
5. Cere stergerea drumului.
7. Raspunde la confirmare. administratorul are posibilitatea sa stearga
drumul.
6. Afiseaza o confirmare.
7. Daca raspunsul este afirmativ , sterge
drumul.
Actiunea de stergere se diferentiaza in functie de tipul drumul, si anume daca acesta este
incarcat sau nu din modulul de gestiune a persistentei. Daca drumul face parte din sesiunea curenta
(in alte cuvinte, nu a fost incarcat din modu lul de gestiune a persistentei), atunci el este sters direct
din memorie.
Daca drumul face parte din modulul de gestiune a persistentei, atunci el nu este sters direct,
ci este setat sa nu mai fie vizibil pe ecran si sa fie sters la urmatoarea operatie de salvare. Cand
administratorul va cere salvarea datelor, drumul va fi sters si din modulul de gestiune a persistentei.
Daca drumul este sters, dar nu se executa operatia de salvare, la urmatoarea pornire a aplicatiei
acesta va fi din nou disponibil, deoare ce asupra lui nu s -a efectuat operatia de stergere.
Trebuie sa tinem cont ca, avand aceste noi informatii, container -ul ce afiseaza harta,
intersectiile si drumurile pe ecran trebuie sa afiseze doar acele drumuri care au setat pe “adevarat”
atributul de v izibilitate.
De asemenea, dupa stergerea drumului va trebui sa fortam crearea unor noi capete (de
inceput si de sfarsit) ale drumului, capete care nu vor face parte din lista de intersectii existente.
Acest lucru va permite utilizatorului sa poata crea di n nou un drum intre cele doua intersectii care
delimitau drumul sters.
Avand aceste informatii, putem continua prin a descrie diagrama de secvente pentru cazul de
utilizare Stergerea drumurilor.
Vom diferentia diagrama de secvente in functie de modul in care a fost creat drumul: de
catre utilizator sau incarcat din modulul de gestiune a persistentei.
Scenari i.
1. Drumul a fost creat in sesiunea curenta si nu a fost executata nicio operatie de salvare asupra lui.
36
ad :
AdministrareDrumuriad :
AdministrareDrumuriadc :
AdministrareDrumuriControlleradc :
AdministrareDrumuriControllerdf : DrumFormdf : DrumForm dfc :
DrumFormControllerdfc :
DrumFormControllerd : Drumd : Drum ld :
ListaDrumurild :
ListaDrumuri
1: editeazaDrum(Integer, Integer)
2: getDrumAt(Integer, Integer)
3: return Drum
4: creaza(Drum)
if Drum not null
5: sterge(Drum)
6: stergeDrumDupaId(Drum)
7: notify( )
8: redeseneaza( )
Figura 3.3.2 10. Diagrama de secvente – Stergerea drumurilor din sesiunea curenta
Administratorul selecteaza optiunea de editare si efectueaza dublu click asupra unui drum
existent. Sistemul intoarce drumul gasit la coordonatele de mouse in care s -a efectuat du blu click.
Daca nu exista nici un drum in acea locatie, atunci se intoarce null si sistemul nu raspunde.
Sistemul afiseaza o fereastra in care administratorul poate opta pentru stergerea drumului.
Cand se apasa butonul “Sterge”, dupa afisarea unei ferestr e de confirmare, controller -ul ferestrei
cere clasei ListaDrumuri (care foloseste pattern -ul Singleton) sa stearga drumul. Deoarece in cazul
curent drumul nu exista in modulul de gestiune a persistentei, el este sters direct din lista ce contine
toate drum urile.
In final, fereastra principala este anuntata sa execute operatia de redesenare pentru a afisa
modificarile.
2. Drumul a fost incarcat din modulul de gestiune a persistentei.
37
Figura 3.3.2 11. Diagrama de secvente – Stergerea drumurilor din modulul persistent
38 Pasii se reproduc identic pentru administrator ca si in cazul (1), diferenta aparand in
raspunsul sistemului. Cand se cere stergerea drumului, acesta nu este sters din ListaDrumuri, dar i se
seteaza doua atribu te: cel de vizibilitate este setat pe “fals”, deoarece nu dorim sa mai afisam drumul
respectiv pe ecran, si cel de stergere este setat pe “adevarat” pentru ca drumul sa fie sters din
modulul de gestiune a persistentei la urmatoarea operatie de salvare.
Nemaifiind un drum valid, trebuie sa modificam si capetele acestuia, pentru a nu influenta
posibilele noi drumuri ce vor fi adaugate. Astfel, vom crea doua obiecte de tip Intersectie si le vom
seta ca fiind cele doua capete ale drumului sters. Obiectele Inte rsectie nu fac parte din lista de
intersectii, deci nu vor fi reprezentate pe ecran si nici nu vor fi salvate in urma unei operatii de
salvare.
Pentru a reprezenta diagrama de clase pentru acest caz de utilizare, va trebui sa adaugam noi
functionalitati c laselor existente.
Figura 3.3.2 12. Diagrama de clase – C.U. Stergerea drumurilor
39 3.3.3 Salvarea datelor
Caz de utilizare: Salvarea datelor
Nume : Salvarea datelor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa salveze datele introduse/modificate in sistem, legate de intersectii si
drumuri
Preconditii : utilizatorul este autentificat ca administrator si exista date (intersectii sau drumuri ce
trebuie salvate )
Postconditii : sistemul a salvat datele in modulul de gestiune a persistentei
Flux principal :
Administrator Sistem
1. Alege optiunea de salvare a datelor.
2. Cat timp se efectueaza operatia de
salvare, afiseaza o fereastra de asteptare
[E1].
3. Se exe cuta cazul de utlizare Salvarea
intersectiilor .
4. Executa cazul de utilizare Salvarea
drumurilor .
5. Anunta utilizatorul ca operatia de salvare
s-a incheiat.
Flux de eroare :
[E1]: conexiunea cu modulul de gestiune a persistentei s -a pierdut, caz in car e este afisat un
mesaj de eroare.
Cazurile de utilizare “ Salvarea intersectiilor ” si “ Salvarea drumurilor ” extind cazul de utilizare
“Salvarea datelor ”, lucru vizibil si in diagrama de mai jos:
Salvarea datelor
Salvarea intersectiilor Salvarea drumurilor<<extend>><<extend>>
Figura 3.3.3 1. Diagrama caz urilor de utilizare
40 Caz de utilizare: Salvarea intersectiilor
Nume : Salvarea intersectiilor
Descriere : interactiunea dintre administrator si sistem
Actori : sistemul
Scop : se doreste salvarea intersectiilor in modulul de gestiune a persistentei
Preconditii : administratorul executa cazul de utilizare Salvarea datelor, iar modulele de
administrare si gestiune a persistentei sunt functionale
Postconditii : sistemul a salvat intersectiile
Flux principal :
Administrator Sistem
1. Cere salvarea datelor.
2. Salv eaza intersectiile.
Pentru a crea diagrama de secvente, avem nevoie sa introducem noi clase:
ProgressForm: reprezinta o fereastra care contine o bara de progres si anunta utilizatorul ca o
operatie este in curs de desfasurare. Aceasta fereastra va trebui sa fie lansata intotdeauna in
alt fir de executie decat cel curent.
DatabaseManager: reprinza o clasa Singleton care va furniza conexiunea cu modulul de
gestiune a persistentei.
IntersectiiManager: reprezinta clasa ce va comunica cu modulul de gestiune a persistentei si
va face inserarea/modificare/stergerea efectiva a datelor de pe suport fizic.
Avand aceste informatii, putem crea diagrama de secvente pentru cazul de utilizare Salvarea
intersectiilor .
41
Figura 3.3.3 2. Diagrama de secvente – C.U. Salvarea intersectiilor
Pentru a declansa acest caz de utilizare, administratorul trebuie sa aleaga optiunea de salvare
a datelor. Cat timp operatia de salvare se va desfasura, pe ecran va fi afisata o fereastra care va
anunta p rogresul operatiei. Managerul IntersectiiManager preia initial toata lista de intersectii, dupa
care va executa cate o operatie asupra fiecarei intersectii, in functie de atributele acesteia:
Daca atributul “trebuieSalvata” este “adevarat”, atunci intersec tia va fi inserata in
modulul de gestiune a persistentei
Daca atributul “trebuieModificata” este “adevarat”, atunci intersectia exista deja in
modulul de gestiune a persistentei, deci ea va fi modificata pentru a reflecta noile
atribute ale acesteia.
Daca atributul “trebuieStearsa” este “adevarat”, atunci intersectia va fi stearsa din
modulul de gestiune a persistentei.
Dupa incheierea acestor operatii, lista de intersectii va fi stearsa, dupa care intersectiile vor fi
din nou incarcate din modulul de gest iune a persistentei. Pentru fiecare intrare din modulul de
gestiune se va crea cate un obiect de tip intersectie, ii vor fi setate pe rand id -ul, denumirea, cele
doua coordonate ale centrului si faptul ca intersectia nu mai trebuie salvata, dupa care ea va fi
adaugata in lista de intersectii.
42 In final, controller -ul MainWindowController va forta redesenarea ferestrei principale,
pentru a afisa exact ultima stare a intersectiilor.
Diagrama de clase rezultata pentru acest caz de utilizare va fi:
Figura 3 .3.3 3. Diagrama de clase – C.U. Salvarea intersectiilor
Caz de utilizare: Salvarea drumurilor
Nume : Salvarea drumurilor
Descriere : interactiunea dintre administrator si sistem
Actori : sistemul
Scop : se doreste salvarea dr umurilor in modulul de gestiune a persistentei
Preconditii : administratorul executa cazul de utilizare Salvarea datelor, iar modulele de
administrare si gestiune a persistentei sunt functionale
Postconditii : sistemul a salvat drumurile
Flux principal:
Adm inistrator Sistem
1. Cere salvarea datelor.
2. Salveaza drumurile.
Pentru a crea diagrama de secvente pentru acest caz de utilizare, va trebui sa introducem noi
clase cu noi responsabilitati:
DrumuriManager: reprezinta clasa ce va comunica cu modulul de gestiune a persistentei si
va face inserarea/modificare/stergerea efectiva a datelor de pe suport fizic.
Avand aceste informatii, putem crea diagrama de secvente pentru cazul de utilizare Salvarea
drumurilor.
43
Figura 3.3.3 4. Diagrama de secvente – C.U. Salvarea drumurilor
44 Pentru a declansa acest caz de utilizare, administratorul trebuie sa aleaga optiunea de salvare
a datelor. Dupa ce intersectiilor vor fi salvate si inainte ca ele sa fie incarcate, se va executa salv area
drumurilor. Dupa ce drumurile au fost salvate, se va executa pe rand incarcarea intersectiilor din
modulul de gestiune a persistentei, urmata de incarcarea drumurilor. Aceasta ordine ne va asigura ca
in momentul salvarii drumurilor avem lista de inter sectii valida si in momentul incarcarii drumurilor
avem lista de intersectii incarcata de pe suport fizic.
Dupa cererea de salvare facuta catre managerul DrumuriManager, se va prelua initial toata
lista de drumuri. Pentru fiecare drum din lista se va exec uta cate o operatie, in functie de atributele
drumului:
Daca atributul “trebuieSalvat” este “adevarat”, atunci drumul va fi salvat in modulul de
gestiune a persistentei.
Daca atributul “trebuieModificat” este “adevarat”, atunci drumul exista deja in modulu l de
persistenta, deci el va fi modificat.
Daca atributul “trebuieSters” este “adevarat”, atunci drumul va fi sters din modulul de
gestiune a persistentei.
Dupa incheierea acestor operatii, lista de drumuri va fi stearsa, dupa care drumurile vor fi
incarc ate din modulul de gestiune a persistentei. Pentru fiecare intrare se vor lua initial cele doua
capete ale drumului, intersectia de inceput si intersectia de sfarsit, dupa care se va crea un nou obiect
de tip Drum cu aceste doua obiecte. Acestui obiect i s e vor setea urmatoarele proprietati preluate din
modulul de gestiune a persistentei: id -ul, nomenclatura, numele, lungimea, cele 4 puncte care ii
definesc reprezentarea grafica si ca datele sunt complete si drumul nu mai trebuie salvat. In final,
drumul va fi adaugat in lista de drumuri.
Controller -ul MainWindowController va forta redesenarea ferestrei principale, pentru a afisa
exact ultima stare a drumurilor.
3.3.4 Autentificarea utilizatorilor
Caz de utilizare: Autentificarea utilizatorilor
Nume : Aut entificarea utilizatorilor
Descriere : interactiunea dintre utilizator si sistem
Actori : administratorul, user -ul
Scop : utilizatorul doreste sa se autentifice cu scopul de a utiliza functiile sistemului
Preconditii : modulele de administrare, client si gesti une a persistentei sunt functionale
Postconditii : sistemul a autentificat utilizatorul
Flux principal :
Utilizator Sistem
1. Lanseaza aplicatia.
3. Introduce datele cerute de sistem.
2. Cere autentificarea utilizatorului.
4. Verifica datele introduse si autentifica
utilizatorul. [ A1].
Flux alternativ:
A1: datele introduse nu sunt valide, deci sistemul nu autentifica utilizatorul.
45 Diagrama de secvente va diferi in functie de tipul utilizatorului, administrator sau user,
deoarece acestia folosesc platfor me diferite pentru a efectua procesul de autentificare.
Cazul 1. Utilizatorul este Administrator .
Pentru a crea diagrama de secvente pentru acest caz de utilizare, va trebui sa adaugam noi
clase cu noi responsabilitati:
Login si LoginController: reprezin ta fereastra de autentificare ce interactioneaza cu
utilizatorul si controller -ul acesteia, responsabil cu tratarea evenimentelor
LoginManager: reprezinta clasa ce va comunica cu modulul de gestiune a persistentei si va
verifica datele introduse de catre u tilizator
DatabaseManager: reprinza o clasa Singleton care va furniza conexiunea cu modulul de
gestiune a persistentei
SHA1: reprezinta clasa ce se va ocupa cu criptarea parolei inainte ca aceasta sa fie trimisa
spre autentificare
UserCurent: este o clasa Singleton care va retine date despre user -ul autentificat, in cazul
unei autentificari reusite
AppWindow: reprezinta fereastra principala a modulului de administrare, din care se pot
alege toate optiunile disponibile in modulul de administrare
Avand acest e clase, diagrama de secvente pentru cazul in care autentificarea se termina cu
succes va fi:
login : Loginlogin : Login loginCtrl :
LoginControllerloginCtrl :
LoginControllersha1 : SHA1sha1 : SHA1 lm :
LoginManagerlm :
LoginManagerdbMan :
DatabaseManagerdbMan :
DatabaseManager
1: autentifica( )
5: creaza( )2: creaza(String)
3: getStringResult( )
4: return String
6: autentifica(String, String)
7: getInstance( )
8: return dbMan
9: getIdAdministrator( )
10: verificaLogin(String,String)
11: return true
Figura 3.3.4 1. Diagrama de secvente – Autentificarea administratorului
46 Administratorul lanseaza aplicatia, iar sistemul ii cere numele de utilizator si parola pentru
autentificare. Acesta introduce datele si cere validarea lor. Inainte de a valida datele, sistemul
cripteaza parola, aplicand algoritmul de hash SHA -1 parolei, apoi aplicand din nou acelasi algoritm
parolei deja cript ate. Vom aplica de doua ori algoritmul SHA -1 deoarece, daca parola utilizatorului
este mica si nesigura (de ex, 3 litere mici), atunci afland hash -ul, se poate afla parola consultand
unul din generatoarele actuale existente pe Internet. Cand aplicam a doua oara SHA -1, stim sigur ca
rezultatul initial are lungime fixa de 196 biti, indiferent de lungimea initiala a parolei. Astfel, riscul
de a afla parola stiind hash -ul este redus la minim.
Avand numele de utilizator si parola criptata, controller -ul LoginCo ntroller va crea clasa
LoginManager, careia ii va cere validarea datelor. Aceasta, folosind conexiunea oferita de catre
clasa Singleton DatabaseManager, va verifica daca datele introduse de catre utilizator sunt valide
(daca numele de utilizator si parola corespund) si daca user -ul are drept de administrator. Daca toate
conditiile sunt implinite, atunci datele introduse sunt valide, deci sistemul le va trimite clase
UserCurent pentru a retine utilizatorul curent.
In final, LoginController va inchide fereas tra de Login si va afisa fereastra principala a
aplicatiei.
Diagrama de clase rezultata pentru acest caz de utilizare va fi:
Figura 3.3.4 2. Diagrama de clase – Autentificarea administratorului
Cazul 2. Utilizatorul este User
Acest caz de utilizare foloseste platforme diferite, partea client ruland pe un telefon mobil sub
platforma J2ME, iar cea server pe un calculator dedicat, fiind un servi ciu web. Noile clase adaugate
pentru a rezolva acest caz de utilizare sunt:
MPF: reprezinta clasa principala a aplicatiei mobile J2ME
47 LoginControllerM5: este controller -ul care se ocupa cu procesul de autentificare a user -ului
WSProxy: reprezinta o clasa Singleton care face legatura cu serviciul web cu care aplicatia
mobila comunica in timpul utilizarii
Service: reprezinta serviciul web care este invocat de catre aplicatia mobila
LoginControllerWS: reprezinta controller -ul ce are responsabilitatea autentificarii unui
utilizator a serviciului web
LoginManagerWS: reprezinta managerul c e va comunica cu modulul de gestiune a
persistentei
DatabaseManagerWS: reprezinta o clasa Singleton ce detine conexiunea catre modulul de
gestiune a persistentei
UserWS: reprezinta abstractizarea obiectului de tip User
Cand se cere autentificarea, fereast ra principala a aplicatiei mobile J2ME creaza un obiect de
tip LoginControllerM cu numele de utilizator si parola introduse de catre utilizator. Intr -un nou
thread se cere verificarea datelor introduse. Folosing clasa Singleton WSProxy care furnizeaza
legatura cu serviciul web, numele de utilizator si parola sunt trimise pentru autentificare pe partea de
serviciu web. Clasa Service va cere controller -ului LoginController WS sa valideze datele. In
constructor, acesta va cripta parola folosind algoritmul SHA -1 si va cere la randului lui managerului
LoginManagerWS sa acceseze mediul persistent. In cazul in care datele sunt corecte, manager -ul
creaza un obiect de tip UserWS cu id -ul utilizatorului si numele acestuia, dupa care acest obiect este
intors in cascada pana la controller -ul LoginControllerM de pe partea mobila.
Daca datele sunt invalide, atunci managerul va intoarce null. Acest rezultat va ajunge in final
la LoginControllerM, care va cere ferestrei principala sa afiseze un mesaj de eroare.
Sa descriem acum acesti pasi si in cadrul unei diagrame de secvente:
5 Literele “M” si “WS” din terminatia claselor sunt puse pentru a face distinctia in faza de proiectare intre clasele care se
afla pe disp ozitivul mobil sub J2ME si cele din serviciul web ASP .NET. In faza de implementare aceste terminatii pot fi
eliminate.
48
Figura 3.3.4 3. Diagrama de secvente – Autentificarea user -ului
49 Diagrama de clase pentru acest caz de utilizare este:
Figura 3.3.4 4. Diagrama de clase – Autentificarea user -ului
3.3.5 Configurarea conexiunii
Caz de utilizare: Configurarea conexiunii
Nume : Configurarea conexiunii
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul d oreste sa seteze parametrii conexiunii catre modulul de gestiune a
persistentei
Preconditii : modulele de administrare si gestiune a persistentei sunt functionale
Postconditii : sistemul a salvat noii parametri
Flux principal:
Administrator Sistem
1. Lanse aza aplicatia de administrare.
2. Alege optiunea de configurare.
4. Efectueaza modificarile necesare si cere
salvarea acestora.
3. Afiseaza o fereastra in care
administratorul vizualizeaza si
configureaza parametrii conexiunii.
5. Salveaza datele.
50 Inainte de a prezenta diagrama de secvente pentru cazul de utilizare Configurarea conexiunii,
va trebui sa adaugam noi clase cu noi responsabilitati si sa extindem functionalitatea claselor
existente:
Config si ConfigController: reprezinta ferestra de conf igurare ce va fi afisata
administratorului si controller -ul acesteia, responsabil cu tratarea evenimentelor.
AES: aceasta clasa se va ocupa cu criptarea si decriptarea informatiilor care vor fi salvate pe
suport fizic.
Avand aceste noi date, putem reprez enta diagrama de secvente:
Figura 3.3.5 1. Diagrama de secvente – C.U. Configurarea conexiunii
51 Administratorul lanseaza aplicatia si sistemul afiseaza fereastra de Login. Aceasta contine un
buton care va lansa evenimentul de configurare. Controller -ul LoginController va crea noua
fereastra ce va fi afisata.
Setarile pentru conexiunea cu modulul de gestiune a persistentei vor fi pastrate intr -un fisier
XML, sub forma de elemente XML. Deoarece fisierul XML este text si poa te fi citit de alte
persoane, vom cripta informatiile din acesta folosind algoritmul de criptare AES.
Fisierul XML de configurare va fi in formatul:
<?xml version="1.0" encoding="utf -8"?>
<Configurare>
<Conexiune>IkCmZllNjAyE5QrmTx1f2w==</Conexiune>
<Server>We7xGyWl0Fv08p2M9tT3qg==</Server>
<BazaDeDate>7mzBgwAwnGB2r/apvuzTcA==</BazaDeDate>
<NumeUtilizator>undF2npDzH0LmbGxJKPzNg==</NumeUtilizator>
<Parola>+MDVEnpQmOOY50PWioKMIQ==</Parola>
</Configurare>
Contructorul lui LoginController va incerca sa incarce din fisierul XML datele salvate
anterior. Pentru aceasta, el va citi si va decripta fiecare element in parte (tipul conexiunii, adresa
server -ului, numele bazei de date si utilizatorul si parola folosite pentru autentificarea la baza de
date) si il va trimite ferestrei Config, care le va afisa. Daca fisierul nu este gasit sau datele continute
sunt invalide, atunci controller -ul va crea un nou fisier cu setari implicite si il va folosi pe acesta.
Dupa ce toate datele au fost citite, controller -ul LoginController seteaza fereastra Login ca
fiind parinte pentru clasa Config, dupa care ascunde fereastra initiala si o afiseaza pe cea de
configurare. Aceasta contine acum setarile incarcate din fisierul XML.
In momentul in care se cere salvarea datelor , datele introduse de utilizator vor fi din nou din
nou criptate folosind acelasi algoritm, dupa care vor fi salvate in fisierul XML de configurare.
Deoarece managerul DatabaseManager foloseste pattern -ul Singleton, trebuie sa ne asiguram
ca la o noua c erere catre modulul de gestiune a persistentei vom folosi noile date introduse de
administrator, si nu vechile setari. De aceea vom forta ca obiectul DatabaseManager sa devina null,
ca la urmatoarea apelare a acestuia datale sa fie din nou incarcare din fi sierul de configurare.
In final, fereastra de configurare este inchisa si cea de Login este din nou afisata.
Avand aceste informatii, diagrama de clase rezultata va fi:
52
Figura 3.3.5 2. Diagrama de clase – C.U. Configurar ea conexiunii
3.3.6 Administrarea oraselor
Caz de utilizare: Administrarea oraselor
Nume : Administrarea oraselor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa efectueze operatii de adauga re/modificare asupra oraselor definite
in cadrul modulului de administrare
Preconditii : utilizatorul este autentificat ca administrator, iar modulele de administrare si gestiune a
persistentei sunt functionale
Postconditii : sistemul a efectuat operatiile c erute
Flux principal:
Administrator Sistem
1. Alege optiunea de operare asupra
oraselor.
3. Alege una din optiunile de vizualizare a
2. Afiseaza optiunile posibile.
53 oraselor sau introducere a unui oras nou. 4. In functie de optiunea aleasa se executa
cazul de utilizare “Adaugarea oraselor” sau
cazul de utilizare “Modificarea oraselor”
sau cazul de utilizare “Stergerea oraselor”.
Cazurile de utilizare Adaugarea oraselor, Modificarea oraselor si Stergerea oraselor extind
cazul de utilizare Administra rea oraselor.
Adaugarea oraselor
Modificarea oraselorStergerea oraselorAdministrarea oraselor
<<extend>><<extend>><<extend>>
Figura 3.3.6 1. Diagrama cazurilor de utilizare
Caz de utilizare: Adaugarea oraselor
Nume : Adaugarea oraselor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administr atorul doreste sa adauge un nou oras
Preconditii : utilizatorul este autentificat ca administrator, iar modulele de administrare si gestiune a
persistentei sunt functionale
Postconditii : sistemul a adaugat noul oras
Flux principal:
Administrator Sistem
1. Alege optiunea de introducere a unui
oras nou.
3. Introduce numele orasului si selecteaza
fisierul ce contine harta orasului.
2. Cere numele noului oras si un fisier
grafic ce reprezinta harta acelui oras.
4. Memoreaza numele orasului si o
semnatura un ica pentru fisierul harta. [E1]
Fluxuri de eroare :
[E1]: orasul exista deja introdus, caz in care se afiseaza un mesaj de eroare.
54 Avand pasii acestui caz de utilizare, putem descrie diagrama de secvente a acestuia. Pentru
aceasta, va trebui sa introducem noi clase cu noi responsabilitati:
AdminOrase – reprezinta un control ce va fi adaugat in fereastra principala si va contine
optiuni pentru adaugarea unui nou oras sau vizualizarea oraselor existente.
Avand aceste clase, rezulta diagrama de secvente a caz ului de utilizare “Adaugarea
oraselor”:
Figura 3.3.6 2. Diagrama de secvente – C.U. Adaugarea oraselor
Administratorul apasa pe buton “Orase”, moment in care user controller -ul AdminOrase este
incarcat pe fereastra princ ipala. Cand se alege optiunea de adaugare a unui oras nou, se afiseaza in
mod automat doua campuri care permit introducerea numelui noului oras si selectarea unui fisier
grafic ce va contine harta acelui oras.
La cererea de memorare a datelor introduse, s istemul verifica mai intai daca orasul exista
deja. In caz pozitiv, el afiseaza un mesaj de eroare si cazul de utilizare se opreste. Daca orasul nu
exista, atunci sistemul genereaza mai intai o semnatura unica pentru fisierul grafic folosind
algoritmul SHA -1 pentru a asigura ca la operatiile viitoare de adaugare/modificare a drumurilor si
intersectiilor in cadrul orasului se va folosi mereu aceeasi harta.
Sistemul insereaza in modulul de gestiune a persistentei numele orasului si semnatura
fisierului harta , dupa care ascunde componentele care cereau introducerea orasului. Fereastra
principala nu mai trebuie reafisata, deoarece ea a fost afisata pe tot parcursul acestor operatii.
Avand aceste informatii, putem prezenta diagrama de clase corespunzatoare aces tui caz de
utilizare.
55
Figura 3.3.6 3. Diagrama de clase – C.U. Adaugarea oraselor
Caz de utilizare: Modificarea oraselor
Nume : Modificarea oraselor
Descriere : interactiunea dintre administrator si sistem
Actori : adminis tratorul
Scop : administratorul doreste sa modifice numele unui oras deja existent
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin in oras inregistrat in
sistem
Postconditii : sistemul a modificat numele orasului
Flux princip al:
Administrator Sistem
1. Alege optiunea de afisare a tuturor
oraselor.
3. Alege un oras.
5. Alege un nume nou. [E1]
2. Afiseaza toate orasele.
4. Afiseaza detalii despre oras si permite
schimbarea numelui orasului.
6. Memoreaza numele nou.
56 Flux de eroare:
[E1]: exista deja un alt oras cu numele nou ales, caz in care sistemul afiseaza un mesaj de
eroare.
Avand pasii cazului de utilizare, putem descrie diagrama de secvente a acestuia. Pentru
aceasta, va trebui sa introducem noi clase cu noi resp onsabilitati:
AdminToateOraseleForm si AdminToateOraseleFormController – reprezinta interfata
grafica ce va fi responsabila cu afisarea tuturor oraselor existente si controller -ul acesteia,
responsabil cu tratarea evenimentelor.
AdminOraseEditeaza si Admin OraseEditeaza – reprezinta interfata grafica ce va fi
responsabila cu editarea unui oras selectat si controller -ul acesteia, responsabil cu tratarea
evenimentelor.
Oras: reprezinta obiectul ce memoreaza informatii despre un oras
ListaOrase: reprezinta o cl asa de tip Singleton in care se va retine lista curenta de obiecte de
tip Oras.
Avand aceste clase, rezulta diagrama de secvente a cazului de utilizare “Modificarea
oraselor”:
57
Figura 3.3.6 4. Diagrama de secvente – C.U. Mo dificarea oraselor
58 Administratorul alege optiunea de afisare a tuturor oraselor existente. Controller -ul
componentei AdminOrase creaza o noua fereastra de tip AdminToateOraseleForm. La incarcarea
acesteia, controller -ul ei solicita mai intai managerului A dminOraseManager sa preia din modulul de
gestiune a persistentei lista cu toate orasele. Aceasta este salvata in clasa ListaOrase, care foloseste
pattern -ul Singleton.
Dupa incarcare, lista cu toate orasele disponibile este afisata in fereastra
AdminToat eOraseleForm.
La selectarea prin dublu click a unui oras, controller -ul va crea un nou obiect de tip
AdminOrasEditeaza, care este o fereastra grafica ce permite, printre altele, modificarea numelui
orasului ales.
Dupa setarea unui nou nume, managerul Adm inOraseManager verifica mai intai daca mai
exista un alt oras cu acel nume, iar in caz negativ, modifica numele orasului si anunta utilizatorul.
Fereastra care afiseaza toate orasele este fortata sa reincarce lista cu orase pentru a reflecta
modificarile facute.
Avand aceste informatii, putem prezenta diagrama de clase corespunzatoare acestui caz de
utilizare.
Figura 3.3.6 5. Diagrama de clase – C.U. Modificarea oraselor
59 Caz de utilizare: Stergerea oraselor
Nume : Sterg erea oraselor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa stearga un oras existent
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un oras in sistem
Postc onditii : sistemul a sters orasul
Flux principal:
Administrator Sistem
1. Alege optiunea de afisare a tuturor
oraselor.
3. Alege un oras.
5. Cere stergerea orasului.
7. Raspunde la confirmare.
2. Afiseaza toate orasele.
4. Afiseaza detalii despre o ras si permite
stergerea orasului.
6. Cere confirmarea stergerii.
8. In cazul unui raspuns pozitiv, efectueaza
stergerea.
Avand aceste clase, rezulta diagrama de secvente a cazului de utilizare “Stergerea oraselor”:
60
Figura 3.3.6 6. Diagrama de secvente – C.U. Stergerea oraselor
61 Pasii acestui caz de utilizare se reproduc la fel ca cei din cazul Modificarea oraselor, cu
diferenta ca de data aceasta administratorul cere stergerea orasului.
In urma cererii de stergere, ma nagerul AdminOraseManager sterge toate referintele orasului
din modulul de gestiune a persistentei.
Este important de retinut ca, in urma stergerii unui oras, vor fi sterse si toate drumurile si
intersectiile ce faceau parte din orasul respectiv.
Deoarec e tabela Drumuri contine doua legaturi catre tabela Intersectii (pe campurile
IntersectieInceput si IntersectieSfarsit), nu vom putea seta proprietatea “Cascade on delete” din
cauza ciclicitatii. De aceea, o varianta pentru stergerea tuturor informatiilor dorite este executarea
programatica a stergerii. Vom prezenta mai jos un exemplu de procedura stocata care sterge un oras
si toate drumurile si intersectiile ce faceau parte din acel oras, fara utilizarea optiunii “Cascade on
detele”:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER OFF
GO
ALTER PROCEDURE [dbo].[DeleteOras]
(
@IdOras int
)
AS
DELETE FROM Drumuri
FROM Drumuri INNER JOIN Intersectii ON
Drumuri.IntersectieInceput = Intersectii .IdIntersectie
WHERE (Intersectii .Oras = @IdOras)
DELETE FROM Drumuri
FROM Drumuri INNER JOIN Intersectii ON
Drumuri.IntersectieSfarsit = Intersectii .IdIntersectie
WHERE (Intersectii .Oras = @IdOras)
DELETE FROM Intersectii
WHERE Oras = @IdOras
DELETE FROM Orase
WHERE IdOras = @IdOras
Dupa ce stergerea a avut loc , fereastra AdminToateOraseleForm este fortata sa reincarce lista
de orase disponibile, pentru a reflecta modificarile facute.
Deoarece in cadrul cazului de utilizare Stergerea intersectiilor participa toate acelasi clase ca
si in cazul de utilizare Modif icarea intersectiilor, relatiile intre clase sunt aceleasi pentru ambele
cazuri de utilizare.
62 3.3.7 Administrarea utilizatorilor
Caz de utilizare: Administrarea utilizatorilor
Nume : Administrarea utilizatorilor
Descriere : interactiunea dintre adminis trator si sistem
Actori : administratorul
Scop : administratorul doreste sa efectueze operatii de adaugare/modificare asupra utilizatorilor
sistemului
Preconditii : utilizatorul este autentificat ca administrator, iar modulele de administrare si gestiune a
persistentei sunt functionale
Postconditii : sistemul a efectuat operatiile cerute
Flux principal:
Administrator Sistem
1. Alege optiunea de operare asupra
utilizatorilor.
3. Alege una din optiunile de adaugare a
unui nou utilizator sau de cautare/afisare a
utilizatorilor curenti.
2. Afiseaza optiunile posibile.
4. In functie de optiunea aleasa se executa
cazul de utilizare “Adaugarea utilizatorilor”
sau “Modificarea utilizatorilor” sau
“Cautarea utilizatorilor” sau “Stergerea
utilizatorilor”.
Cazur ile de utilizare “Adaugarea utilizatorilor”, “Modificarea utilizatorilor”, “Cautarea
utilizatorilor” si “Stergerea utilizatorilor” extind cazul de utilizare “Administrarea utilizatorilor”.
Adaugarea utilizatorilor
Modificarea utilizatorilor Cautarea utilizatorilorStergerea utilizatorilorAdministrarea utilizatorilor
<<extend>>
<<extend>> <<extend>><<extend>>
Figura 3.3.7 1. Diagrama cazurilo r de utilizare
63 Caz de utilizare: Adaugarea utilizatorilor
Nume : Adaugarea utilizatorilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa adauge un nou utilizator (user sau administrator) in sistem
Preconditii : utilizatorul este autentificat ca administrator, iar modulele de administrare si gestiune a
persistentei sunt functionale
Postconditii : sistemul a adaugat utilizatorul
Flux principal:
Administrator Sistem
1. Alege optiunea de introduc ere a unui nou
utilizator.
3. Introduce toate datele cerute si cere
memorarea acestora.
2. Cere introducerea datelor noului
utilizator: informatii personale despre
acesta (nume, prenume, adresa etc), cat si
un nume de utilizator asociat contului, o
parola si dreptul acesuia (user sau
administrator).
4. Memoreaza datele introduse. [E1]
Flux de eroare:
[E1]: datele introduse sunt intr -un format invalid, caz in care sistemul afiseaza un mesaj de
eroare si cere reintroducerea lor.
Avand pasii aces tui caz de utilizare, putem descrie diagrama de secvente a acestuia. Pentru
aceasta, avem nevoie sa introducem noi clase cu noi responsabilitati:
AdminUsers si AdminUsersController – reprezinta un control care va fi adaugat pe fereastra
principala si va pe rmite efectuarea de operatii de adaugare/modificare/cautare asupra
utilizatorilor si controller -ul acestuia, responsabil cu tratarea evenimentelor.
AdaugaUserForm si AdaugaUserFormController – reprezinta interfata grafica ce va fi afisata
si va permite int roducerea datelor pentru un nou utilizator si controller -ul acesteia,
responsabil cu tratarea evenimentelor.
Persoana – reprezinta abstractizarea obiectului Persoana si memoreaza date personale ale
unei persoane (nume, prenume, adresa etc).
Cont – reprezin ta abstractizarea obiectului Cont si memoreaza date despre numele de
utilizator si parola asociata unei persoane
TipUtilizator – reprezinta abstractizarea obiectului TipUtilizator si memoreaza tipul de
utilizator al unui cont (user sau administrator)
Avand aceste clase, rezulta diagrama de secvente pentru cazul de utilizare “Adaugarea
utilizatorilor”.
64
Figura 3.3.7 2. Diagrama de secvente – C.U. Adaugarea utilizatorilor
65 Administratorul apasa pe butonul “Utilizatori”, moment in care pe pagina principala este
incarcat controllul AdminUsers. Aici el alege optiunea de adaugare a unui nou utilizator si apasa
butonul “Continua”. Controller -ul AdminUsersController creaza un nou obiect de tip
AdaugaUserForm, care in contructorul ei a peleaza metoda getTipuriUtilizatori() a managerului
AdminUserManager pentru a incaraca din mediul persistent toate tipurile de utilizatori disponibile.
Avand aceste date, este afisata o interfata grafica ce permite adaugarea de date personale ale
unei per soane (nume, prenume, adresa, oras, judet, telefon, e -mail), cat si definirea unui nume de
utilizator asociat contului persoanei si o parola pentru acesta. De asemenea, este obligatorie alegerea
unui tip de utilizator asociat contului ce va fi creat.
La cererea administratorului de adaugare a utilizatorului, dupa verificarea datelor introduse
in pagina, se creaza un obiect de tip Persoana. O persoana va avea mereu atribuit un cont, iar un cont
va avea atribuit un tip de utilizator.
Pentru a nu incalca pat tern-ul Creator, trimitem toate datele de pe pagina clasei Persoana,
care va lua datele specifice contului (username si parola) si va crea un obiect de tip Cont. Acesta, la
randul lui, va lua din ListaTipuriUtilizator acel tip de utilizator care i -a fost a tribuit de catre
administrator.
Dupa crearea obiectelor Persoana, Cont si TipUtilizator se cere salvarea acestor obiecte pe
mediu persistent. Pentru acesta vom folosi managerul AdminUsersManager, care va salva in
sistemul de gestiune a persistentei toate datele persoanei si contului asociat.
Din acest moment, contul este activ si poate fi folosit pentru autentificare.
Diagrama de clase asociata acestui caz de utilizare este:
Figura 3.3.7 3. Diagrama de clase – C.U. Adaug area utilizatorilor
66 Caz de utilizare: Modificarea utilizatorilor
Nume : Modificarea utilizatorilor
Descriere : interactiunea dintre administrator si sistem
Actori : administratorul
Scop : administratorul doreste sa modifice datele unui utilizator deja existe nt (user sau administrator)
in sistem
Preconditii : utilizatorul este autentificat ca administrator si exista cel putin un utilizator in sistem
Postconditii : sistemul a efectuat modificarile utilizatorul
Flux principal:
Administrator Sistem
1. Alege optiu nea de afisare a tuturor
utilizatorilor.
3. Alege un utilizator din lista.
5. Efectueaza modificarile dorite si cere
salvarea acestora.
2. Afiseaza lista cu toti utilizatorii existenti.
4. Afiseaza datele complete pentru
utilizatorul ales si permit e modificarea
acestora.
6. Memoreaza modificarile efectuate. [E1]
Flux de eroare:
[E1]: datele introduse sunt intr -un format invalid, caz in care sistemul afiseaza un mesaj de
eroare si cere reintroducerea lor.
Avand pasii acestui caz de utilizare, pu tem descrie diagrama de secvente a acestuia.
67
Figura 3.3.7 4. Diagrama de secvente – C.U. Modificare utilizatorilor
68 Administratorul apasa pe butonul “Utilizatori”, moment in care pe pagina principala este
incarcat controllu l AdminUsers. Aici el alege optiunea de afisare a tuturor utilizatorilor. Controller –
ul ferestrei UsersForm foloseste managerul AdminUserManager pentru a lua din modulul de
persistenta toti utilizatorii disponibili. Dupa incheierea acestei operatii, toti u tilizatorii sunt afisati in
fereastra UsersForm.
Aici administratorul alege utilizatorul dorit, iar sistemul afiseaza o noua ferestra,
ModificaUserForm, ce contine toate datele utilizatorului ales. Administratorul are posibilitatea de a
modifica atat datel e persoanale ale utilizatorului (nume, prenume, adresa etc), cat si datele despre
contul acestuia (nume de utilizator, parola si tip utilizator). La cererea operatiei de salvare, acelasi
manager AdminUserManager updateaza informatiile despre utilizator din mediul persistent.
3.3.8 Identificarea drumurilor dupa nume
Caz de utilizare: Identificarea drumurilor dupa nume
Nume : Identificarea drumurilor dupa nume
Descriere : interactiunea dintre user si sistem
Actori : user
Scop : utilizatorul doreste sa comunice sistemului cele doua drumuri care se intersecteaza pentru a
stabili intersectia sursa sau cea destinatie
Preconditii : utilizatorul este autentificat ca user
Postconditii : sistemul a memorat cel e doua drumuri
Flux principal:
User Sistem
1. Alege orasul i n care doreste sa efectueze
cautarea unui drum.
3. Introduce si trimite numele strazilor
2. Cere introducerea numelui a doua strazi
care se intersecteaza.
4. Intoarce cate o lista de drumuri pentru
fiecare nume de strada introdus. [E1]
Flux de eroare:
[E1]: cel putin una din cele doua strazi nu a fost gasita
1. Sistemul afiseaza un mesaj de eroare.
2. Fluxul continua cu pasul 2 din fluxul principal.
Vom prezenta in continuare diagrama de secvente pentru acest caz de utilizare:
69
Figura 3.3. 8 1. Diagr ama de secvente – C.U. Identificarea drumurilor dupa nume
Utilizatorul completeza numele aproximativ al celor doua strazi care se intersecteaza.
Procedeul va fi acelasi atat pentru ide ntificarea intersectiei sursa, cat si a intersectiei destinatie.
Dupa completarea numelor si trimitea lor catre sistem, controller -ul DrumuriControllerM va lua
instanta clasei WSProxy care face legatura cu serviciul web si ii va cere identificarea celor doua
strazi introduse.
Pentru fiecare strada in parte, proxy -ul va exec uta metoda getDrumuriCuNumele (String,
OrasWS) pe serviciul web. Acesta va pasa mai departe cererea unui controller, care va comunica cu
managerul DrumuriManagerWS pentru a interoga modu lul de gestiune a persistentei.
Trebuie sa tinem cont ca este posibil ca utilizatorul sa nu stie numele complet al strazilor
cautate. De aceea, nu trebuie sa ne rezumam la a intoarce acele drumuri care au numele ales, ci vom
intoarce drumurile care contin numele introdus de utilizator. O procedura stocata care realizeaza
acest lucru este:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER OFF
GO
CREATE PROCEDURE [dbo].[WS_CautaDrumuriCuNumele]
(
@NumeStrada varchar(MAX),
@IdOras int
)
70 AS
SELECT DISTINCT Nomenclatura , NumeStrada
FROM Drumuri INNER JOIN Intersectii ON
Drumuri.IntersectieInceput = Intersectii .IdIntersectie
WHERE Drumuri.NumeStrada like @NumeStrada AND
Intersectii .Oras = @IdOras
Odata intoarse toate drumurile ce satisfac criteriile de cautare, managerul va crea pentru
fiecare intrare cate un obiect de tip DrumWS si il va adauga in vectorul DrumWS[]. Acest vector va
fi returnat in cascada pana la controller -ul DrumuriC ontrollerM al aplicatiei mobile si va contine
intrari valide de drumuri cunoscute de sistem.
3.3.9 Alegerea intersectiei comune
Caz de utilizare : Ale gerea intersectiei comune
Nume : Alegerea intersectiei comune
Descriere : interactiunea dintre user si sistem
Actori : user
Scop : utilizatorul doreste sa stabileasca intersectia sursa sau destinatie a drumului
Preconditii : utilizatorul este autentificat ca u ser si a efectuat identificarea celor doua drumuri a
caror intersectie o doreste
Postconditii : sistemul a memorat intersectia celor doua drumuri
Flux principal:
User Sistem
1. Alege si trimite cele doua drumuri a
caror intersectie va reprezenta sursa sau
destinatia drumului.
2. Memoreaza intersectia celor doua
drumuri. [E1]
Flux de eroare:
[E1]: cele doua drumuri nu se intersecteaza
1. Sistemul afiseaza un mesaj de eroare.
2. Cazul de utilizare se opreste.
Diagrama de secvente foloseste acelasi stil ca si cea precedenta, de intoarcere in cascada a
obiectului de tip IntersectieWS pana in controller -ul care cere stabilirea intersectiei comune,
IntersectiiControllerM. Procedeul de alegere al intersectiei comune este acelasi atat pentru
intersectia sursa , cat si pentru cea destinatie.
Daca nu exista nici o intersectie comuna a celor doua drumuri, atunci managerul
DrumuriManagerWS va intoarce null, iar sistemul va afisa un mesaj de eroare.
Diagrama de secvente pentru acest caz de utilizare este:
71
Figura 3.3.9 1. Diagrama de secvente – C.U. Alegerea intersectiei comune
72 Un aspect important aici este modalitatea in care vom identifica intersectia comuna a doua
drumuri. Avand in verede ca nu stim daca cele doua drumuri se i ntersecteaza in punctul de inceput,
in punctul de sfarsit sau in celelalte doua combinatii, va trebui ca in cadrul procedurii stocate sa
acoperim toate cele patru posibilitati. O procedura stocata care foloseste tabele temporare si rezolva
cu succes aceast a problema este urmatoarea:
set ANSI_NULLS OFF
set QUOTED_IDENTIFIER OFF
GO
CREATE PROCEDURE [dbo].[WS_GetIntersectieComuna]
{
@Nomenclatura1 varchar(50),
@NumeStrada1 varchar(MAX),
@Nomenclatura2 varchar(50),
@NumeStrada2 varchar(MAX),
@IdOras int
)
AS
SELECT IntersectieInceput , IntersectieSfarsit
INTO #ListaIntersectii1
FROM Drumuri INNER JOIN Intersectii ON
Drumuri.IntersectieInceput = Intersectii .IdIntersectie
WHERE Intersectii .Oras = @IdOras AND Nomenclatura =
@Nomenclatura1 AND NumeStrada = @NumeStrada1
SELECT IntersectieInceput , IntersectieSfarsit
INTO #ListaIntersectii2
FROM Drumuri INNER JOIN Intersectii ON
Drumuri.IntersectieInceput = Intersectii .IdIntersectie
WHERE Intersectii .Oras = @IdOras AND Nomenclatura =
@Nomenclatura2 AND NumeStrada = @NumeStrada2
SELECT #ListaIntersectii1 .IntersectieInceput FROM
#ListaIntersectii1 INNER JOIN #ListaIntersectii2
ON #ListaIntersectii1 .IntersectieInceput =
#ListaIntersectii2 .IntersectieInceput
SELECT #ListaIntersectii1 .IntersectieInceput FROM
#ListaIntersectii1 INNER JOIN #ListaIntersectii2
ON #ListaIntersectii1 .IntersectieInceput =
#ListaIntersectii2 .IntersectieSfarsit
SELECT #ListaIntersectii1 .IntersectieSfarsit FROM
#ListaIntersectii1 INNER JOIN #ListaIntersectii2
ON #ListaIntersec tii1.IntersectieSfarsit =
#ListaIntersectii2 .IntersectieInceput
SELECT #ListaIntersectii1 .IntersectieSfarsit FROM
#ListaIntersectii1 INNER JOIN #ListaIntersectii2
ON #ListaIntersectii1 .IntersectieSfarsit =
#ListaIntersectii2 .IntersectieSfarsit
DROP TABLE #ListaIntersectii1
DROP TABLE #ListaIntersectii2
73 3.3.10. Gasirea drumului
Caz de utilizare : Gasirea drumului
Nume : Gasirea drumului
Descriere : interactiunea dintre user si sistem
Actori : user
Scop : utilizatorul doreste sa afle drumul intre sursa si destinatie
Preconditii : utilizatorul este autentificat ca user si a stabilit intersectia sursa si intersectia destinatie
pentru drumul cautat
Postconditii : sistemul a calculat si a afisat drumul
Flux principal:
User Sistem
1. Cere afisarea drumului.
2. Afiseaza drumul ca o succesiune de
strazi si o reprezentare grafica a acestuia.
Avand in vedere ca toate datele despre orase, drumuri si intersectii sunt inregistrare in
modulul de gestiune persistenta, prima idee ar fi aplicarea unui algoritm pentru g asirea drumului
dintr -o procedura stocata, direct in baza de date. Nu ar fi o idee gresita, deoarece ne -ar scuti in
primul rand de timpul necesar transferului tuturor datelor din baza de date in memorie pentru a
aplica un algoritm de cautare programatic si in al doilea rand ar folosi interogari SQL, exploatand
astfel la maxim optimizarile pentru viteza facute de producatorii SGBD -urilor.
Sa oferim o solutie care gaseste drumul intre doua intersectii (sursa si destinatie) folosind o
procedura stocata SQL:
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[WS_GasesteDrum]
(
@IntersectieInceput int,
@IntersectieSfarsit int,
@NrMaximPasi int
)
AS
WITH drum (Destinatie , Pasi, DistantaTotala , Drum)
AS
(SELECT DISTINCT IntersectieInceput , 0, CAST(0 AS float),
CAST(@IntersectieInceput AS VARCHAR(MAX))
FROM Drumuri
WHERE IntersectieInceput = @IntersectieInceput
UNION ALL
SELECT IntersectieSfarsit , departure .Pasi + 1,
departure .DistantaTotala + arrival.Lungime,
CAST(departure .Drum AS VARCHAR(MAX))+ ',' +
CAST(arrival.IntersectieSfarsit AS VARCHAR(MAX))
FROM Drumuri AS arrival
INNER JOIN drum AS departure
74 ON departure .Destinatie = arrival.IntersectieInceput
WHERE departure .Drum NOT LIKE '%' +
CAST(arrival.IntersectieSfarsit AS VARCHAR(MAX))+ '%' )
SELECT *
FROM drum
WHERE Destinatie = @IntersectieSfarsit
ORDER BY DistantaTotala ASC
Procedura de mai sus parcurge in mod recursiv toate drumurile d in baza de date si genereaza
toate drumurile posibile intre intersectia sursa si cea destinatie. Algoritmul se executa intr -un numar
de pasi definit la inceputul sau; cand numarul de pasi este depasit, solutia curenta este abandonata si
se trece la urmator ul pas. Pentru a putea aplica acest algoritm trebuie sa avem stocate drumurile
definite direct (drum de la intersectia A pana la intersectia B), cat si invers (drum de la intersectia B
la intersectia A). Acest lucru este conform cu realitatea, deoarece un drum dintr -un oras poate fi
parcurs in ambele directii de mers.
Tocmai aceasta ultima conditie de definire a drumurilor in ambele sensuri ne va face sa
renuntam la algoritm ul prezentat . Fiind un algoritm recursiv si drumurile putand fi parcurse atat in
mod direct, cat si invers , vor aparea bucle in care algoritmul se va bloca. Daca pentru un numar mic
de pasi (sa zicem 10) algoritmul intoarce toate drumurile existente intre o intersectia sursa si una
destinatie, printre care si cel minim, la un numar mai m are de pasi (de exemplu 20, care raportat la
numarul de intersectii ale unui oras este infim), algoritmul va cicla si solutia nu va mai fi gasita.
Trebuie deci sa gasim alt algoritm eficient pentru a rezolva aceasta problema , deoarece
abordarea prin proce duri stocate SQL a esuat.
Vom apela la algoritmii cunoscuti si vom cauta unul care poate rezolva cu succes cerinta
noastra. De aceea, vom pri vi orasul nostru ca un graf in care intersectiile reprezinta noduri, iar
drumurile sunt arcele dintre noduri. Fiec are arc are un cost, care este de fapt lungimea acelei
portiuni de drum. Dupa cum am precizat mai devreme, arcele pot fi parcurse in ambele sensuri, atat
direct, cat si invers, deci graful este unul neorientat.
Daca am apela la un algoritm de tip Dijsktra , care sa ne intoarca drumul de la un nod al
grafului la toate celelalte noduri, ne -am lovi de aceeasi problema ca si in cazul procedurii SQL.
Avand in vedere ca noi dorim doar drumul optim intre doua noduri alea grafului, si nu intre
oricare doua noduri , vom apela la un algoritm euristic de cautare. Algoritmul ales este A* (A -Star)
si el poate rezolva cu succes problema noatra, si anume gasirea drumului optim de la un nod sursa la
un nod destinatie intr -un graf neorientat. Mai multe detalii despre algori tmul A* sunt in capitolul
urmator, capitol dedicat special acestui algoritm.
3.4 Proiectarea bazei de date
Pentru a proiecta baza de date vom lua in considerare toate datele persistente de care
sistemul are nevoie. Se doreste memorarea pe suport persiste nt a datelor despre utilizatorii
sistemului, despre conturile acestora si despre drepturile de utilizator pe care le au. De asemenea,
pentru a atinge scopul aplicatiei este nevoie de inregistrarea oraselor in care va fi disponibila
aplicatia si a tuturor d rumurilor si intersectiilor pentru acele orase.
Vom prezenta in continuare schema conceptuala MMED a bazei de date care satisface toate
cerintele noastre.
75 Drumuri
Reprezinta multimea drumurilor de interes din orasele introduse. Un drum apartine unui ora s daca
cel putin o intersectie ce delimiteaza drumul apartine acelui oras.
idDrum ↔ NAT(8), total
Nomenclatura → char(50), total
NumeStrada → char(max), total
Lungime → float, total
PunctAx → NAT(4), total
PunctAy → NAT(4), total
PunctBx → NAT(4), total
PunctBy → NAT(4), total
PunctCx → NAT(4), total
PunctCy → NAT(4), total
PunctDx → NAT(4), total
PunctDy → NAT(4), total
IntersectieInceput : DRUMURI → INTERSECTII, total
IntersectieSfarsit : DRUMURI → INTERSECTII, total
Campurile PunctAx, .. , PunctDy vor retine coordonatele necesare reprezentarii grafice a
drumului in cadrul modulului de administrare, iar cele doua intersectii (IntersectieInceput si
IntersectieSfarsit) reprezinta capetele drumului.
Cheia primara a tabelei este idDrum, iar cheia semantica este formata din toate campurile, in
afara de cheia primara.
Intersectii
Reprezinta multimea intersectiilor de interes din orasele introduse.
idIntersectie ↔ NAT(8), total
NumeIntersectie → char(max)
CoordonataX → NAT(4), total
CoordonataY → NAT(4), total
Oras : INTERSECTII → ORASE, total
Campurile CordonataX si CoordonataY reprezinta coordonatele folosite pentru reprezentarea
grafica a intersectiei in cadru l modulului de administrare.
Cheia primara este idIntersectie, iar cheia semantica este formata din toate campurile, in
afara de cheia primara.
Orase
Reprezinta multimea oraselor de interes in care este disponibila aplicatia client.
idOras ↔ NAT(8), tot al
NumeOras ↔ char(max), total
SemnaturaSHA1 → char(max), total
Campul SemnaturaSHA1 reprezinta semnatura SHA -1 a fisierului ce contine harta orasului.
Cheia primara este idOras, iar cheia semantica este NumeOras.
76
Persoane
Reprezinta multimea persoanelo r de interes din sistem.
idPersoana ↔ NAT(8), total
NumePersoana → char(50), total
PrenumePersoana → char(50), total
Adresa → char(max), total
Oras → char(50), total
Judet → char(50)
Telefon → char(50)
Email → char(50)
User : PERSOANE → USERS, total
Chei a primara a tabelei este idPersoana, iar cheia semantica este formata din toate campurile,
in afara de cheia primara.
TipuriUtilizator
Reprezinta multimea tipurilor de utilizatori de interes din sistem.
idTipUtilizator ↔ NAT(8), total
NumeTipUtilizator ↔ char(50), total
Cheia primara este idTipUtilizator, iar cea semantica este NumeTipUtilizator.
Users
Reprezinta multimea conturilor de utilizator de interes din sistem.
idUser ↔ NAT(8), total
Username → char(50), total
Parola → char(50), total
TipUtili zator : USERS → TIPURIUTILIZATOR, total
Cheia primara este idUser, iar cheia semantica este formata din toate campurile, in afara de
cheia primara.
Diagrama entitati -asociatii pentru baza de date prezentata este:
77
Figura 3.4 1. Diagrama Entitati – Asociatii
78 4. Algoritmul A*
A-Star (sau A*) este un algoritm de cautare extrem de competitiv in comparatie cu ceilalti
algoritmi din aceeasi categorie, dar totusi usor de inteles si de implementat. Algoritmii de cautare
sunt fo lositi intr -o vasta gama de contexte, de la inteligenta artificiala pana la analiza lexicala si
sintactica a propozitiilor. De aceea, un algoritm eficient ne permite sa rezolvam cu usurinta un
numar mare de probleme.
Tipul de probleme la care A -Star este cel mai des folosit sunt cele de orientare in spatiu.
Avand o problema data, se reprezinta conditiile initiale ale acesteia ca o stare initiala si scopul
problemei ca o stare finala. Pentru fiecare actiune declansata, se genereaza starea succesorilor pentr u
a reprezenta efectul actiunii. Repetand acest pas, la un moment dat unul din succesorii generati va fi
chiar starea finala, iar calea de la starea initiala la cea finala reprezinta solutia problemei.
A-Star genereaza si proceseaza succesorii intr -o anum ita ordine. De fiecare data cand cauta
pasul urmator, A -Star foloseste o functie euristica pentru a incerca sa aleaga pasul cel mai bun. Daca
functia euristica este buna, A -Star va gasi solutia optima intr -un timp foarte scurt.
Algoritmul utilizeaza doua liste, Open si Closed. In lista Open se pastreaza acele noduri care
trebuie examinate, iar in lista Closed nodurile care au fost deja examinate. Initial, lista Open contine
doar nodul initial, iar lista Closed este vida. Pentru fiecare nod memoreaza valori le obtinute in urma
aplicarii functiilor urmatoare :
g(n) Costul necesar pentru a ajunge din nodul initial in n
h(n) Estimarea, conform functiei euristice, a costului necesar
pentru a ajunge din n in nodul final
f(n) = g(n) + h(n); intuitiv, aceasta este cea mai buna solutie
care trece prin n
Fiecare nod pastreaza de asemenea o referinta catre parintele sau, pentru a putea intoarce
solutia gasita.
A-Star are o bucla principala in care citeste nodul n cu cea mai mica valoare f(n) din lista
Open (in al te cuvinte, nodul despre care se crede ca ar face parte din solutia optima). Daca n este
nodul final, solutia a fost gasita si poate fi afisata parcurgand parintele fiecarui nod, incepand cu cel
final. Altfel, n este eliminat din lista Open si adaugat in l ista Closed. La urmatorul pas se genereaza
toti succesorii posibili pentru n.
Pentru fiecare succesor n’, daca el este deja in lista Closed si are o valoare initiala pentru f
estimat mai mica sau egala cu valoare calculata, se renunta la nodul n’ si se co ntinua (faptul ca n’
se afla in lista Closed inseamna ca deja a fost parcurs). In mod similar, daca n’ este in lista Open si
are o valoare mai mica sau egala pentru f extimat decat cea calculata, se renunta la n’ si se
continua.
Daca nu exista nici o vers iune mai buna a lui n’ in Closed si Open, se elimina n’ din cele
doua liste si se seteaza n ca fiind parinte pentru n’. De asemenea, trebuie sa calculam costul estimat
pentru n’: g(n’) = g(n) + costul necesar de a ajunge din n in n’; h(n’) = estimarea euri stica
pentru a ajunge din n’ in nodul final; f(n’) = g(n’) + h(n’) .
In final, n’ este adaugat in lista Open si bucla se repeta.
Mai jos este prezentat algoritmul A -Star scris in pseudocod :
79 se initializeaza lista Open
se initializeaza lista Closed
se creaza nodul final (nod_final)
se creaza nodul initial (nod_initial)
se adauga nodul initial in lista Open
cat timp lista Open nu este vida
{
se alege nodul n cu cea mai mica valoare f(n)
se adauga n in lista Closed
daca n = nod_final return So lutie(n)
se genereaza toti succesorii n’ pentru nodul n
pentru fiecare succesor n’ al lui n
{
parinte(n’) = n
h(n’) = estimarea euristica pentru n’
g(n’) = g(n) + cost(n, n’)
f(n’) = g(n’) + h(n’)
daca n’ este in Open si f_init(n’) <=f(n’) continua
daca n’ este in Closed si f_init(n’)<=f(n’) continua
elimina n’ din Open si Closed
adauga n’ in lista Open
}
}
return esec.
Succesul A -Star depinde foarte mult de functia euristica aleasa. Pentru fiecare problema in
care se poate aplica A -Star, exista functii euristice bune si functii euristice proaste. O functie buna
va permite algoritmului sa gaseasca solutia optima intr -un timp rapid, una aleasa intr -un mod
nefericit poate creste timpul necesar executiei sau chiar poate o bliga algoritmul sa intoarca solutii
gresite.
Pentru a garanta ca se va gasi solutia optima, functia euristica trebuie sa fie admisibila. Acest
lucru inseamna ca functia nu trebuie sa supraestimeze costul necesar de a ajunge din nodul initial in
cel final .
Un alt aspect este viteza cu care poate fi calculata functia euristica. Cu cat functia euristica
este mai exacta, cu atat sansele ca A -Star sa intoarca solutia optima cresc. In realitate, o functie
euristica perfecta nu este intotdeauna disponibila sau ea necesita prea mult timp pentru ca rezultatul
ei sa fie calculat. Sunt cazuri in care se prefera o functie euristica mai usor de calculat in favoarea
uneia mai exacte, dar mai greu de calculat. De exemplu, in cadrul gasirii drumului in jocuri, nu se
cauta drumul minim intre doua puncte; se prefera cautarea unui drum bun, dar a carui calcul dureaza
mult mai putin decat cel minim.
80 5. Tehnologii folosite
5.1 .NET Framework
Microsoft .NET Framework este o platforma de dezvoltare a aplicatiilor ce permite
dezvoltatorilor sa creeze cu usurinta aplicatii Windows, aplicatii web si servicii web, folosind
diferite limbaje de programare, fara a mai avea nevoie sa se preocupe de probleme de genul
gestiunii memoriei sau lucrului cu procesorul.
La baza . NET sta Common Language Runtime , sau mai simplu, CLR, care este format din
mai multe componente:
Independenta Limbajului
Unul dintre cele mai importante aspecte a .NET Framework este independenta fata de
limbajul de programare folosit. Aplicatiile .NET pot fi scrise folosind diferite limbaje. Cele mai
populare par sa fie C# si VB.NET, dar multe alte limbaje au extensii .NET, cum ar fi Python,
COBOL, etc. Independenta fata de limbaj este obtinuta folosind un limbaj intermediar (Intermediate
Language – IL). Acest lucru inseamna ca, in loc sa fie obtinut cod masina6 in urma compilarii, codul
este compilat intr -un limbaj generic de nivel inalt. Astfel , indiferent de limbajul ales pentru a scrie
codul, in urma compilarii sub .NET acesta devine IL. Cum toate limbajele ajung intr-un final sub
forma IL, runtime -ul trebuie sa inteleaga si sa lucreze doar cu limbajul intermediar, si nu cu limbajul
in care a fost scris codul.
Just-in-Time Compilation
Dupa ce codul este compilat si transformat in limbaj intermediar, acesta este s alvat intr -o
librarie. Cand acea librarie este folosita, CLR preia codul si il compileaza in timp real pentru masina
pe care este rulata. Acest lucru inseamna ca un cod poate fi compilat diferit, in functie de procesorul
si sistemul de operare al masinii p e care ruleaza aplicatia. Totusi, CLR nu compileaza tot codul, ci
doar metodele care sunt apelate. Fiecare metoda este compilata o singura data, astfel incat nu mai
este necesara recompilarea daca se apeleaza o metoda deja compilata.
Gestiunea memoriei
Lucrul cu memoria este principala cauza pentru gaurile de securitate si bug -urile aplicatiilor.
.NET elimina necesitatea lucrului direct cu memoria prin introducerea componentei Garbage
Collector. Sarcina de a sterge obiectele din memorie nu mai este acum a d ezvoltatorului; Garbage
Collector verifica fiecare obiect din memorie si decide daca acesta mai este sau nu util.
Librarii
Daca runtime -ul este fara indoiala cea mai importanta parte a .NET, de unul singur nu ar face
nimic, deoarece nu ar avea ce sa ruleze . Pentru aceasta exista Base Class Library (sau BCL). Acesta
include toate librariile .NET, printre care System, I/O, lucrul cu texte etc. In afara de BCL exista si
Framework Class Library (sau FCL). FCL este o extensie a librariilor .NET si include urmato arele
componente:
ADO.NET
Majoritatea aplicatiilor necesita lucrul cu bazele de date . ADO.NET reprezinta componenta
.NET Framework ce permite accesul la bazele de date si include mai multi provideri impliciti pentru
SQL Server, ODBC, OLEDB si Oracle.
Windo ws Forms
Windows Forms reprezinta metoda .NET Framework de a crea aplicatii desktop. Acesta
reprezinta de fapt un wrapper peste API -ul Windows nativ, acest lucru insemnand ca se poate scrie
6 Codul ce este rulat pe procesor
81 cod pentru o versiune de Windows, iar acesta va rula pe orice vers iune de la Windows 98 SE
incoace. Windows Forms necesita .NET Framework pentru a rula. In alte cuvinte, oricine doreste sa
ruleze o aplicatie Windows Forms, va trebui sa aiba instalat si .NET Framework.
ASP.NET
ASP .NET este o componenta a .NET Framework conceputa special pentru a crea aplicatii
web. Acesta permite scrierea aplicatiilor web fara a folosi un limbaj de scripting, totul putand fi scris
intr-un limbaj suportat de .NET. Deoarece aplicatiile ASP .NET au ca rezultat cod HTML, .NET
Framework nu tr ebuie sa fie neaparat prezent pe partea client. Pe partea server insa, el trebuie
instalat.
Web Services
Ca si restul componentelor .NET, si serviciile web pot si scrise in orice limbaj .NET.
Prima versiune .NET Framework 1.0 a fost lansata pe 13 Februari e 2002, urmata in Aprilie
2003 de un update major, .NET Framework 1.1. La sfarsit lui 2005, odata cu lansarea Visual Studio
2005 si SQL Server 2005, s -a lansat si .NET Framework 2.0, care a adus cu sine numeroase
modificari ale API -ului fata de versiunea 1 .1, un API rescris pentru aplicatiile native, suport complet
pentru procesoarele pe 64 biti, suport la runtime pentru tipurile generice, controale aditionale in ASP
.NET, etc.
Versiunea curenta este .NET Framework 3.0, care este de fapt o extensie a versiu nii 2.0,
adaugand la aceasta patru noi tehnologii: Windows Presentation Foundation (WPF), Windows
Workflow Foundation (WF), Windows Communication Foundation (WCF) si Windows CardSpace.
Nu exista nicio modificare a versiunii componentelor incluse in .NET 3. 0 fata de cele din versiunea
2.0, existand astfel o compatibilitate totala intre cele doua versiuni [6].
Figura 5 1. Structura .NET Framework 3.0
5.2 C#
Limbajul de programare C# (pronuntat C -Sharp) este unul dintre cele mai puternice limbaje
de programare orientate pe obiecte. El a fost dezvoltat de catre Microsoft si lansat ca versiune beta
in anul 2000. Ulterior, Micros oft a lansat diferite versiuni ale limbajului, inclusiv ultima versiune C#
2.0.
C, C++ si Visual Basic 6.0 au dominat industria calculatoarelor in ultimele decenii.
Principalul neajuns al acestor limbaje era ca programatorul pierdea prea mult timp pentru a dezvolta
82 si a lansa o aplicatie. De asemenea, sintaxa limbajelor era diferita, trecerea de la un limbaj la altul
necesitand un timp considerabil de adaptare. Programatorii cautau un limbaj de programare care sa
reduca timpul necesar dezvoltarii unei apli catii, dar in acelasi timp sa obtina o productivitate optima.
Aceste dificultati au fost eliminate odata cu C#, deoarece, ca si celelalte limbaje .NET, urmaresc
CLS-ul (Common Language Specification) si au ca rezultat CLR-ul.
Principalele facilitati ale C # sunt namespace -urile, array -uri multidimensionale,
suprascrierea operatorilor, delegati si atribute. C# permite de asemenea transmiterea parametrilor
prin valoare (“pass by value”) sau prin referinta (“pass by reference”), documentatii XML,
integrarea cu componente COM etc.
Folosind C# se pot dezvolta aplicatii pentru console, aplicatii grafice Windows, aplicatii web
ASP .NET, servicii web ASP .NET, aplicatii web mobile, librarii, controale Windows si aplicatii
pentru smart device -uri [6].
5.3 Servicii Web
Serviciile Web XML reprezinta temelia fundamentala pentru mutarea calculului distribuit pe
Internet. Standardele deschise si axarea catre comunicatii si colaborari intre oameni si aplicatii au
creat un mediu in care serviciile web au devenit platforma de baza pentru integrarea aplicatiilor.
Probabil ca numarul definitiilor existente pentru serviciile web XML este comparabil cu
numarul companiilor care dezvolta astfel de servicii, dar aproape toate definitiile au cateva lucruri in
comun:
Serviciile We b XML expun functionalitati utile pentru utilizatorii Internetului prin
protocolul standard al Web -ului. In cele mai multe cazuri, acest protocol este SOAP.
Serviciile Web XML furnizeaza un mod de a -si descrie interfetele in detaliu, astfel incat sa
permit a utilizatorilor sa creeze aplicatii client pentru consumarea lor. Aceasta descriere este
de obicei un document XML numit document WSDL (Web Services Description Language).
Serviciile Web XML sunt inregistrare astfel incat sa fie gasite rapid de potentiali i utilizatori.
Acest lucru este realizat folosind UDDI – Universal Discovery, Description and Integration.
Principalul avantaj al arhitecturii pe servicii web este ca permite aplicatiilor scrise in diferite
limbaje de programare pe platforme diferite sa co munice intre ele folosind un anumit standard. Daca
acesta promisiune era facuta in trecut si de CORBA, arhitectura bazata pe SOAP aduce o abordare
mult mai simplificata fata de cea din trecut, scazand cu mult bariera pentru standardele
implementarii SOAP. Implementarea SOAP este realizata si sustinuta de marile companii de
software, dar si de dezvoltatori independenti.
Un alt avantaj semnificativ al serviciilor web XML este functionarea acestora cu
protocoalele Web standard – HTTP, XML si TCP/IP. Majoritate a companiilor detin infrastructuri
web, astfel incat costul introduce rii tehnologiilor serviciilor web este mult mai scazut fata de alte
tehnologii similare.
Initial, primele servicii web s -au vrut a fi utilizate ca surse de informatii care pot fi
incorpor ate cu usurinta in cadrul aplicatiilor – aplicatii pentru bursa, vreme, evenimente sportive etc.
Expunerea aplicatiilor existente ca servicii web v a permite dezvoltatorilor sa creeze aplicatii noi,
mai puternice decat cele actuale, avand structura formata din servicii web. O asemenea structura
permite nu numai comunicarea intre clienti si serviciul web, ci si schimbul de date intre doua sau
mai multe servicii web. Astfel, interoperabilitatea aplicatiilor nu va mai fi o problema.
83 SOAP
SOAP reprezinta pro tocolul de comunicare intre serviciile web. El este de fapt o specificatie
care defineste un format XML pentru mesaje. Orice document XML care este formatat cu elemente
SOAP este considerat un mesaj SOAP.
Alte componente ale specificatiei SOAP descriu mod ul in care sunt reprezentate datele unui
program in format XML si cum este folosit SOAP pentru a executa apeluri de proceduri remote
(Remote Procedure Call). Aceste parti optionale ale specificatiei sunt folosite pentru a implementa
aplicatii in stilul RPC , unde un mesaj SOAP ce contine apelul unei metode si parametrii acesteia
este trimis catre un serviciu web, iar server -ul intoarce catre client rezultatul executarii metodei.
SOAP suporta de asemenea aplicatii -document (document -style applications) in car e mesajele sunt
doar un wrapper in jurul unui document XML. Aceste aplicatii sunt foarte flexibile, iar multe
servicii web se folosesc de aceasta flexibilitate pentru a construi servicii dificil de implementat prin
RPC.
Ultima parte a specificatiei SOAP d escrie modul in care trebuie sa arate un mesaj HTTP ce
contine un mesaj SOAP. Aceasta incapsulare HTTP este importanta deoarece protocolul HTTP este
suportat de aproape toate sistemele de operare. Chiar daca aceasta incapsulare este optionala,
aproape toat e implementarile SOAP o suporta, deoarece HTTP este singurul protocol standardizat
pentru SOAP. Din aceasta cauza, exista o conceptie generala gresita ca SOAP are neaparat nevoie
de HTTP. Unele implementari suporta SMTP sau TCP/IP pentru transport, dar apr oape toate
serviciile web XML folosesc si HTTP.
De departe cel mai important aspect al SOAP este ce acesta a fost implementat pe foarte
multe platforme hardware si software. Acest lucru inseamna ca SOAP poate uni intre ele sisteme
disipate, din cadrul ace leiasi organizatii sau din exteriorul ei. Multe alte incercari de integrare a
sistemelor diferite au fost facute in trecut, dar nici unul dintre ele nu s -a bucurat de succesul pe care
il are in ziua de azi SOAP. Explicatia pentru acest lucru este simpla: S OAP este mult mai mic si mai
usor de implementat decat alte protocoale.
WSDL
Un fisier WSDL (Web Services Description Language) este un document XML ce descrie un
set de mesaje SOAP si modul in care aceste mesaje sunt trimise. Deoarece WSDL este document
XML, el este lizibil pentru utilizator, dar de obicei este generat si consumat de o aplicatie.
Faptul ca fisierul WSDL este bazat pe o schema XML inseamna in primul rand ca limbajul
de programare folosit este neutru7, iar in al doilea rand ca descrierea interfetei serviciului web
urmeaza standardele XML, facand posibila accesarea serviciului indiferent de platforma sau limbaj
de programare pe partea client. In afara continutul ui mesajelor, fisierul WSDL defineste si locatia in
care serviciul este disponib il si ce protocol foloseste pentru a comunica. Acest lucru inseamna ca
fisierul WSDL contine toate informatiile necesare pentru a consuma serviciul web.
UDDI
UDDI (Universal Discovery, Description and Integration) este un fel de carte de telefon
pentru servicii web. Asemenea cartii mentionate anterior, cu ajutorul UDDI se pot cauta informatii
despre o companie, se poate obtine o lista a ofertelor acelei companii, se poate contacta o persoana
7 nu conteaza ce limbaj de programare este folosit pentru generarea serviciului web; rezultatul este u n fisier WSDL
84 din cadrul companiei sau se pot obtine orice alte informatii di sponibile. Bineinteles, un serviciu web
poate fi publicat si fara sa fie publicat in UDDI.
O intrare UDDI reprezinta un fisier XML care descrie un business si serviciile oferite de
acesta. Sunt trei elemente pe care trebuie sa le contina o intrare in UDDI : detalii despre compania
care ofera serviciile (nume, adresa contact etc), categoria industriala din care face parte compania si
interfata catre serviciul web, care trebuie sa ofere suficiente informatii pentru ca un dezvoltator sa
poata scrie o aplicatie ce consuma cu succes serviciul web.
Directorul UDDI contine de asemenea cateva modalitati de cautare a unui serviciu necesar
dezvoltarii unei aplicatii. De exemplu, prin UDDI se pot cauta acei provideri care furnizeaza servicii
de localizare geografica. Directorul UDDI va furniza informatii, date de contact, link -uri si detalii
tehnice despre serviciile cautate.
Conform celor mai recente informatii8, odata cu aprobarea UDDI v3.02 ca standard OASIS
in anul 2005, IBM, Microsoft si SAP au evaluat performant ele obtinute de -a lungul timpului de catre
UDDI Bussiness Registry si au determinat ca scopul acestui proiect a fost atins. De aceea, serviciul
de inregistrare/cautare a unui business in cadrul UDDI a fost dezactivat din data de 12 ianurie 2006
[19].
5.4 Java 2, Micro Edition (J2ME)
Limbajul de programare Java a fost initial conceput ca limbaj de programare pentru
consumabile electronice, insa de -a lungul timpului a evoluat intr -un set de tehnologii folosite pentru
a dezvolta aplicatii desktop si server.
Platforma Java 2 contine trei elemente:
Limbajul de programare Java este asemanator din punct de vedere sintactic cu C++, dar
difera fundamental de acesta. In timp ce C++ foloseste pointeri (nesiguri) si atribuie
programatorului responsabilitatea alocari i si dezalocarii memoriei, limbajul de programare
Java foloseste referinte (sigure) ale obiectelor si gestioneaza in mod automat memoria.
Masina virtuala formeaza fundatia platformei Java. Aceasta arhitectura ofera un avantaj
major: masina virtuala poate f i implementata pe diferite sisteme de operare, pentru diferite
componente hardware. In plus, masina virtuala ofera un control asupra aplicatiilor executate,
putand rula cod nesigur intr -un mediu sigur.
Un set de interfete de programare (Application Program ming Interface – API), care ofera
acces la toate functiile necesare unui programator pentru a realiza o aplicatie.
Impreuna, limbajul Java, masina virtuala si API -ul formeaza platforma Java. Mai mult,
platforma Java este conceputa sa suporte o gama larga d e dispozitive hardware, de la smart card -uri
pana la servere enterprise. Astfel, platforma Java cuprinde trei editii:
Java 2 Platform, Standard Edition (J2SE) furnizeaza un mediu de executie (runtime
environment) si un set complet de API -uri pentru aplicat iile desktop si defineste un set de
functionalitati de baza pentru celelalte editii.
Java 2 Platform, Enterpise Edition (J2EE) este o extensie a J2SE ce suporta programare
enterprise scalabila si orientata catre tranzactii si baze de date.
Java 2 Platform, Micro Edition (J2ME) defineste un mediu de executie si un set de API -uri
pentru dispozitivele consumabile si embedded, precum telefoane mobile, PDA -uri sau alte
dispozitive care nu au resursele necesare pentru a suporta J2SE sau J2EE.
8 http://www.uddi.org/find.html
85 Java 2 Micro Edition (J2ME) reprezinta editia Java pentru dispozitivele limitate din punct de
vedere hardware, cum ar fi PDA -uri, telefoane mobile, dispozitive embedded si alte consumabile
electronice. J2ME se axeaza pe dispozitive cu memorie mica (128 Kb) si procesoare mult mai slabe
decat cele cele folosite pentru un calculator desktop obisnuit.
J2ME nu defineste un nou limbaj de programare; el adapteaza tehnologia Java existenta
pentru dispozitivele mobile si embedded. Pentru a se constrange limitarilor dispozitivelor mobil e,
J2ME inlocuieste cateodata API -ul J2SE si adauga noi interfete, dar evolutia J2ME consta in special
in eliminarea partilor inutile din J2SE si J2EE si adagarea de noi facilitati pentru dispozitive mobile.
De fapt, J2ME consta intr -un set de profile . Fie care profil este definit pentru un anume
dispozitiv – telefoane mobile, PDA -uri, cuptoare cu microunde etc. – si consta intr -un set minim de
clase necesare pentru dispozitiv si specificatiile masinii virtuale Java (JVM) ce suporta dispozitivul
respectiv. M asina virtuala specificata intr -un profil nu este neaparat aceeasi cu cea utilizata in Java 2
Standard Edition (J2SE) sau Java 2 Enterprise Edition (J2EE).
Pana acum, Sun a lansat urmatoarele profile:
The Foundation Profile – un profil pentru urmatoarea generatie de consumabile electronice
The Mobile Information Device Profile (MIDP) – un profil pentru dispozitivele mobile, ca
telefoanele mobile, PDA -uri si pagere.
Un profil nu face nimic de unul singur; el doar defineste anumite specificatii. Profilele s unt
implementate printr -o configuratie . Configuratia reprezinta de fapt implementarea unui profil J2ME
pentru un anume dispozitiv (de exemplu, telefon mobil). Configuratiile disponibile sunt:
Connected Device Configuration (CDC) – implementarea profilului Foundation Profile
pentru generatia urmatoare de consumabile si dispozitive embedded.
Connected Limited Device Configuration (CLDC) – implemetarea MIDP pentru dispozive
mobile ca telefoane mobile, PDA -uri etc.
Deoarece fiecare profil defineste un set difer it de librarii Java, nu se poate rula o aplicatie
scrisa pentru un profil pe un dispozitiv care suporta alt profil. De asemenea, nu se poate rula o
aplicatie scrisa in Java 2 Standard Edition sau Java 2 Enterprise Edition pe un dispozitiv care
suporta Java 2 Micro Edition. Pentru fiecare dispozitiv pot fi utilizate doar acele librarii Java incluse
in profilul dispozitivului respectiv.
In figura de mai jos sunt prezentate variantele platformei Java pentru dispozitive electronice:
Figura 5 2. Variantele platformei Java pentru dispozitive electronice
86 Connected Limited Device Configuration (CLDC)
CLDC reprezin ta o configuratie minima J2ME cu restrictii asupra puterii computationale,
durata bateriei, memorie si largime de banda. Aceste limite afecteaza in mod direct tipurile de
aplicatii Java suportate.
CLDC nu necesita multe resurse. CLDC 1.0 suporta dispoziti ve cu procesor pe 16 sau 32 de
biti, cu minim 160 Kb memorie persistenta si cel putin 32 Kb memorie volatila. Puterea consumata
este mica; de obicei, dispozitivele suportate ruleaza pe baterii. Conexiunea la retea suporta de obicei
o viteza mica de transfe r. Componenta principala a acestei configuratii este o masina virtuala Java,
referita in implementare drept K Virtual Machine (KVM). Aceasta masina virtuala elimina cateva
dintre facilitatile masinii virtuale standard J2SE; de exemplu, CLDC nu suporta grup area thread –
urilor.
CLDC defineste configuratia de baza a J2SE si adauga noi clase suportate de dizpozitivele
mobile. In plus, CLDC a introdus un nou pachet, Generic Connection Framework (GCF) –
javax.microedition.io –, pentru a suporta operatiile de intr are/iesire pe dispozitivele a caror
memorie nu permite utilizarea pachetelor java.io.* si java.util.* .
In tabelul de mai jos sunt prezentate pachetele Java incluse in CLDC:
Nume Descriere
java.lang Clasele de baza ale limbajului de programare Java
java.lang.ref (doar CLDC 1.1) Clase care suporta referinte slabe
java.util Clasele utilitare are limbajului Java
java.io Clase pentru operatii de intrare/iesire
javax.microedition.io Suport pentru retea bazat pe Generic Connection Framework
CLDC 1.1 ( JSR9 139) a inlocuit specificatiile origale CLDC 1.0 (JSR 30).
Diferente intre CLDC 1.0 si CLDC 1.1
CLDC 1.0 si CLDC 1.1 sunt foarte similare. Din perspectiva dezvoltatorilor, cele mai importante
modificari sunt probabil operatiile aritmetice c u virgula mobila si suportul pentru referinte slabe. In
lista de mai jos sunt prezentate principalele diferente fata de CLDC 1.0:
A fost adaugat suport pentru virgula mobila
Au fost adaugate clasele Float si Double
A fost adaugat suport pentru referinte sl abe
Clasele Calendar , Date si TimeZone au fost reconcepute pentru a semana mai
mult cu omoloagele lor din J2SE
A fost modificat modul de tratare al erorilor
Thread -urile suporta acum nume, exact ca in J2SE. A fost introdusa metoda
Thread.getName() , iar cla sa Thread are cativa constructori mosteniti din J2SE
Cateva librarii minore au fost adaugate, au fost rezolvate unele bug -uri si s -au
adaugat urmatoarele campuri si metode:
Boolean.TRUE si Boolean.FALSE
9 Java Specification Request – reprezinta documente formale ce descriu specificatii propuse si tehnologii adaugate
pentru platforma Java
87 Date.toString()
Random.nextInt(int n)
String.intern()
String.equalsIgnoreCase()
Thread.interrupt()
Memoria minima necesara a fost modificata de la 160 la 192 Kb, pentru a suporta
operatiile cu virgula mobila.
Profilele CLDC: MIDP si IMP
MIDP -ul (Mobile Information Devide Profile) si IMP -ul (Information Mod ule Profile) sunt
doua profile foarte asemanatoare.
Figura 5 3. Structura MIDP si IMP
MIDP a fost primul profil J2ME si este cel mai matur si mai folosit dintre toate profilele, cu
milioane de utilizari in lume, in special p e PDA -uri si telefoane mobile.
IMP este folosit pentru dispozitive asemanatoare cu cele MIDP, dar cu capabilitati reduse
sau absente legate de interfete grafice: case de marcat, aplicatii industriale sau sisteme de securitate.
Definit pentru prima data in JSR 195, IMP imprumuta toate functionalitatile MIDP, inclusiv API –
urile pentru managementul aplicatiilor, gestiune persistenta si retea. IMP 1.0 este un descendent
direct al MIDP 1.0, excluzand insa API -ul pentru interfete grafice
(javax.microedition.lcdu i).
MIDP 1.0 a fost descris pentru prima data in JSR 37 si este cel mai utilizat profil J2ME.
MIDP 2.0, definit in JSR 118, extinde foarte mult capabilitatile initiale ale profilului. In plus fata de
API-urile originale pentru retea, interfata grafica, p ersistenta locala si ciclul de viata al unui
MIDlet10, MIDP 2.0 aduce cu sine un nou API pentru retea ce suporta socket -uri TCP, datagrame
UDP, conexiuni seriale si conexiuni securizate. De asemenea, au fost adaugate API -uri pentru
politici de securitate, p entru sunet si chiar pentru jocuri. MIDP 2.0 suporta in specificatiile profilului
si mesaje OTA11.
Urmatorul tabel prezinta pachetele disponibile pentru MIDP si IMP 1.0.
10 MIDlet -ul este un program Java pentru dispozitive mobile, ce ruleaza su b J2ME. In general, acestea sunt jocuri sau
aplicatii pentru telefoane mobile.
11 Over -the-air Programming este o metoda de a distribui update -uri pentru soft -urile existente pe telefoanele mobile, ce
cuprind setarile necesare pentru a accesa servicii precu m WAP sau MMS.
88 Nume Descriere MIDP
1.0 MIDP
2.0 IMP
1.0
java.lang Clasele de baza ale MIDP. X X X
java.util Clase utilitare. X X X
java.io Clase folosite pentru operatiile de
intrare/iesire. X X X
javax.microedition.io Suport pentru retea folosind Generic
Connection Framework; include socket –
uri TCP, datagrame UDP, conexiuni
seriale si conexiuni cri ptate. X X X
javax.microedition.lcdui Clase MIDP pentru interfete grafice. X X
javax.microedition.lcdui.game Clase pentru jocuri, precum sprite -uri,
canvas -uri si layere. X
javax.microedition.media Interfete pentru controlul ( Control ) si
redarea (Player ) audio – clase
compatibile cu API -ul pentru Mobile
Media (JSR 135). X
javax.microedition.media.control Clase pentru controlul sunetului
(ToneControl si VolumeControl ) –
clase compatibile cu API -ul pentru Mobile
Media (JSR 135). X
javax.mi croedition.midlet Interfata aplicatiei, cliclul sau de viata si
interactiunea acesteia cu mediul de
executie si managerul aplicatiei. X X X
javax.microedition.pki Clase pentru chei publice folosite pentru
autentificare criptata. X X
javax.microedition. rms Clase pentru lucrul cu date persistente. X X X
Pachete optionale
Pachetele optionale sunt componente foarte importante ale J2ME. Ele pot fi privite ca
extensii ale profile lor originale. Acestea ofera suport in arii restranse de functionalitate ale
dispozitivelor, cum ar fi sisteme de mesaje, multimedia sau servicii de localizare. In acest fel,
profilele se axeaza pe dezvoltarea acelor capabilitati suportate de majoritatea d ispozitivelor, in
schimb ce pachetele optionale dezvolta anumite capabilitati, existente doar pe unele dispozitive.
Toate pachetele optionale J2ME sunt definite de JCP12, devenind astfel API -uri standard.
Dupa cum spune si numele, includerea acestor pachet e este optionala: producatorii dispozitivelor
mobile pot alege daca vor sa includa sau nu pachetele optionale pentru un anumit produs. De
exemplu, un dispozitiv anume MIDP poate avea suport pentru conexiuni Bluetooth13 prin includerea
API-ului Java pentru B luetooth (JSR 82).
5.4.1 Servicii Web J2ME (JSR 172)
Dezvoltat in Java Community Process sub denumirea JSR 172, API -ul J2ME pentru servicii
web (Web Service API – WSA) extinde Java 2 Platform, Micro Edition pentru a adauga suportul
pentru conexiuni catre servicii web. Cele doua pachete ale API -ului ofera doua functionalitati
cruciale pentru conexiunea unui client la un serviciu web: invocarea de metode remote (remote
method invocation) si parsarea XML (XML parsing).
12 Java Community Process este un proces formalizat, infiintat in 1998, prin care orice persoana interesata poate
contribui la dezvoltarea Java. In acest proces sunt propuse JSR -uri, care sunt sau nu adoptate de o comisie JCP
13 Reprezinta o s pecificatie pentru retele wireless; Bluetooth ofera posibilitatea conectarii si schimbului de informatii
intre dispozitive precum telefoane mobile, laptop -uri, PC -uri etc, folosind o conexiune criptata si o frecventa radio libera
la nivel global.
89 WSA este conceput sa lucreze cu profile le de baza J2ME, pe configuratiile Connected
Device Configuration (CDC) sau Connected Limited Device Configuration (CLDC 1.0 sau CLDC
1.1). API -ul pentru invocarea metodelor remote este bazat pe API -ul J2SE (Java API for XML –
based RPC – JAX-RPC 1.1), cu un ele clase RMI14 incluse pentru a satisface dependentele JAX –
RPC. API -ul pentru parsarea XML este bazat pe Simple API for XML, versiunea 2 (SAX2).
Scopul WSA este de a integra suportul pentru invocarea serviciilor web si parsarea XML in
mediul de executie a l dispozitivului, pentru ca dezvoltatorii sa nu fie nevoiti sa includa acest suport
in fiecare aplicatie.
JSR 172 specifica standardele tehnologiei pe partea client pentru a permite aplicatiilor J2ME
consumarea serviciilor remote oferite de servicii web, asa cum arata si figura de mai jos:
Figura 5 4. Consumarea unui serviciu web de catre un dispozitiv mobil
Aceasta arhitectura a serviciilor web are trei elemente:
O aplicatie rezidenta pe dispozitivul mobil, ce suporta WSA, cu acces la retea (internet).
Aplicatia include stub -ul JSR 172 care utilizeaza mediul de executie JSR 172 pentru a
comunica cu reteaua.
O retea wireless ce permite accesul la Internet si protocoalele corespunzatoare pentru
comunicatii si date, incluzand aici protocoale binare, HTTP si SOAP/XML
Un server web ce se comporta ca si producator de servicii, aflat in spatele unui gateway.
Serverul w eb permite accesul la aplicatiile din spatele lui si alte servere din reteaua locala
privata.
Prima versiune a WSA se adreseaza doar consumului de servicii web. Ea nu suporta crearea
si distribuirea de servicii web. Astfel, un dispozitiv J2ME poate fi doar consumator pentru un
serviciu web, dar nu si producator. De asemenea, JSR 172 nu specifica un API pentru descoperirea
serviciilor folosind UDDI15.
Urmatoarea lista descrie caracteristicile JSR 172:
Suporta SOAP 1.1
Suporta orice mediu de transport, ca de e xemplu HTTP 1.1, care poate transmite mesaje
SOAP si are definit protocolul de incapsulare SOAP 1.1
14 Remote Method Invocation
15 Universal Description, Discovery and Integration este un registru independent de platforma, bazat pe XML, pentru
publicarea automata a serviciilor web pe Internet.
90 Suporta intreaga suita de tipuri de date: boolean, byte, short, int, long,
float, double, String , vector de primitive si tipuri complexe (structuri
continan d primitive sau alte tipuri complexe )
De retinut este faptul ca suportul pentru virgula mobila exista doar in aplicatiile bazate pe
CDC sau CLDC 1.1. Sub CLDC 1.0, tipurile double si float sunt mapate ca String .
Suporta reprezentarea literala (Literal) a u nui mesaj SOAP, reprezentand un apel RPC sau un
raspuns.
Nu suporta mesaje SOAP cu atasamente.
Nu suporta handlere pentru mesaje SOAP.
Nu suporta publicarea serviciilor; in alte cuvinte, dispozitivul poate fi doar consumator de
servicii, nu si producator.
Nu suporta descoperirea serviciilor folosind UDDI.
Pentru a reduce folosirea largimii de banda, nu obliga dispozitivul sa faca el insusi codarea
XML [13]-[16].
Urmatorul tabel descrie pachetul JSR 172, derivat din JAX -RPC:
Nume Descriere
javax.microedit ion.xml.rpc Defineste tipurile primitive folosite de catre stub: boolean,
byte, short, int, long, float, double,
String
Defineste tipurile complexe folosite de stub, care sunt tipuri
speciale definite de WSDL: xsd:complextype
Defineste tipurile Element , folosite de catre stub, din
definitia WSDL: xsd:element
Defineste operatiile ( Operation) , folosite de catre stub,
primite din descrierea WSDL: wsdl:operation
Defineste FaultDetailHandler , o interfata implementata
de stub pentru tratarea erorilor
Defineste FaultDetailException, folosita de stub,
clasa ce arunca exceptii la runtime
javax.xml.namespace Defineste un nume ( Qname) al clasei folosite de catre stub.
javax.xml.rpc Defineste interfata stub -ului, care reprezinta interfata pentru
toate stub -urile JAX -RPC
java.rmi Pachet derivat din java.rmi JAX -RPC, folosit pentru a
satisface dependentele RPC.
5.5 Sony Ericsson – Platforma Java
Pentru platformele Java, Sony Eric sson foloseste o abordare apropiata de implementarea
Java, permitand dezvoltatorilor sa se axeze mai degraba pe platformele disponibile decat pe modele
de telefoane existente. Exista doua platforme Sony Ericsson disponibile, pentru telefoanele ce
suporta S ymbian (SJP) si cele care nu suporta Symbian (JP16). Platformele sunt implementate intr -o
maniera evolutionara pentru a asigura compatibilitatea intre diferite versiuni. Fiecare platforma este
folosita pe anumite telefoane. Toate platformele sunt compatibil e cu cele precedente, astfel incat o
implementare pentru o platforma cuprinde toate caracteristicile platformelor precedente.
16 JP = Platforma Java pentru Sony Ericsson
91 In lista de mai jos sunt prezentate toate telefoanele Sony Ericsson (disponibile pana in luna
martie 2007) si platformele Java co respunzatoare fiecarui model.
Figura 5 5. Platformele J2ME pentru telefoanele mobile produse de Sony Ericsson
In anul 2006 Sony Ericsson a introdus Platforma Java 6 (Java Platform 6 – JP-6) ce ofera
suport pentru Servicii W eb (JSR 172), facand posibila consumarea unui serviciu web de catre un
client J2ME de pe un telefon mobil. Pentru a putea consuma un serviciu web cu ajutorul unui telefon
Sony Ericsson, acesta trebuie sa faca parte din telefoanele cu versiunea 6 (sau mai n oua) a
Platformei Java [17][18] .
92 6. Contributii personale
Contributiile personale din cadrul acestei lucrari sunt:
Ideea aplicatiei
Gasirea unei solutii fiabile
Analiza si proiectarea aplicatiei
Implementarea aplicatiei
Testarea aplicatiei
Vom prezenta in continuare principalele probleme care au aparut in cadrul dezvoltarii
aplicatiei, cat si solutiile propuse in aceasta lucrare.
Volumul datelor necesare pentru administrarea oraselor (drumuri si intersectii) este foarte
mare, iar daca solutia propusa nu este eficienta, administrarea este dificil de efectuat
Pentru a simplifica la maxim administrarea drumurilor si intersectiilor pentru un oras am
introdus un modul de administrare care foloseste interfete grafice (GUI). Astfel, administratorul are
posibili tatea sa incarce o harta a unui oras (dintr -un fisier grafic JPEG), iar aplicatia va afisa acea
harta la detalii maxime si va permite introducerea pe baza hartii a drumurilor si intersectiilor
necesare. In plus, interactiunea administratorului cu sistemul este minima, acesta din urma efectuand
operatii in mod automat in functie de cererile administratorului.
Dimensiunea unui fisier ce contine harta unui oras este foarte mare, iar platforma utilizata
nu permite incarcarea tipurilor grafice cu dimensiuni foar te mari si nici nu permite
interactiunea cu acestea
Aceasta problema a fost solutionata prin crearea unui control special care se ocupa cu
incarcarea formatelor grafice si permite interactiunea cu acestea. Astfel, prin intermediul controlului
se pot incarc a fisiere grafice cu dimensiuni mari si se poate interactiona cu acestea, fara a afecta insa
formatul initial al imaginii. Controlul este special conceput sa proceseze si sa afiseze doar acea
portiune a hartii care este pe ecran si doar acele intersectii s i drumuri care sunt vizibile. Astfel se
reduce semnificativ timpul necesar procesarii si afisarii grafice, nemaifiind necesara redesenarea
acelor componente care nu apar pe ecran la un moment dat.
Reprezentarea grafica a drumurilor poate pune probleme deoa rece nu putem sti ordinea in
care administratorul selecteaza cele doua intersectii care il definesc
Aceasta problema este rezolvata prin efectuarea unei ordonari a intersectiilor inainte ca
drumul dintre ele sa fie stabilit si afisat grafic pe ecran. Mai m ulte detalii despre aceasta etapa se
gasesc in cazul de utilizare Adaugarea drumurilor, subcapitolul 3.3.2.
Salvarea datelor ar putea pune probleme deoarece noi lucram atat cu date incarcate din
mediul persistent, cat si cu date din sesiunea curenta. O ope ratie de salvare trebuie sa
reflecte modificarile facute nu numai local, ci si in mediul persistent.
Solutia propusa este introducerea in faza de proiectare a unor atribute de marcaj pentru
clasele Drum si Intersectie care vor stabili atat operatiile care vor fi efectuate pe fiecare obiect in
parte (inserare, stergere, modificare), cat si ordinea acestor operatii. Mai multe detalii despre acest
procedeu se gasesc in cazul de utilizare Salvarea datelor, subcapitolul 3.3.3.
93 Telefonul mobil nu are procesorul s i memoria indeajuns de puternice incat sa poate efectua
calcularea drumului cautat de catre utilizator.
A fost necesara introducerea unui middleware care sa se ocupe cu efectuarea tuturor
operatiilor necesare. Acesta este un serviciu web. El doar va primi cererile de la aplicatia mobila, le
va procesa si va intoarce direct rezultatul, operatiile care revin partii mobile fiind doar cele de
trimitere si primire.
Aplicatia mobila ruleaza pe un dispozitiv mobil sub J2ME, iar serviciul web pe un calculator
dedic at, sub platforma .NET Framework. Cum vor putea comunica aceste doua platforme
total diferite?
Solutia acestei probleme este data de serviciul web, care, printre avantajele majore pe care le
aduce , se numara si interoperabilitatea. Comunicarea intre cele d oua platforme se va face folosind
protocolul standard SOAP (ce are la baza XML) si un canal HTTP. Mai multe detalii despre aceste
tehnologii se gasesc in capitolul 5.
Telefonul mobil nu are memorie suficienta pentru a stoca hartile intregi ale oraselor
Din aceasta cauza, hartile nu vor fi stocate pe telefonul mobil. In schimb, serviciul web va
procesa segmentul de drum cautat de catre utilizator si va trimite datele aplicatiei mobile, a carei
sarcina va fi cea de afisare a acestora.
94 Bibliografie
[1] http://en.wikipedia.org/wiki/Global_Positioning_System
[2] http://en.wikipedia.org/wiki/Distributed_application
[3] http://en.wikipedia.org/wiki/Tier_%28computing%29
[4] Note curs Ingineria Programarii, Crenguta Bogdan , 2007
[5] Note curs Analiza si Pr oiectarea Sistemelor Informatice , Chelai Ozten, 2007
[6] http://en.wikipedia.org/wiki/.NET_Framework
[7] http://www.javaworld.com/javaworld/jw -08-2002/jw -0823 -wireless.html
[8] http://www.onjava.com/pub/a/onjava/2001/03/08/J2ME.html
[9] http://the.jhu.edu/ upe/2003/01/18/introduction -to-the-a-star-algorithm/
[10]http://www.sqlservercentral.com/columnists/fBROUARD/recursivequeriesinsql1999andsqlserv
er2005.asp
[11] http://www.codeproject.com/cs/algorithms/graphs_astar.asp
[12] http://java.sun.com/products/wsa/
[13] http://developers.sun.com/techtopics/mobility/apis/articles/wsa/index.html
[14] http://developers.sun.com/techtopics/mobility/midp/articles/models/
[15] http://developers.sun.com/techtopics/mobility/getstart/articles/survey/
[16] http://developers.su n.com/techtopics/mobility/getstart/
[17] http://developer.sonyericsson.com/getDocument.do?docId=65067
[18] http://developer.sonyericsson.com/getDocument.do?docId=86467
[19] http://msdn2.microsoft.com/en -us/library/ms996507.aspx
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: APLICA ȚIE PENTRU TELEFONIA MOBIL Ă DE ORIENTARE INTR -UN ORAȘ Coordonator științific Lect. dr. Crenguța Bogdan Absolvent Drăghicescu Daniel CONSTAN… [618631] (ID: 618631)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.