Published using Google Docs
Proiect DS
Updated automatically every 5 minutes

Harta interactiva a cantinelor

  Version:           <1.0>

  Date:  <4/04/2011>

Gastronomix.ro

Analysis and Design Document

Crişan Lucian,

30233/30641

 

Revision History

Date

Version

Description

Author

<dd/mmm/yy>

<x.x>

<details>

<name>

Table of Contents

Project Specification

Acest proiect se doreste dezvoltat folosind Java pe partea de gestiune a bazei de date si folosirea de JavaScript pentru afisarea unei harti interactive. Se vor stoca atat programul de functionare, momentele in care se poate servi meniul zilei, sau perioada in care este inchisa locatia. Acest lucru va fi folosit pentru ca utilizatorul sa poata folosi interogari legate de program, de locatii apropiate si altele.

Functional Requirements

        Cerintele de ordin functional sunt cele prezentate in cadrul specificatie. Pe scurt le voi enumera: posibiliatea cautarii dupa anumite criterii, posibilitatea manipularii prin operatii de tip CRUD a tabelelor folosite ca si baza de date, implementarea folosind Google Maps API V3.

Prezentare tehlogie

Tehnologia din pacate este destul de mare, ea fiind prezentata pe http://code.google.com/apis/maps/documentation/javascript/ respectiv pe http://code.google.com/apis/fusiontables/.

Scopul acestui document nu este de a prezenta tehnologia, deoarece mi-a lua aproximativ vreo 10 pagini doar pentru a prezenta o scurta, foarte scurta tehnologie. Consider ca cea mai buna sursa de documentare o repezinta link-urile prezentate mai sus. Esenta invatari acestor tehnologi o reprezinta incercarea exemplelor si nu doar o citire despre tehnologie.

Non-functional Requirements

Pentru prezentarea/exemplificarea acestor cerinte ma voi folosi de scenari.

  1. Availability

  1. Performance

  1. Security

In cazul serviciului de tip client nu exista. Utilizatorul nu are nevoie de autentificare

Voi prezenta doar securitatea pe partea de administrator.

  1. Testability

Se folosesc in special librarii oferite de Google, testate in prealabil de catre dezvoltator. Este astfel nevoie doar de o testare de tip integrare.

  1. Usability

  1. Elaboration – Iteration 1.1

Domain Model

Problema enuntata nu isi doreste sa mentina si informatii complete legate de meniu ci doar timpul in care se poate servi. De asemenea nu se doreste salvarea istoricului cautarii sau posibilitatea de salvarii unor cautari favorite(momentan), si nici posibilitatea de share sau trimitere unui prieten.

Aceasta aplicatie, atat cea de gestiune a bazei de date cat si cea de prezentare folosind JavaScript se axeaza pe modelarea si interogarea pe baza unor orare de functionare. De asemenea se pune accent pe localizare si pe determinarea distantelor.

Architectural Design

Conceptual Architecture

Pentru realizarea acestui proiect am optat pe folosirea unui arhitecturi de tip Layer, pe 3 nivele si MVC. Am ales Layers ca fiind o solutie eleganta pentru separarea car mai vizibila a atributiilor fiecarui pachet. MVC este util pentru a putea schimba usor fie view fie controlul, fara a modifica foarte mult design-ul..

Package Design

Component and Deployment Diagrams

Elaboration – Iteration 1.2

  1. Design Model

Class Design

  1. Data Model

        Modelul “bazie de date” este unul simplu. Cantina este tabela de baza, ceile straine fiind referite doar dinspre acest tabel. Pentru a modela zilele saptamanii, am folosit conceptual numere in intervalul 1..7, care pot fi asociate conceptual cu niste constante.

  1. Unit Testing

Testarea se face folosind testarea de tip integrare. Astfel se testeaza modulele mai mici, iar apoi cand se adauga un nou modul se va testa tot sistemul. Pentru a verifica continutul tabelei se poate folosi si interfata grafica oferita de Google, la adresa tables.googlelabs.com . Momentan sunt inca in faza de “teste” fiind gasite la Google Labs. Trebuie totusi precizat ca desi sunt in faza beta functioneaza mult mai bine decat produsele oferite de alte companii, cum ar fi Microsoft.

Testarea securitatii/logarii si a trimiterii datelor se face mai dificil, deoarece sunt transparente, Google fiind responsabil cu securitatea si cu operatiile de tip HTML post si get ce opereaza pe baza de date.

Elaboration – Iteration 2

  1. Architectural Design Refinement

Nu am avut nevoie sa modific diagrama de pachete, sau comportamentul dinamic al aplicatie.

  1. Design Model Refinement

