Sistem Inteligent de Comanda Taxi Pentru Telefoanele Mobile

SISTEM INTELIGENT DE COMANDĂ TAXI PENTRU TELEFOANELE MOBILE

LUCRARE DE LICENȚĂ

Cuprins

1. Introducere

1.1 Context

1.2 Conturarea domeniului

2. SPECIFICAȚIA ȘI OBIECTIVELE 8

3. STUDIU BIBLIOGRAFIC

3.1 Arhitectura client-server

3.2 Programarea Orientată pe obiecte

3.3 Android

3.4 Python

3.5 Python – Django

3.6 JSON

4. ANALIZĂ ȘI FUNDAMENTARE TEORETICĂ

4.1 Arhitectura sistemului

4.2 Funcționalitățile sistemului

4.3 Cerințele non-funcționale

4.4 Schema bloc a sistemului

4.5 Considerații de performanță

4.6 Analiza algoritmului de desenare a hărții google pe server

5. Proiectarea de detaliu și implementarea

5.1 Tehnologii utilizate în implementarea sistemului

5.2 Diagrama de clase

5.3 Diagrama de secvență

5.4 Diagrama de deployment a aplicației

5.5 Diagrama cazurilor de utilizare

5.6 Structuri de date

5.7 Interfața grafică

6. Testare și validare

7. Manual de instalare si utilizare

7.1 Manual de instalare server

7.2 Manual de instalare client

7.3 Manual de utilizare server

7.4 Manual de utilizare client

8. Concluzii

9. Bibliografie

Introducere

Context

Trăind într-o lume în care nevoia și dorința de comunicare este din ce în ce mai mare și mai importantă, iar nevoia de a fi în contact permanent cu ceilalți deja este o necesitate și se manifestă în majoritatea domenilor, dispozitivele mobile dotate cu sisteme de operare din ce în ce mai performante sunt soluția pentru satisfacerea acestor idei. Practic acestea tind să înglobeze în ele un nou univers al fiecărui deținător de astfel de dispozitiv, putând să dețină acces la agenda telefonică, știri de ultima oră, întâlniri de afaceri, jocuri etc.

Fiind din ce în ce mai mult dependenți de aceste tehnologii de comunicare, de transfer de informație tindem să ne petrecem și să ne îndreptăm viața spre lumea aceasta virtuală. În cele ce urmează este prezentat modul în care se poate folosi tehnologia Android în crearea unei aplicații.

Ținând cont de aceste aspecte ale dezvoltării în direcția telefoanelor mobile, o idee bună de aplicație ar fi dezvoltarea uneia pentru a putea efectua comenzi la taxi prin intermediul telefonului mobil. Astfel, efectuarea unei comenzi va fi realizată mai rapid, iar clientul care dorește să facă comanda intră pe dispozitivul lui, face o cerere de comandă și în timp real aceasta o să i se asigneze.

Un număr tot mai mare de telefoane mobile sunt dotate cu capacitatea de a fi localizate prin gps. Odată cu introducerea gps-urilor pe dispozitivele mobile s-a deschis o lume de servicii care se bazează pe locația dumneavoastră, odată cu asta se introduce și posibilitatea de urmărire in timp real a unui dispozitiv mobil.

Chiar și fară un receptor GPS, dispozitivele mobile pot furniza informații referitoare la locația dumneavoastră. Un calculator poate determina pe baza masurătorilor de semnal cum ar fi:

Cât timp are nevoie semnalul să ajungă de la un turn de semnal la altul.

Puterea semnalului atunci când se ajunge la turnuri

Părțile cele mai critice ale aplicației client-server descrisă mai sus sunt trimitirea și receptarea mesajelor între clienți ( clienți care fac comandă de taxi și clienti taximetriști care preiau comenzi). Schimbul de mesaje între cele două tipuri de clienți se realizează cu mesaje de tip JSON. Este foarte important ca fiecare mesaj să ajungă la destinatarul dorit pentru a nu apărea neplăceri în utilizarea sistemului. Astfel, aplicația nu va mai avea credibilitate în fața posibililor utilizatori.

O altă parte critică în realizarea unui sistem îl are alegerea tehnologiilor pe care urmează să le folosim, deoarece la posibile dezvoltări ulterioare trebuie ca tehnologiile alese să suporte viitoarele îmbunatățiri. Pentru partea de Client vom folosi aplicații făcute în Android atât pentru Client care face comanda, cât și pentru Client-Taximetrist. Iar pentru partea de server vom folosi Python.

Comunicarea între Client și Server se realizează prin mesaje de tip Json deoarece sunt foarte ușor de scris și de citit de către oameni și ușor de generat și descompus de către compilatoare.

O altă parte critică a aplicațiilor este securitatea informației. Clasificarea se face în funcție de acțiunea vizată prin atacul asupra sistemului: obținerea de acces neautorizat la date, execuția de cod arbitrar, negarea de servicii. În cadrul unui sistem, dacă se cunoaște o vulnerabilitate a securității informației, aceasta este imediat remediată, iar sistemul este actualizat la ultima versiune, astfel acea vulnerabilitate va dispărea.

Securitatea sistemului este privită ca un parametru de calitate al sistemului, iar acesta diferă de la caz la caz în funție de cunostințele și atitudinea utilizatorului despre importanța securizării unui produs. În funcție de necesitatea implementării unui sistem ridicat de securitate există aplicații software care au implementată o politică severă de securitate deoarece, în cadrul acelui sistem se va opera cu date critice pentru utilizatorii acestora. De asemenea sunt și sisteme care nu necesită un grad ridicat pentru securitate deoarece nu se operează cu date critice.

Aplicarea unor tehnici de securitate încă din faza de început a proiectului poate aduce o creștere considerabilă a prețului acestora. Din cauză că securitatea costă, mulți clienți renunță la implementarea unei securități ridicate în aplicația lor.

Conturarea domeniului

Pentru conturarea exactă a domeniului de studiu am să pornesc de la următoarea întrebare:

De ce tipul și modalitatea de trimitere a mesajelor este o problemă ?

Tipul mesajelor este foarte important deoarece trebuie să folosim un model internațional de mesaj pentru a putea fi ințeleasă și extinsă aplicația cât mai bine în cazul unor îmbunătățiri ulterioare. Dacă vom folosi mesaje create de noi e posibil ca, pe viitor, când vor veni alți dezvoltatori ai proiectului, să nu înțeleagă modul de transfer al mesajelor de la client la server și invers, astfel va fi foarte greu pentru realizarea de dezvoltări ulterioare. Am ales să folosesc mesaje de tip Json deoarece este un tip internațional de mesaje. Json este construit pe două tipuri de structuri: o colecție de nume/valori puse în pereche care, în cele mai multe limbaje, aceasta este realizată sub formă de obiect și o listă ordonată de valori, care în cele mai multe limbaje este realizată sub formă de colecție.

Metoda folosită pentru transmiterea mesajelor este POST. Aceasta este una din multele metode de cerere a informației de pe server folosită de protocolul HTTP utilizat de către consorțiul World Wide Web. Metoda de cerere POST este concepută pentru a vedea dacă un server web acceptă data încapsulată în corpul mesajului. În contrast cu POST avem GET care este o metodă concepută pentru a obține informații de pe server. Ca și parte a unei cereri GET,unele date pot fi transmise cu URL-ul. Acestea pot specifica unele informații despre termeni de căutare, intervale de date sau alte informații ce definesc interogarea. În cererile de tip POST pot fi trimise o cantitate arbitrară de date în corpul mesajului. Un câmp de antet în cererile de tip POST de obicei indica corpul mesajului. Clientul trimite o cerere către server iar acesta îi dă un răspuns.

Pentru o descriere a funcționalității POST-ului vedeți figura 1.1 POST HTTP.

SPECIFICAȚIA ȘI OBIECTIVELE

Se dorește implementarea unei aplicații care să permită utilizatorilor să facă comenzi de taxiuri prin intermediul telefoanelor mobile ce au sistem de operare Android pe ele și, implicit posibilitatea taximetriștilor să preia comenzi efectuate de clienți.

Obiectivul principal al aplicației este acela de a oferi utilizatorilor posibilitatea de a efectua comenzi de taxi rapide, prin intermediul telefonului mobil și de a fi preluate de către un taximetrist cât mai repede.

Un alt obiectiv de asemenea important este transmiterea mesajelor între client – server și server – client. Vom defini 2 aplicații: una pentru clienții care vor sa facă comenzile și una pentru taximetriști prin care se vor prelua comenzile.

Sistemul va funcționa astfel: clientul care dorește să facă comanda se autentifică și așteaptă un anumit timp până este localizat pe hartă prin gps. Acesta are și un câmp unde poate să își introducă numele comenzii. Când dorește să lanseze comanda, clientul alege dacă vrea ca locația acesteia să fie cea a localizării gps sau o altă adresă introdusă de acesta. Se așteaptă un interval de timp până se asignează o comandă, după care, clientul poate să observe în timp real unde este taxiul pe hartă raportat la el. Afișarea hărții pe telefon se realizează folosind serviciul celor de la google „Google – maps”.

Localizarea pe aceasta hartă se realizează prin intermediul gps-ului prezent la fiecare dispozitiv ce are instalată aplicația pe el.

Clientul de taxi așteaptă să primească lista de comenzi și, în funcție de poziția acestuia primește o anumită listă. Clienții care au făcut comenzi pe o anumită zonă vor fi afișați în lista unui anumit taximetrist. Când un taximetrist dorește să preia o comandă, acesta își alege din lista pe care o are pe ecran comanda dorită, după care așteaptă un timp pentru a se asigna la comanda respetivă. După ce un anumit taximetrist s-a asignat la o anumită comandă se așteaptă un interval de timp pentru a se înscrie și alți taximetriști la comanda respectivă. Pe urmă, cu un algoritm de selecție este selectat taximetrist-ul cel mai apropiat.

Când taximetristul ajunge la clientul care a efectuat o comandă, acesta îl avertizează printr-un mesaj trimis prin intermediul telefonului cum că acesta a ajuns la destinație.

Un alt obiectiv, mai puțin vizibil pentru utilizatorii aplicației, care ține mai mult de felul în care va fi organizată arhitectura aplicației, este extensibilitatea acesteia. La etapa actuală, aplicația va permite doar comunicarea între clienți și taximetriști. Deoarece clientul sistemului va fi o aplicație dezvoltată pe platforma Android, aceasta va fi îmbunatațită în timp, prin adăugarea de noi funcționalități cum ar fi mesagerie instantă între client și taximetrist pentru a se putea găsi mai ușor la finalizarea comenzii.

Pe partea de server al aplicației, obiectivul de bază a fost folosirea unui protocol de comunicare între cele două tipuri de aplicații client. Pe server este stocată baza de date a sistemului, aici sunt salvați toți utilizatorii, comenzile și legăturile între acestea.

Tot aici se dorește implementarea de condiții asupra clienților. În cazul în care unul nu a onorat o comandă acesta nu mai primește comenzi o perioadă de timp. În cazul în care incidentul se tot repetă, taximetriștii nu vor mai fi capabili să preia niciodată comenzi, iar în cazul clienților să mai efectueze comenzi.

STUDIU BIBLIOGRAFIC

Arhitectura client-server

Arhitectura client-server este o arhitectură de rețea în care fiecare calculator sau proces din rețea este un client sau un server. În etapa actuală clientul poate fi o aplicație mobilă, un proces rulat la distanță care face cereri către aplicația server. În majoritatea cazurilor aplicația client este cea care interacționează cu utilizatorul. Aceasta are următoarele sarcini de bază:

Logica prezentării

Logica aplicației

Logica prezentării se referă la acea parte a programului care coordonează interacțiunea dintre utilizator și aplicație. Aceasta mai include și partea de preluare a datelor de la utilizator.

Logica aplicației se referă la acea parte a programului care decide ce acțiuni trebuie să se execute în diferite situații și ea implementează logica afacerii.

Aplicația server poate rula pe orice calculator care are suficiente resurse pentru a putea asigura un timp de procesare și răspuns la cererile aplicațiilor client.

Arhitecturile client-server prezintă următoarele avantaje:

Au o securitate mai bună

Raportul calitate preț este mai bun

Performanțele pot fi îmbunătățite ușor prin reproiectarea aplicației server

Prin dezavantajele aplicațiilor-client server pot fi enumerate urmăilă, un proces rulat la distanță care face cereri către aplicația server. În majoritatea cazurilor aplicația client este cea care interacționează cu utilizatorul. Aceasta are următoarele sarcini de bază:

Logica prezentării

Logica aplicației

Logica prezentării se referă la acea parte a programului care coordonează interacțiunea dintre utilizator și aplicație. Aceasta mai include și partea de preluare a datelor de la utilizator.

Logica aplicației se referă la acea parte a programului care decide ce acțiuni trebuie să se execute în diferite situații și ea implementează logica afacerii.

Aplicația server poate rula pe orice calculator care are suficiente resurse pentru a putea asigura un timp de procesare și răspuns la cererile aplicațiilor client.

Arhitecturile client-server prezintă următoarele avantaje:

Au o securitate mai bună

Raportul calitate preț este mai bun

Performanțele pot fi îmbunătățite ușor prin reproiectarea aplicației server

Prin dezavantajele aplicațiilor-client server pot fi enumerate următoarele:

Complexitatea: administrarea și configurarea serverelor nu este simplă

Preț: performanțele server-ului scad odată cu creșterea numărului de utilizatori

Necesități: pentru a putea deservi un număr mare de clienți, serverul trebuie să fie un calculator foarte performant.

Arhitecturile client server pot fi clasificate în următoarele trei categorii:

Arhitecturi pe două niveluri

Arhitecturi pe trei niveluri

Arhitecturi pe mai multe niveluri

Arhitectura client-server pe două nivele a fost dezvoltată în anii 1980. Prima generație a aplicațiilor client-server a fost dezvoltată în două nivele logice și două nivele fizice. O aplicație client-server pe două nivele este împărțită în două părți unde o porțiune rulează pe mașina client și o porțiune rulează mașina server. Astfel, aplicația este împărțită între client și server. Această arhitectură este constituită din trei componente distribuite pe două nivele:

Interfața de sistem cu utilizatorul

Logica aplicației(administrarea prelucrării)

Gestiunea bazei de date

Fig.3.1.1Modelul conceptual al arhitecturii client-server pe două nivele

Arhitectura client-server pe trei nivele a fost dezvoltată în anii 1990, și a apărut ca alternativă pentru deficiențele prezentate de arhitectura client-server a celei de două. În cadrul acestei aplicații este adăugat un nivel suplimentar, numit nivel de mijloc sau server de aplicații , între client și serverul bazei de date, care are rolul de prelucrare a regulilor de afaceri,deci eliberează clientul de logica aplicației.

Arhitectura client-server pe trei nivele este utilizată atunci când aplicația distribuită trebuie să permită performanțe mai bune, flexibilitate, mentenabilitate, reutilizabilitate și scalabilitate.

Fig.3.1.2 Modelul client-server pe trei nivele

Arhitectura client-server pe trei nivele este cea la care nivelul de mijloc este împărțit în două sau mai multe nivele cu funcționalitați diferite. Cele mai cunoscute aplicații cu o astfel de arhitectură sunt aplicațiile Internet. Acest nivel intermediar este implementat într-un limbaj de scriptare. Acest nivel primește cererile de la clienții Internet și generează pagini html utilizînd serviciile oferite de nivelul de afaceri al aplicației. Astfel se realizează și separarea între organizarea aplicației și logica aplicației.

Fig.3.1.3 Modelul conceptual al arhitecturii client-server pe mai multe niveluri

Programarea Orientată pe obiecte

Odată cu creșterea mediului informatic a crescut și numărul de probleme legate de dezvoltarea a noi aplicații și mai ales de aplicații de mare anvergură. Proiectarea sistemelor este foarte complicată când nu există o modalitate intuitivă de a percepe lucrurile. În perioada programării procedurale, lucrurile păreau simple în sensul că pentru fiecare acțiune exista o funcție implementată. Avantajul programării procedurale este că permite execuția rapidă a codului fară trecerea prin diverse straturi. Problema cea mai mare a programării procedurale este greutatea cu care se modularizează sistemul și, din punct de vedere arhitectural, sunt foarte greu de adăugat module noi ceea ce ar însemna că sistemul să atingă o limită în dezvoltare peste care nu poate trece.

Din această cauză a fost necesară o modalitate nouă de organizare a codului. Programarea Orientată pe Obiecte este această nouă organizare și este cel mai actual tip de programare în industrie. Multe limbaje de programare au posibilitatea programării pe obiecte cel putin ca opțiune adițională.

În programarea orientată pe obiecte, există o legatură stransă între date si operațiile realizate asupra lor de asemenea se extinde și asupra structurilor de date. Obiectele sunt considerate o structură de date, asociată cu o colecție de metode ( funcții sau procedure ) prin intermediul cărora se manipulează aceste date. Obiectele care au aceleași câmpuri si aceleași clase sunt grupate in aceași clasă. Clasa este o extindere a conceptului de tip de date, in care mulțimea de valori este o mulțime de obiecte, iar mulțimea operațiilor este o mulțime de metode. "Programul" este, in POO, un ansamblu de clase si obiecte care comunica intre ele prin mesaje.

Obiectele sunt caracterizate prin:

– stare: obiectul este caracterizat prin valorile pe care le au datele conținute de acesta. La modificarea stării unuia sau a mai multor cîâmpuri starea obiectului se modifică.