Incercand sa implementez diagrama initiala am ajuns la concluzia ca aceasta diagrama este corecta in linii mari insa are nevoie si de unele modificari, legate in special de diferenta intre partea teoretica si cea practica a aplicatie. Astfel principalele modificari au aparut la introducerea unor clase abstracte pentru gateway si pentru transaction script. Aceste clase au aparut ca si o necesitate de a nu duplica acelsi cod in toate clasele. Parserul a superit de asemenea modificari in structura sa interna, deoarece initial era gandit continand un HashMap si acum contine 2 matrici de obiecte, o matrice pentru a memora numele coloanelor si alta matrice pentru a memora valoriile din tabel.

        De asemenea am abstractizat si lin partea de prezentare. Astfel am incercat sa obtin o reutilizare cat mai ridicata a codului. Pentru aceasta am incercat ca folosind acelasi Jtabel fiind diferit doar modelul sa pot reprezentata cat mai multe tabele. De asemenea folosind un control extern, obtin comportamentul dorit.

        In acest proiect nu am fost nevoit sa folosesc niciu-un principiu de proiectare cu clase. Principiul OpenClose, de proiectare tinand cont de clasele abstracte, nu l-am folosit. Se putea folosi la AbstractGateway, AbstractTransactionScript, si sa folosesc nume generice de metode, de ex afiseaza, in loc de afiseazaProgram si afiseazaMeniu. Neapliand primul principiu, nu am aplicat nici principiul substitutiei lui Liskov. Nu am aplicat nici dependency inversion, deoarece nu am avut nevoie de a proiecta la nivel de clase abstracte sau de interfata.

        In continuare voi prezenta principiile de design cu pachete pe care le-am folosit. Principiile de coeziune la nivel de pachet sunt respectate. Toate clasele care sunt legate logic au fost incluse in acelasi pachet. Astfel daca am nevoie sa folosesc o clasa folosesc doar acel pachet si clasele de stub, pentru clasele de nivel inferior de care ar avea nevoie. De asemenea in cazul in care apare o modificare aceasta se propaga doar la nivelul acelui pachet. Principiul ADP a fost respectat, deoarece am un sir liniar, in ceea ce priveste dependentele intre pachete. Consider ca am respectat si principiul SDP, deoarece am doar o intrare in fiecare pachet si o iesire din fiecare pachet.

Voi prezenta in continuare partea de client:

a) o diagrama de componente la partea de JS

b) o incercare de diagrama de clase

In aceasta diagrama am incercat sa surprind esenta designului in JavaScript. Unele nume de metode pot sa difere in implementare, in principal datorita coliziunilor de nume ce pot sa apara in fisierele JavaScript.

Numele de clase poate parea impropiu insa in aceasta aplicatie am incercat sa modelez “cat  mai obiectual”. Astfel unele metode pot fi apelate doar in contextul unui obiect, de exemplu: obiect.numeMetoda(param). De asemenea unele atribute pot fi folosite la fel doar in contextul unui obiect, cum ar fi obiect.atribut sau this.atribut.

Cea mai importanta clasa este “Cantina”. Ea contine 3 obiecte foarte importante, cum ar fi “PerioadaInchis”, “ServireMeniu”, “OrarCantina”.  Fiecare acest obiect are asociata o metoda de a verifica daca o cantina este deschisa.  Mai contine si unele atribute, pentru fiecare cantina, cum ar fi locatia, sau adresa web.

Clasa de “DataLoader” se ocupa cu preluarea informatiilor din fusion tables si crearea unor tabele locale, si mai apoi a unor liste de Cantine. In continuare in aplicatie se va lucra cu Cantine in loc de tabele deoarece este mai simplu si mai logic. Odata construit obiectul poti sa il interoghezi daca este deschisa sau nu.

Lista est eo clasa folosita pentru a faca managementul unor obiecte generice. Interfata generica este utila la nivel conceptual ea neexistand ca si fisier. Totusi toate clasele care imprementeza aceasta interfata trebuie totusi sa “implementeze” cele 3 metode enumerate. Astfel aceasta combinatie de lista si interfata generica s-a dovedit foarte utila in a trata unitar cele 3 obiecte.

Clasele de “DataViz” si “MapLayer” sunt folosite petru a popula efectiv pagina de index.jsp. Comunicarea ar fi in mod normal in ambele directii intre aceste clase si pagina HTML, deoarece in JavaScript am definite anumite id iar din JS le pot prelua si manipula.