– comportament: se manifestă in modul in care obiectul răspunde la primirea unui mesaj. Răspunsul depinde atât de starea actuală a obiectului cât si de conținutul mesajului.

Obiectivele analizei si proiectarii orientate sunt:

– îmbunatățirea mentenabilității produselor program, adică a posibilității de a fi depanate si modificate cu usurință;

– imbunatățirea posibilității de reutilizare a produselor software, ceea ce are drept consecință reducerea costurilor;

– creăterea productivității analiștilor si programatorilor, prin punerea la dispoziția acestora a unor biblioteci de clase reutilizabile;

– imbunătățirea calitații produselor program prin utilizarea unor metode eficiente de analiza si programare și prin folosirea in programe a unor clase de bibliotecă bine verificate.

Se consideră că trecerea de la programarea procedurală "tradițională" la programarea orientată pe obiecte poate fi comparată cu trecerea de la producția artizanală la cea industrială. În producția artizanală, produsul este realizat, in toate componentele sale, de un singur meșter, sau de un număr mic de lucrători conduși de un astfel de meșter, care "monopolizează" atât concepția, cât si execuția. Fiecare produs este executat ca un unicat. În producția industrială, produsul este alcătuit dintr-un număr mare de componente fabricate – in general – în alte unități industriale, producatorului final revenindu-i numai sarcina construirii unui numar mic de componente (de ex. carcasei) și asamblării finale. Proiectantul unui astfel de produs industrial alege cea mai mare parte din componente din cataloage, iar sarcina lui este să proiecteze ansamblul produsului și acele componente care nu pot fi procurate de la alți fabricanți. În mod similar, în POO, la proiectarea unei aplicații folosesc "cataloage de clase" existente in biblioteci, iar programatorilor le revine numai sarcina conceperii ansamblului și scrierii programelor care utilizează aceste clase pentru realizarea obiectivelor aplicației respective. Se obține astfel atât  creșterea sensibilă a productivității programatorului, cât și imbunatățirea calității aplicației, deoarece se folosesc componente deja verificate. Totodată, dacă se constată anumite anomalii (erori) într-un produs program, pentru depanarea lor este suficient să se localizeze obiectul (componenta) care le-a produs și să se remedieze sau inlocuiască această componentă. De asemenea, modificarea functionalității unui produs program se poate face prin adaugarea de componente (obiecte) noi sau inlocuirea unor componente existente, fară a modifica intregul produs. Aceste caracteristici au drept consecință creșterea mentenabilității produselor program realizate in cadrul POO.

Un avantaj foarte important în programarea obiectuală, rezultat din utilizarea obiectelor, este posibilitatea de a construi relații între aceste obiecte și care permite totodată mult mai ușor trasarea și depanarea comportamentului sistemului. Relațiile acestea duc la definirea unor tehnici de programare obiectuala specifice POO:

– Moștenire

– Încapsulare

– Modularitate

– Abstractizarea datelor

– Polimorfism

– Transmiterea de mesaje

Moștenirea este tehnica prin care derivăm un obiect din alt obiect. De fapt avem un obiect care este considerat părinte iar celălalt este considerat copil. Obiectul copil moștenește toate metodele si proprietățile obiectului părinte și pe lângă acestea îi mai sunt adăugate și alte metode și proprietăți.

Încapsularea presupune ascunderea datelor într-un obiect. Obiectele pot avea niveluri de accesibilitate diferit la datele care le conțin, de multe ori este foarte important ca proprietățile obiectului sa poată fi modificate numai de catre acesta, in acest caz spunem că proprietățile obiectului sunt private. Un alt caz ar fi ca proprietățile si metodele lui sa fie accesibile global, adică oricine poate avea acces la ele.

Modularizarea este organizarea datelor si componentelor unui sistem in componente cât mai mici si ușor de depanat. In principiu modulele trebuie sa aibă integritate și trebuie să fie ușor de schimbat, șters sau adăugat.

Abstractizarea datelor este capabilitate unui sistem să acceseze doar datele utile pentru acesta și să le ignore pe cele inutile. Funcțiile si proprietățile obiectelor pot fi abstracte, iar in acest caz este necesar sa se faca o specializare ale acestora prin tehnicile descrise mai sus.

Polimorfismul este calitatea obiectelor de a avea mai multe forme și ca a tare de a avea comportament diferit pentru fiecare formă.

Transmiterea de mesaje reprezintă modalitate de comunicare între procese si obiecte prin transmiterea de mesaje. Această tehniă este utilizată inprogramarea paralelă si programarea orientată pe obiect sau la comunicarea între procese.

Android

Sistemul de operare Android este un sistem de operare apărut recent pe piață de sipozitivele mobile. Acest sistem este atractiv pentru dezvoltatori deoarece oferă librării și utilitare pt dezvoltarea de aplicații open source. Este un sistem bazat pe controale și evenimentele atașate acestora,care-l face să fie un sistem „condus pe evenimente”.

Sistemul de operare Android este alcătuit din următoarele componente de bază:

Activitatea

Serviciu

Intenție

Manager de conținut

Receptor de emisie („broadcast”)

Activitatea reprezintă interfața cu utilizatorul, o aplicație Android poate avea una sau mai multe activități. Fiecare activitatea are un ciclu de viata independent de ciclul de viata al procesului asociat aplicației. Activitățile iși pot păstra starea și datele acesteia pot fi salvate sau restarate. O aplicație poate avea cicluri de viață multiple.

Serviciu este reprezentat de o sarcină care este executată in fundal, fără interacțiunea directă cu utilizatorul si este gestionat de o instanță a clasei „ Service”.

Intenția este entitatea folosită pentru descrierea unei operațiuni care este pregătită pentru a fi executată. De fapt este un mesaj transmis către o altă componentă pentru a anunța o anumită operațiune. Este reprezentată de un mesaj asincron folosit pentru a activa servicii sau activități. Intenția este gestionată de o instanță a clasei „Intent”.

Managerul de conținut este un API folosit pentru a gestiona datele priate ale aplicației, este ca un sistem de administrare de date ce descrie o alternativă la sistemul de fișiere, baze de date SqlLite sau orice alta soluție de stocare persistentă.

Receptorul de emisie este o componentă care răspunde la anunțuri difuzate la nivel de sistem, similar cu conceptul de handler global. Acesta este implementat de o subclasă a clasei „BroadcastReceiver”.

Resursele aplicațiilor Android reprezintă șirurile de caractere, bitmap-urile, fișierele video și audio, folosite pentru a imbogați experiența utilizatorului. Deși sunt controlate din codul sursă acestea reprezintă resurse externe ale aplicației si este recomandat sa fie externalizate pentru a putea facilita:

Internaționalizarea interfeței cu utilizatorul prin furnizarea acesteia in diferite limbi si formate

Portabilitatea aplicației

Resursele sunt stocate in directorul „res” din cadrul oricărui proiect Android. In funcție de resursele care vrem sa le gestionăm acest director conține subdirectoare.

Python

Python este un limbaj dinamic de programare care este utilizat într-o varietate largă de aplicații. Este adesea comparat cu alte limbaje de programare cum ar fi Perl, Ruby, TCL, Java. Unele dintre caracteristicile sale cheie includ:

Sintaxa foarte clară si ușor de citit

Capabilități puternice de introspecție

Orientare obiect intuitivă

Expresie naturală a codului

Complet modularizat, suportă pachete ierarhice

Suportă tipuri de date dinamice

Include biblioteci standard extinse și module pentru aproape orice tip de sarcină

Implementarea Python estesub o licență „open-source” care îl face liber de utilizat și de distribuit chiar și pentru uz comercial.

Python este un limbaj de programare rapid si ușor de înțeles. Limbajul este unul flexibil care practic poate manipula practic orice problemă. Poți sa iți construiești propriul tau website in doar trei linii de cod. Se poate construi cod condus de date folsind capabilitățile de introspecție dinamică a Python-ului și funcții avansate de limbi străine, cum ar fi meta-clasele.

Python poate fi integrat cu obiecte COM, .NET si CORBA. Pentru librăriile JAVA se folosește Jython, care este o implementare a Python pentru Mașina Virtuală JAVA. Pentru .NET se poate folosi „Python for .NET”, care este noua implementare a Python-ului adusă de Microsoft. Python este disponibil pentru orice sistem de operare: Windowsm Linux/Unix, OS/2, Mac, Amiga etc. Limbajul python este considerat ca fiind unul din cele mai prietenoase limbaje de programare acesta fiind foarte ușor de înțeles. Acesta vine cu o documentație completă care face utilizarea lui mult mai ușoară de catre utilizatori.

Python – Django

Django este un framework de nivel înalt care încurajează dezvoltarea rapidă și design-ul curat si pragmatic. Dezvoltat de o organizație online, acesta este proiectat pe baza cerințelor stricte ale dezvoltatorilor web cu experiență. Acest fapt permite construirea și dezvoltarea rapidă și elegantă a aplicațiilor WEB de inaltă performanță

Proprietățile framework-ului Django sunt următoarele:

Maparea relațională a obiectelor – definirea modelelor de date în întregime în python.

Interfață de admin automată

Desgign-ul url-ui este elegant

Sistem de șablon – limbaj prietenos de tamplate pentru a separa design-ul, conținutul și codul Python.

Internaționalizare – folosește suport total pentru multi-limbă

Ca și Python, Django este tot un limbaj „open-source” și poate fi folosit de oricine.

JSON

JSON ( JavaScript Object Notation ) este un format independent de schimb de date. JSON este limitat la valori de tip text și numerice, valorile binare nu sunt acceptate. JSON este un subset al specificașiei JavaScript și prin urmare este susținut direct în JavaScript. Structurile de date in Json sunt bazate pe perechi cheie-valoare. Cheia este un string iar valoarea poate fi o valoare numerică, o valoare boolean sau un obiect.

Un obiect JSON este un set de perechi cheie-valoare care începe cu ”{” și se termină cu “}” .

Exemplu de reprezentare a mesajelor JSON:

{"menu": {

"id": "file",

"value": "File",

"popup": {

"menuitem": [

{"value": "New", "onclick": "CreateNewDoc()"},

{"value": "Open", "onclick": "OpenDoc()"},

{"value": "Close", "onclick": "CloseDoc()"}

]

}

}}

ANALIZĂ ȘI FUNDAMENTARE TEORETICĂ

Arhitectura sistemului

În figura 4.1.1 este prezentată arhitectura conceptuală a sistemului. Această arhitectură este doar o imagine de ansamblu a sistemului și este construită conform descrierii proiectului din capitolul 2.

Fig 4.1.1 Arhitectura Conceptuală

Pe partea de Client avem două aplicații care sunt rulate pe dispozitive mobile cu sistemul de operare Android pe ele, deoarece acest sistem oferă toate componentele de bază pentru implementarea funcționalității aplicației.

Aplicațiile client sunt părți componente ale sistemului prin ajutorul cărora utilizatorii interacționează cu sistemul. Ele sunt expuse către utilizatori prin intermediul unei aplicații client Android. Prima aplicație client este concepută pentru a satisface nevoile clienților care vor sa comande un taxi. A doua aplicațtie client este concepută pentru asatisface nevoile clienților care vor sa onorez o comandă venită de la un client care o postat o comandă.

Web serverul este containerul in care rulează aplicația python. El oferă resurse si metode de interacțiune cu alte componente și sisteme din exterior. Aceasta aplicație conține si logica de business si conexiunea la baza de date a sistemului.

SQLITE3 este baza de date folosită.

Funcționalitățile sistemului

În urma celor descrise mai sus putem deduce mai multe funcționalităși ale sistemului. Mai jos vom descrie funcționalitățile sistemului ce trebuiesc implementate mai pe larg.

Aplicația client Comandă

Înregistrare / creare de cont

Logare și delogare utilizatori

Vizualizare pe hartă a poziției actuale

Completare de comandă nouă

Vizualizarea parametrilor de poziționare

Tratarea corectă a mesajelor primite de la server

Actualizarea poziție taximetristului asignat comenzii

Rularea in background a aplicației

Aplicația client Taximetrist

Vizualizare a tuturor comenzilor disponibile la un anumit moment de timp ale aplicației

Alegerea unei comenzi pentru a putea fi asignată respectivului taximetrist

Tratarea corectă a mesajelor primite de la server

Trimiterea coordonatelor de navigare constant către server

Rulare aplicație in background

Aplicația Python

Recepționare de mesaje de la ambele aplicații client

Trimitere de mesaje catre aplicațiile client

Afișare a informaților despre fiecare utilizator al sistemului

Afișare pe harta a poziționarii utilizatorilor in funcție de coordonatele gps ale acestora.

Posibilitatea de a șterge istoricul unor clienți

Posibilitatea de a vedea traseele făcute de toți utilizatorii

Persistarea datelor provenite de la clienții sistemului

Asigurarea accesului concurent la resursele sistemului

Asigurarea aplicațiilor client cu date consistente

Interacțiunea cu sistemul se va realiza prin intermediul a două aplicații client, fiecare fiind specializată pe o anumită funcționalitate in funcție de necesitățile care urmează sa fie indeplinite de catre aceasta.

Una din aplicații se bazează pe serviciile celor de la google maps pentru a putea arată poziționarea pe harta a clientului și a taxiului, iar cealalta aplicație va conține doar un „listview” al comenzilor existente.

Cerințele non-funcționale

În această secțiune sunt prezentate cerinșele non-funcționale ale sistemului. Ținând cont ca nu se cunoaște numarul de utilizatori ai aplicației trebuie să respectăm o serie de factori. De asemenea trebuie sa luăm in considerare si importanța consistenței mesajelor care sunt trimise între aplicațiile client si server. Sistemul trebuie sa funcționeze tot timul corect pentru a nu dezavantaja utilizatorii acestuia (exemplu: să se trimită un o comanda de taxi la o adresă gresită astfel incât un client care a făcut o comandă sa rămână fără taxi).

Cerințele non-funcționale ale sistemului sunt:

Coordonatele din mesajele primite trebuie sa aibă o anumită acuratețe

O comandă efectuată trebuie introdusă corect in lista de așteptare

Numele unei comenzi să fie unice

Unei singure comenzi să ii se asigneze un singur taximetrist

Trebuie sa se primească pozitia taximetriștilor la un anumit interval de timp

Evitarea introducerii a aceleași comenzi de două ori in sistem. Odată efectuată o comandă se așteaptă pană la asignarea unui taximetrist si doar după aceea poate fi efectuata altă comandă

Schema bloc a sistemului

În această secțiune este descrisă si prezentată schema bloc a sistemului și o scurtă descriere a acesteia. Această schema curpinde componentele principale ale sistemului si modul in care interacționează unele cu altele.

Schema actuală practic conține trei părți:

Client Comandă

Client Taximetrist

Server ClientTaxi

Aplicațiile de tip Client comunică intre ele prin intermediul celei de server. Aplicația care efectuează comenzi trimite catre server un mesaj intr-un format Json cu detaliile necesare pentru a face posibilă validarea comenzii. Serverul interpretează mesajul Json și introduce comanda in baza de date. Tot odată aplicatie Client Taxi face requeste pentru a primi de la server lista de comenzi valide de la un anumit moment. După ce primește lista de comenzi poate trimite o cerere de inregistrare la o anumită comandă pentru ai fi asignată.

Pentru prezentarea schemei bloc a sistemului se poate vizualiza Figur 4.4.1.

Figura 4.4.1 Schema Bloc

Client Comandă este o componentă de tip client a sistemului. Aceasta face cereri pe server de inregistrare a unei comenzi pe acesta. Deocamdată este realizată doar pe dispozitive ce suportă Android c ași sistem d operare dar aceasta poate fi realizată in viitor și pe alte tipuri de dispozitive cum ar fi cele care suportă Windows Phone sau IOS.

Client Taxi este o aplicație care poate rula pe dispozitivele ce suportă ca si sistem de operare Android. Acesta face cerere pe server a listei de comenzi și eventual se asignează la una din acestea. De asemenea și aceasta aplicație poate fi extinsă si pe alte platforme.

Serverul Django are grijă de funcționalitatea întregului sistem. Face practic partea de business logic a aplicației, adică oferă celor două tipuri de aplicații datele necesare acestora pentru a putea afișa pe interfața cu utilizatorul datele dorite.

Considerații de performanță

Deoarece această aplicație dacă este introdusă pe piața va avea un număr considerabil de utilizatori concurenți vom avea nevoie de un server care sa suporte traficul intre aceștia. Pentru fiecare utilizator al aplicației se vor executa cereri către server constant si este nevoie de tratarea corectă a cerințelor fiecăruia.

Performanța accesării funcționalitații serverului poate fi afectată de parametrii fizici ai serverului și de tipul de conexiune către server. Cu cât viteza de transfer a datelor prin rețeaua la care va fi conectat clientul va fi mai mare cu atît se poate asigura un timp de răspuns mai mic de la server.

Perfomanța serverului este determinată de parametrii săi fizici,modul în care este cconfigurat.Un server cu un sistem de procesare mai puternic orientat spre procesări concurente va asigura un timp mai mic de răspuns la cererile clienților.

Pe partea de client performanța sistemului se masoară în termeni de valorificare economică a resurselor acestuia, precum este bateria, traficul disponibil pentru un dispozitiv mobil pentru care este proictată aplicația client. O bună optimizare și corelare a modului de gestionare a acestor resurse poate duce la o creștere a duratei de folosire a dispozitivului pentru necesitățile aplicației în sine , cât și a altor aplicații care pot rula la moment pe dispozitiv.