In continuare voi prezenta o diagrama de deployment si una concetuala a intrebului sistem, atat partea de Java cat si partea de JavaScript.

c) diagrama de deployment

Partea de Google am pus-o “in nori“ deoarece nu se stie exact pe ce servere se gaseste partea de fusion table care se ocupa cu stocarea, si atat mai putin partea de autentificare care este tinuta sub secret.

Pe partea de client, in interfata web se vor gasi atat fisierele de tip JavaScript cat si fisierele(aici unul singur) de tip HML.

Pe partea de administrare, care este facuta in Java va trebui ca pe masina locala sa se gaseasca fisierele Java. Pe aceasta masina se va crea un JFrame care contine aplicatia, in fapt doar niste tabele, ce oferao perspectiva mai “umana” asupra tabelelor din fusion table. Stie sa interpretezele cheile straine, dintre cantine si restul tabelelor dependente de aceasta, afisand doar inregistrarile din meniul zilei asociate cantinei selectate.

d) diagrama de componenete

In diarama se observa ca aplicatia Java comunica cu serverele de la Google folosind HTTP Secure, deoarece este nevoie de autentificare pentru modificarea tabelelor. Tot aici aplicatia este structurata pe 3 layere si anume partea de prezentare, care contine in principal tabele, si alte elemente de swing; partea de logica a aplicatiei este in TransactionScript, aici facandu-se validari si formatari/conversi; in partea de Gateway am fost nevoit sa implementez un driver pentru a transforma datele din fusion table care vin in CSV intr-un format de tip Map

In partea de JavaScrip si HTML aplicatia este structurata pe patternul Public Subscriber(explicit invocation). Aici comunicarea se face folosind HTTP, deoarece nu este nevoie de autentificare pentru interogarea tabelor.

Toata aplicatia poate fi considerata ca fiind structurata pe principiul Data Centered, deoarece avem un container unde punem si luam datele.

  1. Construction and Transition

  1. System Testing

In plus fata de testarea anterioara la nivel de metoda, folosind main pentru unele clase si testarea de integrare am folosit si JUnit 4, pentru clasa AbstractTransactionScript. Am analizat metodele de formatTime2Roman, formatLatLng, formatTime. Prima metoda se ocupa cu translatarea unei date de tip “12/25/11” care este de tip mm/dd/yy in “25,XII, 2011”, care este de tip dd/mm/yyyy care este de tip . Metoda de formatare a latitudinii si longitudinii testeaza daca perechea de latitudine si longitudine este o locatie corecta, adica daca latitudinea este in intervalul [-90.0, 90.0] iar longitudinea este intre [-180.0, 180.0]; in caz contrar se returneaza [0.0, 0.0]. Metoda de formatare a timpului verifica daca o data introdusa de utilizator este corecta din punct de vedere fizic. Se foloseste hh.mm atat pentru formatul de intrare cat si pentru cel de iesire formatat.

Pentru testarea de tip black box am folosit boundary-value analysis. La metoda de formatTime2Roman am ales ca si varianta o data corecta, din punct de vedere calendaristic si pentru datele din afara intervalului am folosit orice data invalida, care are fie o luna sau o zi din luna nepermisa.

Pentru formatLatLng am tratat o conditie in care era o latitudine si longitudine corecta, iar pentru data gresita se poate folosi o data din afara intervalului. Astfel am testat daca introducand o latitudine prea mare sau prea mica la una din situatii sau la ambele.

Pentru formataTime, am incercat un caz corect dar mai difici, in care testez o ora din intervalul PM, deoarece in intervalul AM atat in format cu meridian cat si in cel de tip 24 orele sunt identice.

Pentru metoda de tip white box, cu acces direct la cod, am testat in aceiasi clasa metoda formatTime2Roman. Aceasta metoda are un if, care verifica daca un an apartine secolului 20 sau secolului 21. Am folosit astfel condition testing. Intervalul de valori de imparte in [0..29] si [30..99]. Am dat astfel o valoare din primul interval 11, de la margine 30 si din intervalul al doilea 50.

  1. Future improvements and conclusions

In special in partea de GUI se pot aduce imbunatatiri, la partea de refresh. In ceea ce priveste JavaScript am inceput inlocuirea Fusion Layer prin parsarea “manuala” a rezultatului pentru a avea un mai mare control asupra modului de afisare.

Principala concluzie ar fi: “Don’t try this at home” efortul de invatare al tehnologiilor folosite in lipsa unui beneficiu de ordin material este prea mare. Pentru stapanirea cu succes a celor doua saptamani estimez ca dureaza minin 3 ore pe zi timp de 1 luna, la 5 zile pe saptamana. Consumator de timp este partea de Java necesara accesului la baza de date si aproape toata partea de client in lipsa unui mediu cu debuger corespunzator.