Analiza algoritmului de desenare a hărții google pe server

Aceasta funcție a aplicației este menită pentru a construi harta care va fi afișată pe server și adaugarea tuturor utilizatorilor pe aceasta. Această parte practic construiește pentru fiecare utilizator in funcție de coordonatele pe care acesta le-a introdus in sistem o linie, care este colorată diferit pentru fiecare dintre acestea, reprezentând drumul parcurs deaceștia.

Pentru fiecare utilizator păstram si ultima locație, de asemenea când am păstrat coordonatele acestora le-am atașat si ora la care au fost recepționate de către server pentru a putea să avem o reprezentare bună a punctelor pe hartă.

Ultimul punct primit (ultimele coordonate) sunt afișate cu un punct de localizare pentru a putea fi evidențiată poziția utilizatorului la ultima trimitere către server.

De asemenea sunt implementate si funcții care care permit redesenarea traseelor in cazul în care ne hotărâm să scoatem de pe hartă anumiți utilziatori. Dacă am scos un utilizator și mai târziu considerăm ca acesta trebuie introdus din nou pe hartă putem realiza acesta lucru.

Figura 4.6.1 Reprezentare a hărții google_maps

În spatele fiecarei Harți Google există o hartă mult mai complexă care este defapt cheia reprezentării harții. Aceste detalii sunt ascunse utilzatorului și conțin o logică complexă.

În sistemul prezentat ăn acest document a fost nevoie de introducerea unei librări care suportă google maps atât in aplicația destinată efectuări de comenzi cât si pe server. Ambele afisează hărțile necesare reprezentării nevoilor utilizatorului/administratorului.

În figura 4.6.1 este prezentată o vedere a unei hărți, asa vor apărea hărțile și in aplicațile descrise numai ca o să fie afișată harta cu contextul care va trebui.

Proiectarea de detaliu și implementarea

5.1 Tehnologii utilizate în implementarea sistemului

Implementarea proiectului este realizată folosind două limbaje de programare: JAVA si python. Pe langă aceste limbaje de programare mai sunt folosite și cateva biblioteci online gratuite și disponibile pe internet. Aceste librării sunt folosite pentru o mai bună rezolvare a sistemului și o implementare mai ușoară.

Limbajele de programare, tehnologiile si tehnicile utilizate:

JAVA – limbaj de programare orientată obiect cu scopul dezvoltării de aplicțtii care implică dependențe minime intre părțile acesteia

SQLITE3 – este o biblioteca software care implementează un motor de sine stătător, motor tranzacțional SQL al bazei de date, nu are nevoie de server.

Android – platformă open-source de dezvoltare software

Python – este un limbaj de programare care permite să lucrați mai rapid și să integrați mai eficient sistemele. Se poate invăța să se utilizeze foarte ușor și se vor vedea caștigurile aproape imediat in vederea reducerii costurilor de intreținere si productivitate.

Django – este un framework de nivel inalt al Python-ului

Biblioteci folosite:

Django.contrib.admin – una dintre cele mai puternice parți ale lui Django este interfața automată de admin. Citește metadata in modelul tău pentru a livra o interfață gata facută care coține proceduri care pot fi folosite imediat pentru a incepe să adaugi conținut la site.

Django.http.HttpResponse – Django folosește obiecte cereri și răspuns pentru a trece starile prin sistem. Când o pagină este cerută, Django crează un obiect HTTPRequest care conține metadata despre cerere. Django încarcă cea mai apropiată vedere, pasează ht tprequest-ul ca și prim argument la funcția vedere („view function”). Fiecare vedere este responsabilă sa returneze un obiect HTTPResponse.

Django.json – librărie care ajută la codarea și decodarea mesajelor Json

Django.ast – acest modul ajută aplicațiile python sa proceseze arbori ai sintaxei Python

Google_maps – este un API cu ajutorul caruia putem afișa harta locațiilor dorite, pentru a putea obțtine vederi panoramice a ceea ce dorim fara a avea nevoie de javaScript. Folosește cereri HTTP sa acceseze înălțimea,direcția, locul si informații despre fusul orar dintr-o anumită locație.

5.2 Diagrama de clase

5.2.1 Aplicațile Client

Aplicația Client Comandă

Figura 5.2.1 Diagrama de clase pentru aplicația Client Comandă

În figura 5.2.1 este prezentată diagrama de clase pentru apicația Client Comandă. Aceasta are rolul de a localiza pe hartă un client care dorește să efectueze o comandă. După ce este localizat si introduce numele comenzii se trimite catre server un mesaj cu comanda acestuia si este pus in lista de comenzi active ale site-ului. Mesajul se trimite numai dacă localizarea utilizatorului are o acuratețe suficient de bună pentru a putea fi gasit de către clientul taxi. Aceasta este o aplicație destinată celor care doresc să efectueze comenzi.

Din Client Comandă fac parte urmatoarele clase:

Utils – clasă auxiliară pentru a putea accesa cateva date ce țin de dispozitiv, cum ar fi UUID-ul telefonului (seria acestuia) sau contextul

DataSyncronizer – pregăteștele mesajele care urmează sa fie trimise. Toate proprietățile necesare sunt introduse într-un obiect de tip JSON si apoi cu HTTPREQUEST este trimis mesajul catre server. Daca nu are conexiune validă cu un server scrie datele intr-un fișier.

LocationManager – localizează dispozitivul si vede dacă acuratețea cu care s-au gasit datele e suficient de bună încat sa fie trimise la server. De asemenea se verifică dacă fosa locație unde a fost indentificat dispozitivul est la o distanță suficient de mare pentru a putea cosidera ca poziția dispozitivului s-a modificat.

AppController – Este interfața pentru a descrie funcțiile ce vor fi apelate din mainActivity, practic se definesc metodele principale care vor controla aplicația.

MainActivity – este clasa care se ocupă cu interfața grafică si cu activarea trimiterii către server a datelor.

Aplicația Client Taxi

Figura 5.2.2 Diagrama de clase pentru aplicația Client Taxi

În Figura 5.2.2 este prezentată diagrama de clase pentru aplicația Client Taxi care este una din aplicațiile de pe parte de client a sistemului. Aici este tratată lista de comenzi activă de pe server și de aici se pot prelua comenzile. Este o aplicație destinată șoferilor de taxi care vor sa preia comenzi.

Din Client Taxi fac parte urmatoarele clase:

Command – model pentru o comanda, conține metode care se pot executa pe obiecte de tip comandă

Coordinate – model pentru a reține in obiecte coordonatele comenzii

JSONCommandsParser – clasă care parseaza un obiect de tip JSON pentru a putea fi mapat pe obiectele de tipul modelelor mai sus descrise

HTTPRequestHandler – preia mesajul de la server și il parsează cu ajutorul metodelor din clasa JSONCommandsParse sau trimite o cerere la server de asignare la o anumită comandă

MainActivity – partea in care este descrisă și interfața grafică a acestei aplicații, rezolvă interacțiunile utilizatorului cu dispozitivul prin executare unor metode lansate numai la cererea acestuia.

Cu ajutorul cererilor HTTP se pot rezolva cererile către server iar in funcție de necesitatea utilizatorului sistemul va trimite anumiți parametri în mesajul trimis către server. Pe server este interpretat mesajul si in func

Ie de parametrii trimite inapoi un mesaj cu datele solicitate de utilizator. După ce se primește mesajul cu datele cerute fie de asignare la o comanda fi de cerere a listei de comenzi, ecranul aplicației este reîmprospatat cu noile date.

5.2.3 Aplicația Server

Aplicația Server ClientTaxi

Figura 5.2.3 Diagrama de clase a server-ului

În Figura 5.2.3 este prezentată diagrama de clase a serverului ClientTaxi. Proiectul ClientTaxiServer este alcătuit din 2 aplicații: clientTaxiServer și ClientTaxi.

În aplicația ClientTaxi sunt descrise modelele care le vom avea in proiectul ce ține de server și dependențele între ele.

GPSCoordinates – reprezintă coordonatelor: longitudine, latitudine și ora

UserClient – reprezintă toate campurile necesare pentru a păstra un utilizator de tip Client Comandă in baza de date prin intermediul modelului

UserTaxi – reprezintă toate campurile necesare pentru a păstra un utilizator de tip Client Taxi in baza de date prin intermediul modelului

Commands – reprezintă toate campurile necesare modelului pentru a reține comenzile

În apicația ClientTaxiServer avem descrise url-urile care pot fi accesate, baza de date, vederile care formează pagini sau raspunsuri care vor fi afișate sau distribuite plus cateva modele javascript pentru a distribui elementele in pagină.