Pe viitor as vrea sa ofer o solutie de localizare si pentru desktop si laptori, alta decat IP. Acesasta presupune folosirea unui modul de GPS, de genul Copernicus de la SparkFun.com sau varinate disponibile si in Romania prin TME sau prin Farnell. Presupune folosirea interfetei de USART(UART) al modului si eventual a unui bridge de la FTDI(FT232R[L]) sau de la Prolific(Prolific 2303), in cazul in care nu avem port de Serial.

Reamintesc( sau daca nu precizez acum) ca am folosit Eclipse Gallileo 3.5.2, si un plug in de interfete numit Visual Editor(care acum nu mai exista...) deci s-ar putea sa existe unele probleme de compatibilitate.

Manual de instructiuni

Pentru folosirea apliciei de Java:

  1. Mai intai trebuie sa alegem daca avem proxy sau nu.
  2. Se va introduce username-ul si parola de GMail.
  3. In tabelul de sus sunt prezentate o lista a locatiilor, iar in partea de jos se gasesc un numar de 3 tabele necesare pentru stocarea informatiilor. Ambele panels au operatii de inseare in view, inserare in tabel(commit al ultimei linii adaugate in view) sau de stergere.
  4. Voi prezenta in continuare operatia de afisare a tuturor tabelelor si informatiilor legate de o locatie:
  1. Din tabelul din partea de sus se va selecta folosind click o locatie.
  2. Se va apasa pe “Selectare cantina”
  3. Informatiile vor aparea in partea de jos
  1. In continuare voi prezenta operatia de adaugare a unei noi inregistrari fie in partea de sus fie in cea de jos:
  1. Mai intai se va insera un rand nou in view, folosind “Insert in view”. Are rolul de a introduce doar la nivel de vedere, fara sa se reflect in baza de date
  2. Casutele pot fi de tip editabil sau nu; fiecare casuta daca dam hoover peste ea se va afisa un mesaj de informare asupra continutului si a formatului(! aceste informatii nu apar si pe headerul de tabel, doar pe randurile din el).
  3. Odata introduse datele dorite in view, recomand sa se dea click pe prima coloana, altfel daca avem selectata o casuta editabila, chiar daca are contiut se va considera cu continut nul.
  4. Daca am terminat de editat randul dorit, atunci se va apasa pe “Inserare in tabel” care are rolul de commit, facand salvarile in tabel
  1. Se va prezenta operatia de modificare a unui inregistrari, care se poate face fie in tabelul de sus, fie in tabele de jos.
  1. Se va da click pe randul dorit, apoi se va da click pe coloana care se vrea modificata.
  2. Recomand aplicarea strategiei prezentate la punctul e) subpunctul iii)
  3. Daca se va da click pe alt rand atunci se va face modificarea acelui rand, updatarea facandu-se in functie de randul selectat prin click.
  4. Se va da click pe “Modificati” pentru a se face updatarea si in baza de date
  1. Operatia de stergere este cea mai simpla operatie, facandu-se prin selectarea randului dorit si apoi se va da “Sterge”.

                Toate aceste operati au (ar trebui sa aiba) ca si efect un refresh al interfetei Java.

        Voi prezenta si un scurt manual de instructiuni pentru aplicatia in web browser.

  1. In partea de sus a aplicatie este o harta insotita de o legenda, cred eu destul de explicativa. In partea de jos sunt o serie de filtre puse la dispozitie.
  2. In prima sectiune se poate transforma o adresa intr-o locatie de GPS, are ca si efect si updatarea pozitie curente din harta.
  3. In sectiunea urmatoare se pot preciza anumite filtre pentru cautare.
  4. In sectiunea urmatoare se precizeaza ce filtre vor fi folosite la cautare(se va face un AND intre conditii)
  5. Se poate alege si mijlocul de transport de la pozitia noastra pana la ultima locatie pe care s-a dat click.
  6. In ultima sectiune se prezinta o lista cu rezultatele obtinute. Un click pe un element al acestei liste are ca si efect afisarea informatiilor pe harta de la locatia selectata.
  7. In partea de sus prin “Refresh my map” se face o reincarcare din tabele a tuturor locatiilor; in rest operatiile de filtrare facandu-se local, pe o copie a bazei de date “transformata” intr-o lista de obiecte.

  1. Bibliography

Recomand ca si utilitare pentru testarea codului:

Crisan Lucian, UTC-N

Page 9 of 9