În views avem reprezentarea a ceea ce vrem sa afisam in paginile noastre. De exemplu dacă avem un url de forma http://localhost:8000/maps/ – url(r'^maps/', 'google_map') se va executa vederea de la indicele maps astfel conținutul returnat conține ce returnează funcția google_maps.

Display_info – returneza informații utile clienților in funcție de parametrul care vine pe intrare. Poate returna toate comenzile care sunt valide, poate introduce în baza de date o noua comandă, să modifice starea unei comenzi.

Google_maps – returnează pagina care va afișa pe web harta noastră cu punctele care vrem să le evidențiem

În urls avem descris modul in care putem accesa datele de pe server. Url-urile la care va răspunde serverul

.

url(r'^admin/', include(admin.site.urls)) – te duce la panoul de administrator al serverului

url(r'^maps/', 'google_map') – te duce la o reprezentare grafica pe o hartă de la google maps a tuturor clienților

url(r'^$', 'display_info') – oferă date clienților pentru schimbulde informații

În Sqlite3 avem baza de date a sistemului care este creată de catre django in spatele aplicațtiei.

În models avem descrise cateva fisiere javaScript care ne ajută la reprezentarea datelor pe server.

5.3 Diagrama de secvență

Figura 5.3.1 Diagrama de secvență

În figura 5.3.1 este reprezentată diagrama de secvență pentru cazul de utilizare a trimiterii de mesaje cu coordonatele către server. Atunci când clientul incearcă să trimită coordonatele către server acesta incearcă sa le citească și verifică dacă acuratețea este suficient de bună. După ce coordonatele au fost acceptate sunt puse intr-un obiect pentru a putea fi trimise catre server. Apoi se crează un obiect JSON pentru a fi trimis mesajul către server. Apoi se face un HTTPREQUEST cu parametru acel mesaj JSON.

După ce a fost trimis către server primește n mesaj de confirmare cum că mesajul a fost trimis cu succes.

5.4 Diagrama de deployment a aplicației

Figura 5.4.1 Diagrama de deployment a sistemului

În figura 5.4.1 este reprezentată diagram de deployment a sistemului. Aplicația de server are facut deply-ul pe un server local python, care suportă si integrarea sqlite3 pentru a putea reține si baza de date. După cum a fost menționat anterior comunicația intre părți este de tip cerere-răspuns. Aplicațiile android fac cereri către aplicația server pentru a primi anumite date sau structuri de date. Serverul procesează mesajele primite de la clienți si le trimite acestora un raspuns.

În cadrul serverului exista o logică de business care se ocupa de prelucrarea datelor si mesajelor ce vin la server de la aplicațiile client, astfel încât sunt introduse corect in baza de date atât comenzile efectuate de clienții de pe aplicația ClientComandă cât si asignarea la anumite comenzi ale clienților de tip ClientTaxi. De asemenea dintr-un interval in altul de timp serverul trimite către clienții de tip ClientTaxi o listă a tuturor cererilor aflate in derulare.

În ajutorul serverului python a fost folosit si un parser de mesaje Json. Acesta este folosit pentru codificarea mesajelor pentru a putea fi trimise către aplicațiile de tip client dar si pentru a decodifica mesajele primite atât de la ClientComandă cât si de la ClientTaxi.

5.5 Diagrama cazurilor de utilizare

Figura 5.5.1 Diagrama cazurilor de utilizare a aplicțtiei ClientTaxi

Caz de utilizare: Efectuare comandă

Actor principal: ClientComandă

Descriere: Acest caz de utilizare descrie modul de trimitere unei comenzi către server prin intermediul unui mesaj Json.

Fluxul de succes

Clientul pornește aplicația

Așteaptă până este localizat prin gps si are coordonatele valide

Dă un nume comenzii

Apasă butonul de efectuare a comenzii

Mesajul se trimite către server pentru a putea fi pus in baza de date

Primește o notificare cum ca a fost o comandă trimisă cu succes

Fluxuri alternative:

Cade conexiunea la internet: daca nu este conexiune la internet clientul este in incapabilitate de a trimite mesaje către server. Deasemenea dacă serverul nu este online nu se pot trimite date către acesta

Se uită introducerea de nume pentru comandă. În acest caz comanda nu este trimisa catre server.

Dacă clientul incearcă sa facă o comandă până sa fie localizat corect prin gps adică până sa aibă o anumită acuratețe cererea de comandă nu este trimisp către server.

Caz de utilizare: Urmărirea taximetristului pe hartă

Descriere: Clientul poate sa vadă poziționarea taxiului asignat comenzii respective pe harta acestuia iar poziția acestuia se schimbă dintr-un interval de timp in altul.

Actor principal: ClientComandă

Flux de succes

Primește notificare că a fost un taximetrist asignat comenzii

Urmarește pe hartă pozitionarea taxiului

Fluxuri alternative

În cazul in care cade conexiunea la internet nu mai este posibila urmărirea clientului de taxi.

In cazul in care mesajele despre clientul de taxi sunt eronate utilizatorul vede o poziționare eronată a acestuia.

Cerinșe speciale

Clientul trebuie sa fie conectat la internet pe tot parcursul desfașurări fluxului de sosire a comenzi.

Serverul trebuie sa fie tot timpul online.

Fig 5.5.2 Diagrama cazurilor de utilizare a aplicației ClientTaxi

Caz de utilizare: Asiganrea la o comandă

Descriere: Orice clientTaxi va primi o lista cu cererile disponibile si vor putea alege sa se asigneze la oricare din ele.

Actor principal: ClientTaxi

Fluxul de succes

Utilizatorul așteaptă până este încărcată lista de comenzi disponibile

Acesta isi alege o comandă (apasând pe aceasta in lista disponibilă pe ecran)

Asteapta mesaj de la server pentru a sti că i-a fost alocată comanda

Fluxuri alternative

Cade conexiune la internet, in acest caz nu se mai poate realiza asignarea si reîmprospatarea listei de comenzi.

Dacă serverul cade de asemenea nu se mai paote realiza asignarea la o cererea respectivă a taximetristului

Cerințe speciale

Existența unei conexiuni stabile la internet

Figura 5.5.3 Diagrama cazurilor de utilizare a administratorului de Server

Caz de utilizare: Vizualizare pe hartă doar a taximetriștilor

Descriere: Toți utilizatorii de tip Taxi vor fi afișați pe hartă

Actor principal: Administrator Server

Fluxul de succes

Administratorul acceseaza adresa server-ului

Administratorul accesează adresa pentru hărți

Administratorul selectează afișarea doar a utilizatorilor de tip Taxi

Fluxuri alternative

În cazul în care se pierde conexiunea la internet nu se mai pot efectua aceste operații

Caz de utilizare: Ștergerea unui taximetrist

Descriere: Se șterge un taximetrist accesând pagina destinată acestor si selectând comanda de „remove” vom sterge taximetristul dorit

Actor principal: Administrator Server

Fluxul de succes

Administratorul acceseaza adresa server-ului

Administratorul accesează adresa pentru utilizatorii de tip Taxi

Administratorul selectează taximetristul dorit

Administratorul selectează comanda de ștergere a acestuia

Administratorul efectuează comanda de ștergere

Fluxuri alternative

În cazul în care se pierde conexiunea la internet nu se mai pot efectua această operații

5.6 Structuri de date

Baza de date a sistemului este una sqlite3. Este cea mai folosită bază de date, este ușor de integrat cu python și se poate accesa foarte ușor datele din acestea. In figura 5.6.1 este prezentată diagrama bazei de date. În total sunt 4 tabele cu legaturi între ele. Tabele reprezintă modelele serverului python.

Cele 4 tabele sunt:

GPSCoordinates

ClientUser

ClientTaxi

Commands

Figura 5.6.1 Diagrama bazei de date

În tabela GpsCoordinate sunt pastrate coordonatele tuturor utilizatorilor. Pentru fiecare grup de coordonate avem nevoie de urmatoarele câmpuri: latitude, longitude și timestamp. Cele două câmpuri care reprezintă pozționarea pe harta a utilizatorilor sunt primite de la gps-ul dispozitivelor si sunt păstrate in baza de date pentru a putea ști locația unde se află dispozitivele și pentru a putea fi afișate pe hartă.

Ora la care au fost luate datele este păstrată pentru a putea ști exact la un anumit timp unde s-a aflat dispozitivul.

În tabela UserClient și UserTaxi sunt păstrate UUID-urile dispozitivelor pentru a le putea deosebi și coordonatele unde se aflau acestea.

Tabela Commands pastrează comenzile efectuate de clienții care fac comenzi, de asemenea ese si un câmp pentru a păstra uuid-ul dispozitivului taxi care a preluat o anumită comandă. Tot odată păstrăm si coordonatele unde trebuie să se intâlnească taximetristul cu clientul care a făcut comanda.

Legătura intre baza de date si sistem este făcută cu ajutorul modelelor descrise in Django. Fiecarui model ii corespunde o tabelă in baza de date. De asemenea mai sunt create si alte tabele auxiliare care provin din relațiile dintre modelele descrise.

Figura 5.6.1 Maparea obiectelor din Django

În figura 5.6.1 sunt prezentate cateva din mdele folosite de către django. Aici sunt prezentate GpsCoordinate si UserClient, acestea având similar in baza de date. Fiecare câmp din model are si un corespondent in baza de date. De exemplu modelul UserCLient are variabila coordinates de tip GPSCoordinate asta inseamna ca in tabela UserClient vor fi prezente toate câmpurile ce le are variabila de tip GSPCoordinate cum ar fi: longitude, latitude . timestamp.

5.7 Interfața grafică

Interfața grafică a parții client este constituită din 2 ecrane pentru fiecare aplicație client. Fiecare aplicație are funcționalități separate. Prima aplicație are funcționalitatea de a efectua comenzi iar cea de a doua are funcționalitatea de a viziona comenzile active si de a se asigna la una din ele. Fiecare din ecranele cu care este întâmpinat un utilizator a fost modelat folosind controale predefinite în SDK Android.La fel ca multe alte tehnologii proiectarea interfețelor utilizator în Android este bazată pe conceptul de event handling.

5.7.1 Interfața grafică a aplicației ClientComandă

În figura 5.7.1 ste prezentat ecranul cu care este intampinat utilizatorul aplicației atunci cand acesta intră in aplicație. Inițial toate câmpurile nu sunt intializate. Utilizatorul poate vedea deocamdată numai ora actuală. De asemenea poate vedea si viteza cu care acesta se deplasează in cazul in care se deplasează.

Pe fundal ecranul conține o harta globului si este o vedere de ansamblu deoarece dispozitivul nu este încă localizat. De asemenea apar si câmpurile pentru introducerea numelui comenzii cât si butonul de comandă.

În această fază utilizatorul trebuie să aștepte până la localizarea acestuia prin gps pentru a putea fi afișată poziția lui pe hartă, în cazul în care acesta nu este localizat el trebuie să verifice conexiunea acestuia la internet și să vadă dacă gps-ul este pornit.

Figura 5.7.1 Ecran de întâmămpinare

În figurile 5.7.2 și 5.7.3 este prezentată aplicația dupa ce au fost stabilite coordonatele gps ale sistemului se actualizează câmpurile corespunzatoare acetuia. Acum clientul este pregătit să isi introducă numele comenzii si sa efectueze o comandă.

Figura 5.7.2 Ecran pentru selecție comandă

Fig 5.7.3 Ecran pentru efectuarea comenzii

Cu ajutorul butoanelor din partea stângă a ecranului se poate mări scara hărți sau micșora. Implicit este un zoom calculat in funcție de acuratețea datelor care sunt primite prin gps (latitudine, longitudine).

5.7.2 Interfața grafică a aplicației Client Taxi

Figura 5.7.4 Lista de comenzi

În figura 5.7.4 este prezentată o listă de comenzi care este activă in perioada respective. Este si primul excran al aplicației și acesta se reîmprospătează tot odată la 15 secunde. Acestea sunt toate comenzile la care se pot asigna utilizatorii aplicației Client Taxi.

Figura 5.7.5 Asignarea la o comandă

Când un taximetrist dorește să se asigneze la o comandă acesta își allege din listă comanda pe care vrea să o onoreze și apasă pe ea

5.7.3 Interfața grafică a aplicației Sever Client Taxi

Pe partea de server avem un administrator care poate controla de pe adresa locală a server-ului. Acesta poate face urmatoarele:

Vizualizare coordonate introduce pe server

Vizualizare utilizatori care fac comandă

Vizualizare utlizatori care se asignează la comenzi

Ștergere utilizatori

Ștergere coordinate

Vizualizare pe hartă a tuturor utilizatorilor si locurile pe unde au fost aceștia

Figura 5.7.6 Panoul de admin

În figura 5.7.6 este prezentată interfața pe care o vede administratorul când accesează pagina de start a panoului de administrare. De aici administratorul are mai multe obțiuni:

Vizualizare coordonate

Vizualizare utilizatori care efectuează comenzi

Vizualizare utilizatori care se asignează la comenzi

Figura 5.7.7 Panoul de Coordonate

În figura 5.7.7 este prezentată interfața ce apare atunci când este accesată secțiunea dedicate coordonatelor. Aici se pot vizualiza toate coordonatele introduse pe server. Tot de aici se pot șterge anumite coordinate. Le putem selecta din parte stângă bifându-le pe cele care dorim să le ștergem. Apoi select operația de stergere a acestora de la „Action”. Dupa care apăsăm butonul „Go” și acestea vor fi sterse.

Figura 5.7.8 Panoul Clineților care au efectuat comenzi

În figura 5.7.8 este prezentat panoul tuturor clienților care au făcut comenzi. De aici putem alege sa mergem pe oricare din acesta să vedem pe la ce coordonate a trecut (ce coordonate a introdus in baza de date). De asemenea putem sterge orice utilizator care a efectuat comenzi. Această operație este similară cu cea prezentată la coordonate.

Figura 5.7.9 Panoul pentru coordonatele unui anumit taximetrist

În figura 5.7.9 este prezentat panoul coordonatelor unui taximetrist. De aici putem vizualiz toate coordonatele prin care acesta a trecut. Această opțiune o avem atât la utilizatorii de tip taximetrist cât si la cei care efectuează comenzi.

Serverul poate sa recunoasca de pe același dispozitiv mobil atât un client de tip taximetrist cât și unul de tip utilizator care face comandă. Toate comenzile effectuate de pe același dispozitiv sunt trecute in baza de date la același utilizator.

În background pot rula ambele aplicații dar nu este indicat să facem acest lucru deorece nu ar funcționa sistemul correct in cazul in care incercăm sa ne asignăm la o comandă facută de pe același dispozitiv.

Figura 5.7.10 Panoul de vizualizare pe hartă a utilizatorilor

În figura 5.7.10 este prezentat panoul de vizualizare pe hartă a utilizatorilor. Pe fiecare ii avem atașați la categoria din care fac parte.Îi putem identifica după culoare, fiecare având cate o culoare diferită si unică. Putem selecta să vedem pe hartă toți utilizatorii sau doar pe cei care dorim. Sau putem sa alegem sa vizualizam numai o categorie dintre aceștia fie numai taximetriștii fie numai utilizatorii care au efectuat comenzi.

Putem avea un utilizator care apare și la taximetriști cât și la utilizatorii care au efectuat o comandă dar nu putem avea două apariții a aceluiaș dispozitiv la aceași categorie.

Testare și validare

Android oferă un cadru de testare care este integrat în mediul de dezvoltare, de asemenea oferă o arhitectură și tehnici care ne ajută să testăm fiecare aspect al aplicației noastre pentru fiecare nivel.

Framework-ul de testare are urmtoarele caracteristici:

Procesele de testare android sunt bazate pe Junit. Se pot utiliza testele Junit simple pentru a testa o clasă care nu apelează Api-ul de la Android sau se pot testa componenente Android. Un exemplu de test ar fi folosirea „AndroidTestCase”.

Extensia Junit pentru Android oferă clase de test pe baza componentelor specifice. Aceste clase oferă metode de ajutor pentru a crea obiect „mock” și metode care te ajută să controlezi ciclul de viața al componentelor.

Procesele de testare sunt incluse în pachete de testare care sunt similare cu pachetele aplicației.

Instrumentele pentru creat teste sunt disponibile în Eclipse ADT și de asemenea în linia de comandă pentru utilizatorii de alte IDE-uri. Aceste unelte preiau informatia din aplicația proiectului care este sub testare și folosește această informație pentru a crea automat fișiere, structuri de directoare pentru pachetul de testare.

SDK-ul oferă de asemenea „monkeyrunner” care este un API pentru testarea dispozitivelor cu programe Python.

Figura 6.1 Test trecut cu succes

Pentru acest sistem au fost testate componente ale clinetului care se asignează la o comandă. Vom testa elementele componente ale interfeței grafice.

Am făcut teste pentru integritatea lor. Pentru fiecare am verificat existența la afișarea pe ecran și conținutul acestora.

Pentru efectuarea testelor am folosit ActivityUnitTestCase.

În figura 6.1 este prezentat un caz de test care a avut succes.

Figura 6.2 Test care a eșuat

În figura 6.2 este prezentat un test care a eșuat din cauza elementelor componente ale interfeței necorespunzătoare cu acesta.

Manual de instalare si utilizare

7.1 Manual de instalare server

Deoarece sistemul este distribuit este nevoie sa configurăm mai intâi aplicația serverului ca sa putem face sistemul să fie capabil să primească cererile de la aplicațiile client. Aplicațiile client sunt distribuite utilizatorilor sub forma unui fișier cu extensia .apk acesta fiind o arhivă specializată ce definește tipul fișierelor de instalare pentru aplicațiile dezvoltate pentru sistemul de operare Android.

Serverul aplicației: Python + SQLITE3

Aplicațiile client: Sisteme de operare anroid necesare pentru rularea acestora

Pentru a putea rula codul Serverului scris in Python avem nevoie să instalat pe calculatorul nostru python 2.7. Alături de acesta mai avem nevoie si de Django pentru a putea rula codul, deoarece am folosit framework-ul Django. De asemenea mai trebuiesc instalate si cateva librării care au fost folosite (cea pentru parsarea json și cea pentru parser-ul de arbori).

Pașii de instalare python și Django sunt:

Instalare Python 2.7 ( http://www.python.org)

Instalare pip

Instalare django ( „ pip install Django” )

Pornire server Django din Command line. Ne ducem in interiorul fișierului unde avem codul sursa pentru proiectul de server apoi vom executa comanda „python mange.py runserver 0.0.0.0:8000” pentru a porni serverul local

După ce pornim serverul local vom merge în localhost din browser și vom testa funcșionalitatea serverului

În cazul în care avem o bază de date vom copia fișierul acesteia in proiectul nostru inainte de a porni serverul pentru a restabili baza de date.

De asemenea serverul python poate rula și online dacă este pus pe un server care are capabilitatea de a rula proiecte python.

7.2 Manual de instalare client

Pentru a instala oricare din aplicațiile client avem nevoie de dispozitive cu un sistem de operare android instalat pe acesta.

După ce avem dispozitivul pe care dorim sa efectuăm instalarea fie adăugam prin cablul usb fișierele cu extensia .apk ale aplicațiilor și după le instalam de pe telefon, fie le instalăm direct din Eclipse unde avem codul sursa astfel instalarea se va face automat.

7.3 Manual de utilizare server

Pentru a folosi serverul local trebuie sa ne asigurăm ca portul 8000 este liber deoarece vom incerca pornirea serverului pe acel port. În cazul în care portul nu este liber fie deschidem severul pe alt port fie eliberăm acel port. Serverul se porneste din command line-ul windows-ului cu ajutorul comenzii „python manage.py runserver 0.0.0.0:8000”. După ce serverul este pornit practic putem incepe sa facem schimb de date intre aplicațiile de tip client.

Pentru a putea avea acces la panoul de administrator al serverului trebuie sa ne autentificăm la acesta folosind un super utilizator creat la instanțierea bazei de date (super utilizator care provine de la folosirea framework-ului Django).

Putem accesa următoarele adrese:

Localhost:8000/admin

Localhost:8000/maps

Pe partea de admin a server-ului putem vizualiza coordonatele introduse in sistem, toți utilizatorii existenți și toate coordonatele ce le corespund acestora. De asemenea de aici mai putem si sa facem operații de ștergere asupra bazei de date.

Pe partea de hărți administratorul poate viziona poziționarea tuturor utilizatorilor cât și drumul pe care aceștia l-au parcurs pe harta. Acesta poate sa iși aleagă sa observer pe harta numai un anumit grup de utilizatori sau numai un tip din aceștia (de exemplu sa vadă numai clienții care au efectuat comenzi).

Harta de modifică in funcție de spectrul pe care il ocupă coordonatele tuturor utilizatorilor selectați pentru a fi desenați pe hartă.

Serverul de asemenea poate fi ținut si online pe o platformă ce suportă python.

7.4 Manual de utilizare client

7.4.1 Manual utilizare aplicație ClientComandă

Se instalează fișierul cu extensia .apk pe un dispozitiv cu un sistem de operare Android pe acesta

Se pornește GPS-ul și wireless-ul dispozitivului (pentru a funcționa aplicația are nevoie de ambele in stare de funcționare)

Se intră in aplicație se așteaptă localizarea prin gps a telefonului

Se poate efectua o comandă dar numai dupa ce a fost introdus un nume de comandă

7.4.2 Manual de utilizare aplicație Client Taxi

Se instalează fișierul cu extensia .apk pe un dispozitiv cu un sistem de operare Android pe acesta

Se pornește GPS-ul și wireless-ul dispozitivului (pentru a funcționa aplicația are nevoie de ambele in stare de funcționare)

Se intră in aplicație și se așteaptă incărcarea comenzilor active

Se alege o comandă la care vrem sa ne asignăm

Așteptam până se efectuează asignarea și apoi putem onora comanda

Concluzii

Implementarea curentă a proiectului „SISTEM INTELIGENT DE COMANDĂ TAXI PENTRU TELEFOANELE MOBILE” este doar in faza de test. Aceasta poate fi scoasă pe piața aplicațiilor Android dar ar mai trebui puțin modificată partea grafică a acesteia. După ce aplicația va fi lansată in versiunea beta pe „Market”, care este o versiune neplătită se vor putea colecta păreri ale utilizatorilor aplicției despre utilitate acesteia. Pe baza părerilor utilizatorilor se vor putea imbunătăți funcționalitățile si interfața utilizatorului.

„SISTEM INTELIGENT DE COMANDĂ TAXI PENTRU TELEFOANELE MOBILE” este o aplicație care poate fi folosită in orice oraș din țară deoarece aceasta suportă localizarea in orice oraș. Deoarece este o aplicație bine definită adaugarea unor noi funcționalitșți se va realiza ușor deoarece codul a fost conceput incă de la începuturi pentru a putea suporta eventuale imbunatățiri pe viitor. De asemenea și aplicația de server poate fi extinsă foarte ușor pentru adăugarea de noi funcționalități.

Posibile dezvoltări ulterioare ale proiectului sunt următoarele:

Introducerea de alerte audio in cazul apariției a unei noi comenzi

Cele două aplicații sa fie mutate in una singură

Implementarea unui sistem de penalizare eficient in cazul in care nu sunt respectate condițiile impuse de aplicații (nerespectare comenzilor sau nepreluarea acestora după asignarea la acestea)

Scalarea sistemului pentru a putea suporta un număr mai mare de utilizatori

Dezvoltarea aceleași aplicații pe IOS și Windows Phone

Integrarea unui nou modul in care sa iti poți vedea un istoric al comenzilor efectuate sau a comenzilor la care te-ai asignat

Integrarea unui modul de prezentare a unor spoturi publicitare in timp ce aștepți sa ajungă taxiul

Implementarea unui modul de autorecunoștere a numelui ultimei comenzi

Implementarea unui nou modul pe server pentru afisarea istoricului comenzilor

Implementarea pe server a unui modul care permite operații de ștergere si reîmprospătare a listei de clienți care au restricții asupra utilizării aplicaților client

In cazul in care aplicația prinde la utilizatorii din românia aceasta poate fi extinsă pe intreg globul folosind un framework de multi-limbă

Odată cu implementarea acestui sistem am învațat tehnologii noi de programare care mă vor ajuta și in viitor. Una dintre acestea este python și framework-ul atașat acestuia (Django ) cu ajutorul cărora am reușit să construiesc partea de server intr-un mod mult mai plăcut decât dacă aș fi folosit JAVA. Deși a fost depus mai mult efort la învățarea python consider ca a fost o experiență utilă acumulat in acest timp.

O altă parte care a fost interesantă in acest proiect a fost integrarea librăriei pentru harțile celor de la google_maps. Pentru folosirea acestora a trebuit instalate o serie de drivere din SDK Manager.

În implementarea acestui proiect am observat ca o etapă foarte importantă in constituirea proiectului a fost proiectarea acestuia, deoarece cu o proiectare bună lucrurile au mers mult mai bine și modificările ce au intervenit ulterior au fost mult mai usor de realizat și de asemenea imbunatățirile ulterioare vor fi mult mai ușor de realizat.

Bibliografie

Ioan Salomie, “Tehnici orientate pe obiecte”, Editura  Albastra 1995, 362 pagini, ISBN 973921505X;

"Caracteristici ale arhitecturii client/server"

https://sites.google.com/site/ursuleacv/knowledge/principiileprogramariiorientatepeobiecteceestepooclaseobiecteincapsulareamostenireapolimorfismul

http://www.itcsolutions.eu/2011/09/08/android-tutorial-concepte-activitati-si-resurse-ale-unei-aplicatii-android/

http://www.python.org/

https://www.djangoproject.com/

Bibliografie

Ioan Salomie, “Tehnici orientate pe obiecte”, Editura  Albastra 1995, 362 pagini, ISBN 973921505X;

"Caracteristici ale arhitecturii client/server"

https://sites.google.com/site/ursuleacv/knowledge/principiileprogramariiorientatepeobiecteceestepooclaseobiecteincapsulareamostenireapolimorfismul

http://www.itcsolutions.eu/2011/09/08/android-tutorial-concepte-activitati-si-resurse-ale-unei-aplicatii-android/

http://www.python.org/

https://www.djangoproject.com/