Upload
grigore-rusnac
View
97
Download
1
Embed Size (px)
DESCRIPTION
Continutul tezei de licența
Citation preview
Cuprins
Introducere .................................................................................................................................................10
1. Analiza domeniului de cercetare ...........................................................................................................12
1.1 Descrierea sistemelor existente ...........................................................................................................12
2. Dezvoltarea sistemului ................................................................................................................................. 17
2.1 Descrierea structurii sistemului...........................................................................................................17
2.2 Descrierea softului utilizat ..................................................................................................................21
2.2.1 Descrierea NetBeans IDE ................................................................................................................ 22
2.2.2 Descrierea Android Studio .............................................................................................................. 22
2.2.3 Descrierea Enterprise Architect ....................................................................................................... 23
3. Proiectarea și implementarea sistemului ...................................................................................................... 25
3.1 Tehnologii utilizate .............................................................................................................................25
3.2 Documentul cerințelor de sistem ........................................................................................................27
3.3 Proiectarea sistemului de intercomunicare mobil - desktop ...............................................................28
3.3.1 Diagramele de clase ale aplicației desktop ...................................................................................... 28
3.3.2 Diagramele de clase ale aplicației Android ..................................................................................... 31
3.3.3 Diagramele de activitate ale aplicației desktop ............................................................................... 35
3.3.4 Diagramele e activitate ale aplicației Android ................................................................................ 37
4. Organizarea economică ................................................................................................................................ 39
4.1 Scopul realizării proiectului și cercetări de marketing ........................................................................39
4.2 Plan calendaristic .................................................................................................................................39
4.3 Analiza SWOT .....................................................................................................................................42
4.4 Calculul indicatorilor economici..........................................................................................................43
4.4.1 Bugetul.............................................................................................................................................. 43
UTM 526.1.260 ME
Mod. Coala Nr. document Semnat. Data
Elaborat
Sistem de intercomunicare mobil - desktop
Litera Coala Coli
Conducător 8 51
Consultant UTM FE
C - 112 Contr. norm.
Aprobat
4.4.2 Uzura activelor pe termen lung ........................................................................................................ 44
4.4.3 Consumuri directe privind retribuirea muncii...................................................................................44
4.4.3 Costul de producție ...........................................................................................................................46
5. Concluzii ...................................................................................................................................................... 48
6. Bibliografie ................................................................................................................................................... 49
ANEXA 1 Diagrama de clase a modului Communication. .............................................................................. 50
ANEXA 2 Diagrama de activități pentru Trimiterea mesajului. ...................................................................... 51
ANEXA 2 Diagrama Gantt. ............................................................................................................................ 512
UTM 526.1.260 ME Coala
9
Mod Coala Nr. document Semnat. Data
Introducere
În zilele noastre comunicarea utilizând telefonul, calculatorul, tabletele este ceva frecvent întâlnit și de
neînlocuit. Oricând în timpul zilei poți transmite un mesaj, telefona, face un video apel, te poți plimba pe net,
etc. toate astea sunt posibile datorită implementării protocoalelor de comunicare între dispozitive.
Comunicare între dispozitive presupune diferite standarde, nu doar de prelucrare a datelor cât și de
vizualizare a lor.
Cu apariția WiFi-lui pe dispozitivele mici, cum ar fi telefoanele, posibilitatea de a comunica prin
intermediul internetului cu dispozitivele de dimensiuni mici s-a ușurat semnificativ. Actualmente sunt
miliarde de dispozitive care utilizează standardul WiFi de acces în rețea, începând cu telefoanele și finisând
cu computerele.
Dimensiunile diferite ale dispozitivelor presupune diferite forme de manipulare cu ele. Evoluția
manipulării cu dispozitivele de comunicare este un proces inevitabil care va afecta și mai mult structura
transmiterii de date. Un exemplu al evoluției manipulării cu dispozitivele mici este procesul handover sau
handoff, ceea ce reprezintă transferul de apeluri și date de la telefon la un computer (tabletă, alt telefon, etc)
printr-un canal în rețea.
Rezultatul implementării acestui proiect va fi o aplicație la bază căreia va fi implementat procesul
handover/handoff, fiind atașat unui canal de comunicare dintre un computer și un telefon mobil cu Android
OS. Aplicația de pe telefon va avea funcția de transmite a controlului asupra funcțiilor de baza ale telefonului
spre manipularea acestora de către aplicația de pe computer.
Filosofia aplicațiilor de acest gen este reducerea maximă posibilă a manipulării directe cu telefonul,
permițând utilizarea funcțiilor lui fără atingere. Telefonul se poate afla în aceeași rețea ca și computerul, sau
în rețele diferite, această posibilitatea va fi oferită de plasticitatea metodelor de interconectare a sistemului.
Eficiența acestui tip de aplicații:
1. Utilizarea ei când telefonul este la încărcat la ceva distanță de computer și manipularea cu el este
practic imposibilă.
2. Aflarea la distanță de telefon, chiar și zeci de kilometri, dar cu o conexiune de internet.
3. Utilizarea telefonului atunci când sunteți înafara zonei de acoperire (dar telefonul se află în zone de
acoperire) prin intermediul aplicației.
La baza proiectului sunt două aplicații, una din ele este pe computer iar cealaltă pe telefon. După cum
cunoaștem Android OS este o sistemă de operare scrisă în Java, același limbaj este folosit și la crearea
aplicației pe computer. Deci cauze legate de programare sunt:
UTM 526.1.260 ME Coala
10
Mod Coala Nr. document Semnat. Data
1. Aprofundarea cunoștințelor în limbul Java.
2. Cunoașterea metodelor de programare pe platforma Android.
Conform denumirii temei cauzele sunt:
1. Implementarea protocoalelor ce comunicare prin rețea.
2. Crearea unui canal de comunicare pe baza soclurilor TCP.
3. Utilizarea metodei de transmitere a mesajelor broadcast în procesul de conectare.
4. Implementarea procesului handoff/handover.
Piața aplicațiilor pe platforma Android este în continuă creștere, ceea ce motivează dezvoltarea și crearea
aplicațiilor pentru a suplini absența sau necesitățile pieței. Alegerea acestei teme posedă o bună perspectivă
de angajare în viitor ca dezvoltator Android, sau Java. Ca fiind un tip nou de aplicație ce reprezintă un
domeniu parțial necunoscut, deci are un potențial enorm de dezvoltare.
UTM 526.1.260 ME Coala
11
Mod Coala Nr. document Semnat. Data
1. Analiza domeniului de cercetare
Conform introducerii, aplicația va ocupa un spectru relativ îngust al pieței ce necesită acest tip de
serviciu, deci este nevoie de a cunoaște specificațiile acestui tip de aplicație pentru proiectarea și
implementarea corectă a sistemului ce va putea oferi o concurența adecvată.
Handoff/Handover se împarte în două tipuri:
1. Hard – reprezintă transferul canalului de comunicare dintre telefon și antena GSM către o altă antenă
GSM, numai după distrugerea canalului cu prima antenă GSM. Astfel de transfer mai este numit și
break – before – make. Handoff/Handover – ul hard este destinat de a fi instantaneu, cu scopul de a
reduce la minim perturbarea apelurilor. Un transfer de la o antenă la alta în timpul apelului este greu
de realizat deoarece el nu este un eveniment de rețea. Când un telefon se află între două antene, el
poate comunica cu ambele din ele, creând și distrugând canale de comunicare, acest fenomen se mai
numește ping – pong.
2. Soft – reprezintă utilizarea canalelor de comunicare atât cu antena 1 GSM cât și cu antena 2 GSM în
paralel pentru o perioadă de timp, astfel se stabilește conexiunea cu antena 2 GSM înainte de
distrugerea canalului de comunicare cu antena 1 GSM, acest tip de handoff/handover se numește
make – before – brake. Intervalul în care două conexiuni sunt utilizate în paralel poate fi scurt sau de
o durată semnificativă. Din acest motiv handover/handoff – ul soft poate fi perceput ca un eveniment
de rețea. Handover/Handoff – ul soft poate folosi conexiunea la mai multe antene paralel. Când un
apel de intrare apare atunci pentru comunicare este ales cel mai fiabil canal, sau pot fi utilizate mai
multe canale concomitent pentru a produce o copie mai clară a semnalului
De asemenea handover/handoff – ul poate fi clasificat în dependența de tehnica utilizată
1. Handover/Handoff controlat de rețea
2. Asistent handover/handoff pentru telefon mobil
3. Handover/Handoff controlată mobil
1.1 Descrierea sistemelor existente
O categorie nouă în conceptul de handoff/handover sunt aplicațiile handoff/handover, care realizează
transferul de servicii și date către o aplicație pe un alt dispozitiv.
Actual sunt doi reprezentanți ai acestei categorii pe piață:
1. AirDroid 3 (Android OS)
2. Continuity (iOS)
UTM 526.1.260 ME Coala
12
Mod Coala Nr. document Semnat. Data
AirDroid 3 este un răspuns comercial la tehnologia Continuity a companiei Apple. Este o aplicație de tip
handoff/handover ce ușurează manipularea cu telefonul mobil pe bază de Android OS. Aplicația desktop
AirDroid este disponibil pe Windows, Mac si Linux, de asemenea este și aplicația pe Android OS ce se poate
descărca de pe Google Play.
Metodele de interconectare afectează foarte mult comoditatea utilizării sistemului, AirDroid se poate
interconecta prin două metode:
1. Directă – conexiunea se realizează pe baza scanării rețelei de către aplicația de pe calculator, după
care are loc schimbul de date de conectare cu clientul găsit și interconectarea aplicațiilor.
Figura 1.1 Schema conectării directă AirDroid 3.
2. Remote – în acest caz pentru realizarea conexiuni este nevoie de date adăugătoare, cum ar fi adresa IP
și portul de comunicare cu dispozitivul ce se află în altă subrețea decât cea locală.
Figura 1.2 Schema conectării remote AirDroid 3.
UTM 526.1.260 ME Coala
13
Mod Coala Nr. document Semnat. Data
Prin interconexiune directă se subînțelege interconectarea dispozitivelor ce se află în aceeași rețea, adică
au un router sau nod de rețea comun.
Procesul de comunicare are loc astfel:
Figura 1.3 Schema procesului de comunicare în AirDroid 3.
Printre funcționalități ale AirDroid 3 se enumeră:
1. Citirea/Scrierea mesajelor
2. Oglindirea notificărilor
3. Preluarea apelurilor
4. Conectarea mai multor dispozitive concomitent
Continuity pe iOS care are suport odată cu iOS 8 și OS X Yosemite, este o aplicație de tip
handoff/handover care este specifică doar dispozitivelor de la Apple, cum ar fi iPhone, iPan și iPod. Suportul
acestui sistem de către dispozitivele de la Apple nu necesită aplicații terțe, tot este inclus în sistema de
operare.
Comparativ cu AirDroid 3 Continuity are un alt proces de interconectare, care include conectarea la
iCloud pentru verificare ID – lor dispozitivelor ce doresc interconectarea. Doar dispozitivele cu ID – ul
înregistrat sub un singur utilizator pot fi interconectate, în caz contrar interconexiunea va fi respinsă.
Continuity suportă doar conectarea directă, adică suport la conectarea remote nu este. Acesta este un
minus al acestui sistem.
UTM 526.1.260 ME Coala
14
Mod Coala Nr. document Semnat. Data
Figura 1.4 Schema procesului de conectare în Continuity.
Continuity suportă conexiunea la mai multe dispozitive concomitent. Procesul de comunicare arată astfel:
Figura 1.5 Schema procesului de comunicare în Continuity.
Printre principalele funcționalități ale sistemului Continuity se enumeră:
1. Preluarea apelurilor
2. Citirea/Scrierea mesajelor
3. Primirea/Trimiterea email – lor
UTM 526.1.260 ME Coala
15
Mod Coala Nr. document Semnat. Data
4. Sincronizarea activității
Aplicațiile de acest gen actual nu prea au concurență. Din motive de securitate pe Android e imposibil de
capturat fluxul audio de intrare, ceea ce face necesară manipularea cu telefonul în timpul unui apel de
intrare/ieșire. La aplicațiile actuale pe Android se evidențiază lipsa suportului la două cartele SIM, ceea ce
este cauzat de lipsa suportului din partea Android SDK 4.*, asta motivează creare acestui sistem utilizând
Android SDK 5.* care are suport la 2 cartele SIM dar are o rată mică de utilizare.
UTM 526.1.260 ME Coala
16
Mod Coala Nr. document Semnat. Data
2. Dezvoltarea sistemului
Conform capitolului doi așa un sistem va fi rezonabil de realizat utilizând un singur limbaj de programare
și un SDK cu o rată mare de utilizare. Ar trebui să fie prezentă o interfață simplă si intuitivă, în mare parte
designul va trebui să arate ca pe telefon pentru evitarea eventualele incertitudini de utilizare a aplicației. Un
plus mare va fi prestarea sistemului ca un proiect open source, ce va da posibilitatea utilizatorilor avansați de
schimbe sistemul după dorința lor.
2.1 Descrierea structurii sistemului
Sistemul va fi compus din două aplicații, una pe computer, alta pe telefon. Aplicațiile vor utiliza un canal
de rețea pentru comunicare, ce va fi oferit de un router.
Figura 2.1 Schema structurii sistemului.
Aplicația desktop este împărțită pe module conform pattern-lui MVC. Orice comunicare cu alte
dispozitive este realizată în fundal și nu afectează procesul interfeței grafice lipsind aplicația de frânări din
cauza excepțiilor apărute la transmiterea/primirea datelor. Pattern – ul MVC este impus de Java FX ca un
standard de elaborare a aplicațiilor.
Componentele structurale de bază ale aplicației sunt:
1. Interfața grafică
2. Clasa controller
3. Entitățile
UTM 526.1.260 ME Coala
17
Mod Coala Nr. document Semnat. Data
Figura 2.2 Schema structurii aplicației desktop.
Modulul view conține interfața grafică de comunicare cu utilizatorul. Aici va fi posibilă selectarea
dispozitivului conectat, vizualizarea volumului bateriei, lista de contacte, forma de scriere a mesajelor,
pagina de vizualizare a mesajelor. De asemenea modulul view conține forma de conexiune remote.
Modulul model conține entitățile de intercomunicare al sistemului, aici mai sunt și ascultătoarele de
evenimente.
Modulul controller este cel ce implementează toate funcționalitățile acestui sistem, în el are loc
deserializarea datelor primite prin soclul de comunicare și serializarea lor înainte de transmitere, aici are loc
procesarea și îndeplinirea comenzilor primite de la telefon, primirea și trimiterea obiectelor ce reprezintă
pachete de comunicare. Aici va avea loc generarea comenzilor de vizualizare a notificărilor și captarea
informației din forma de scriere a mesajelor.
Modulul controller este singurul ce este construit din mai multe module, printre care:
1. Modulul comunicare rețea.
2. Modulul criptare date.
3. Modulul broadcast.
4. Modulul procesare mesaje.
Funcționalitățile sistemului cu care poate interacționa utilizatorul pot fi redate prin diagrama cazurilor de
utilizare. Această diagramă privește sistemul ca un tot întreg, și funcționalitățile oricărui modul cu care
utilizatorul interacționează sunt atribuite sistemului.
cmp System structure
Controller
ModelView
UTM 526.1.260 ME Coala
18
Mod Coala Nr. document Semnat. Data
Figura 2.3 Diagrama cazurilor de utilizare a aplicației desktop.
Aplicația pe telefon este minimalistă în privința interfeței grafice, deoarece ea se reduce la utilizarea
serviciilor de fundal ce nu au nevoie de interfață grafică. Aplicația Android poate fi închisă după realizarea
conexiuni, deoarece după conexiune necesitate în prezenta ei nu este. Desigur după necesitate se poate de
pornit aplicație pentru, de exemplu de modificat numele dispozitivului, ceea ce nu va afecta funcționalitatea
aplicației. Structura aplicației Android este diferită de cea de pe computer, asta este cauzată de structura
aplicațiilor destinate platformei Android.
Componentele structurale de bază ale aplicației sunt:
1. Interfața grafică
2. Modulul de comunicare
3. Serviciul Android ce rulează în fundal
4. Entitățile
uc Use Case Desktop
User
Sending message
View message
View ocntact list
Find my phone
View phone battery status
Change dev ice
UTM 526.1.260 ME Coala
19
Mod Coala Nr. document Semnat. Data
Figura 2.4 Schema structura aplicației Android.
Modulul interfeței grafice va avea două funcții care le va pute îndeplini, una este legată de conectarea
remote și alta este de a schimba numele dispozitivului care va fi afișat în aplicația desktop.
Modulul de comunicare incorporează toate tipurile de comunicare care le realizează aplicația. Aici avem
submodulul de broadcast, ce realizează scanarea rețelei în căutarea aplicațiilor client sau server. Aici se află
și un soclu TCP ce va realiza o conexiune persistentă cu aplicația de pe computer ce are un soclu de server
pornit în ea.
Modulul cu entități reprezintă o colecție de clase derivate de la clasa CommunicationPacket care este un
obiect serializabil, și este singurul tip de obiect care poate fi trimis prin modulul de comunicare.
Modulul de serviciu reprezintă o clasă ce extinde clasa Service din Android SDK. Extinderea acestei
clase permite realizarea operațiilor de lungă durată în fundal. Serviciul dat conduce cu modulul de
comunicare, trimițând și primind pachete, de asemenea el poate prelucra pachetele oferind informație către
sursa pachetului, în dependență de necesitate. Serviciul va anunța aplicația pe computer în cazul apariției
unui mesaj, unui apel de intrare, va distribui volumul bateriei. De asemenea serviciul poate să trimită
mesajele în rețeaua GSM la comanda aplicației desktop.
cmp Phone aplication structure
User interface
Communication module
Entities
Serv ice
UTM 526.1.260 ME Coala
20
Mod Coala Nr. document Semnat. Data
Fiind o aplicație care predominant rulează în fundal, aplicația pe Android nu va dispune de un număr
mare de cazuri de utilizare.
Figura 2.5 Diagrama cazurilor de utilizare a aplicației pe Android.
2.2 Descrierea softului utilizat
Pentru crearea acestui sistem s-a utilizat un singur limbaj de programare, acesta este limbajul Java. A fost
utilizat nu doar din cauza că este un limbaj cunoscut de programator, ci și din cauza că este limbajul utilizat
la crearea aplicațiilor pe Android. Din aceste considerente au fost alese două medii de dezvoltare.
Pentru dezvoltarea sistemului a fost folosit un set de IDE-uri. IDE-le sunt medii de dezvoltarea a
aplicațiilor. IDE-le pe lângă editorul de text încorporat au și un mediu de testare, compilare, depanare și
generarea de documentației a proiectului. De obicei mediile de dezvoltare apelează compilatoare sau
interpretoare, care la rândul său pot veni cu pachetul de instalare al IDE-lui, sau necesită o instalare aparte.
Ca medii de dezvoltare au fost alese:
1. NetBeans IDE 8.0.2.
2. Android Studio 1.2.1.1.
uc Use Case Phone
User
Change dev ice name
Remote connection
Disconnect
Enter connection data
UTM 526.1.260 ME Coala
21
Mod Coala Nr. document Semnat. Data
2.2.1 Descrierea NetBeans IDE
NetBeans este un mediu de dezvoltare total gratuit, cu sursa deschisă, indiferent de platformă cu suport
implicit pentru limbajul Java. El permite dezvoltarea aplicațiilor pe module, ceea ce-l face extrem de comod
la realizarea proiectelor de dimensiuni mari. Aplicațiile elaborate cu ajutorul IDE - lui NetBeans pot fi
extinse de dezvoltatori terță, ceea ce oferă plasticitate aplicațiilor și reduce din timpul dezvoltatorilor la
extinderea lor.
NetBeans IDE de asemenea are suport lexicografic pentru limbajele PHP, C/C++ și HTML. Popularitatea
lui a crescut mult datorită feedback – ului din partea comunității și apariției distribuțiilor la timp a platformei,
plus NetBeans este dezvoltat de compania Oracle, care deține drepturile de dezvoltator al limbajului Java.
NetBeans IDE este scris în Java, deci orice dezvoltator Java, poate să-l extinsă cu extensiile lui personale
create în Java. Versiunea standard de NetBeans nu necesită JDK pentru începerea dezvoltării aplicațiilor
utilizând biblioteca Swing, aceasta se datorează limbajului de dezvoltare.
Mediul de dezvoltare NetBeans IDE vine cu un set de servicii reutilizabile, printre care sunt:
1. Amenajarea interfeței grafice.
2. Managementul setărilor utilizatorului.
3. Managementul stocării fișierelor.
4. Amenajarea ferestrelor de lucru.
5. Un cadru wizard, pentru crearea proiectelor.
6. O librărie vizuală.
7. Utilite de dezvoltare integrate.
2.2.2 Descrierea Android Studio
Android Studio este un IDE pentru dezvoltarea aplicațiilor pe platforma Android. El este bazat pe mediul
de dezvoltare JetBrains de la IntelliJ IDEA, și este destinat în special pentru dezvoltarea aplicațiilor pe
Android. Android Studio este indiferent de platformă, și poate fi instalat pe Windows, Mac și Linux. El
substituie complet Eclipse Android Development Tool (ADT) ca IDE-ul primar recomandat de Google
pentru dezvoltarea aplicațiilor pe Android.
Principalele funcționalități care vin cu Android Studio sunt:
1. Vizualizarea activă a designul-lui .
2. Suportul Gradle la crearea proiectelor.
3. Reorganizarea structurii codului.
4. Sistem de detectare a codului redundant și a erorilor.
UTM 526.1.260 ME Coala
22
Mod Coala Nr. document Semnat. Data
5. Cadru wizard cu șabloane de design.
6. Un editor de design bogat cu posibilitatea creării design-lui utilizând metoda drag-and-drop.
7. Suport la versiunile de android samrtwatch.
8. Suport implicit pentru platforma Google Cloud.
Android Studio vine și cu un emulator al dispozitivelor pe platforma Android. Emulatorul permite
dezvoltarea și testarea aplicațiilor Android fără utilizarea unui dispozitiv fizic. Emulatorul utilizează aceeași
motorica de manipulare ca pe un dispozitiv fizic, el simulează total funcționalitatea dispozitivului fizic.
Principalul dispozitiv cu care se poate de manipulat emulatorul este mouse-ul care vine pe post de deget.
Pentru testare flexibilă a aplicației, emulatorul vine cu posibilitatea de creare mai multor profiluri de emulare,
în care se pot seta specificații diferite pentru dispozitive diferite.
Dacă aplicația a rulat pe emulator, atunci ea cu siguranță că va rula și pe un dispozitiv fizic. Emulatorul
permite utilizarea clasei Service, cât și claselor ce o extind. El mai permite accesul la rețea si redarea
fișierelor audio și video.
Emulatorul mai conține și diferite capacități de depanare a aplicației, așa ca consola în care se pot scrie
comenzi kernel, simula întreruperi si efectul de latență a rețelei.
Emulatorul Android suportă mai multe tipuri de configurări hard găsite în dispozitivele pe piața
autohtonă, printre care sunt:
1. Procesoarele ARMv5, ARMv7 sau procesoare cu arhitectura x86.
2. Display cu culori de 16 biți.
3. Una sau mai multe tastiere.
4. Un cip audio cu intrări și ieșiri.
5. Memorie de tip flash.
6. Modem GSM, care include cartelă SIM.
7. O cameră de luat vederi, care va fi emulată de un webcam.
8. Sensor ca accelerometru, datele sunt luate de la un dispozitiv Android conectat prin USB.
2.2.3 Descrierea Enterprise Architect
Pentru proiectarea și modelarea vizuală a sistemului am folosit utilita Enterprise Architect care este
bazată pe standardul OMG UML. Am ales această utilită din cauza cursurilor anterioare de Ingineria
Programării la care a fost folosită intens. Este o utilită destul de comodă și aparent plăcută, oferind o
manipulare cu funcționalul ei destul de comodă, plus pachetul de instalare nu e tare voluminos..
A fost aleasă utilita Enterprise Architect versiunea 7.5, care suportă:
UTM 526.1.260 ME Coala
23
Mod Coala Nr. document Semnat. Data
1. Construcția și design-ul sistemelor software
2. Modelarea proceselor funcționale
3. Modelarea domeniilor industriale
Utilita este utilizată nu doar pentru modelarea arhitecturii sistemelor ci și pentru monitorizarea proceselor
de implementare a modulelor până la realizarea completă a sistemului.
UML oferă posibilitatea modelării a tuturor aspectelor organizaționale pe lângă posibilitățile de creare a
design-ului și implementării sistemelor noi cât și extinderea celor existente.
Enterprise Architect pe lângă standardul UML mai suportă și:
1. SysML.
2. BPMN.
3. BPEL.
4. ScaML.
5. SPEM.
6. WSDL.
7. XSD.
8. DDS.
9. ArchMate.
10. Geography Markup Language.
11. ODM, OWL and RDF.
Modelarea UML are câteva aspecte care sunt suportate de majoritatea utilitelor de proiectare. Enterprise
Architect suportă un set de aspecte strâns legate de UML, care sunt:
1. Profilurile.
2. Pattern-urile.
3. MOF (Meta-Object Facility).
4. Limbajul de constrângeri al obiectelor.
5. MDA (Model-Driven Architecture).
6. COBRA (Common Object Request Broker Architecture).
UTM 526.1.260 ME Coala
24
Mod Coala Nr. document Semnat. Data
3. Proiectarea și implementarea sistemului
Implementarea sistemului se bazează pe câteva lucruri importante, printre ele sunt proiectarea și softul
utilizat la implementarea lui, toate acesta au fost descrise în capitolul doi. În acest capitol va fi descris
sistemul din punct de vedere al proiectării și a eventualei implementări.
3.1 Tehnologii utilizate
Pentru o viziune mai clară asupra proceselor ce se petrec în interiorul sistemului, este necesar de aduce la
cunoștință protocoalele utilizate la comunicare între aplicații
1. Protocolul UDP
2. Protocolul TCP
Protocolul UDP – este un membru al familiei de protocoale la baza cărora este protocolul IP. El a fost
proiectat în 1980 de către David Reed, și formal definit în RFC 768. Protocolul UDP este un simplu model
de transmitere a datelor, fără conexiune, cu un număr redus de acțiuni la transmitere. Nu duce dialoguri
handshaking, și astfel este lipsit de orice formă de fiabilitate a canalului de rețea. Acest protocol nu
garantează sub nici o formă livrarea datelor către receptor. UDP oferă sume de control pentru integritatea
datelor, numere de port pentru comunicarea cu receptorul și adresa receptorului.
Utilizând protocolul UDP aplicațiile pot trimite datagrame către un calculator din rețea fără a încheia cu
el o conexiune. UDP este potrivit pentru utilizarea în condiții unde corectarea și verificarea ordinii pachetelor
nu este strict necesară. Aplicațiile sensibile la timp deseori folosesc acest protocol deoarece în conexiunile
persistente în cazul pierderii pachetelor cererea și confirmarea consumă mult timp.
Acest protocol posedă niște atribute care-l face util pentru anumite aplicații:
1. Este un protocol orientat pe tranzacție, pentru operații de interogare – răspuns cum ar fi serviciul
DNS.
2. Utilizarea datagramelor oferă posibilitatea de modelare a protocoalelor cum ar fi tunelul IP sau
Remote Procedure Call și Network File System.
3. Este simplu, potrivit pentru procesul de bootstrap sau în alte scopuri, fără o stivă completă cum ar fi
DHCP sau TFTP.
4. Este apatrid, potrivit pentru un număr foarte mare de clienți, cum ar fi aplicații media de exemplu,
IPTV streaming.
5. Lipsa întârzierii de retransmitere îl face util pentru aplicații în timp real cum ar fi Voice over IP,
jocuri online, si pentru multe protocoale construite deasupra la Streaming Protocol.
UTM 526.1.260 ME Coala
25
Mod Coala Nr. document Semnat. Data
6. Funcționează bine în comunicarea unidirecțională, potrivit pentru broadcast și scanarea rețelei în
căutarea serviciilor de rețea.
Numeroase aplicații de pe internet folosesc UDP, prin ele se includ serviciul DNS, unde interogările
trebuie să fie cât mai rapide posibile, și sunt compuse dintr-o singură interogare și un singur pachet de
răspuns, mai este utilizat în Simple Network Management Protocol (SNMP), în Routing Information
Protocol (RIT) și în Dinamic Host Configuration Protocol (DHCP).
Transferul video și audio în general este realizat utilizînd protocolul UDP. Protocoalele ce se ocupă cu
transmiterea informației video și audio în timp real sunt pregătite pentru pierderile ocazionale de pachete, ca
rezultat se obțin pierderi minime din calitatea informației.
Protocolul TCP – la fel este un membru al familiei de protocoale la baza cărora este protocolul IP. Este
originar încă de la implementarea inițială a rețelei internet, unde a completat protocolul IP. Prin urmare un
pachet TCP are denumirea specifică TCP/IP. Protocolul TCP oferă siguranță, ordine, și verificarea erorii de
livrare la transmiterea pachetelor. Aplicațiile de pe internet ca World Wide Web, e-mail, administrarea de la
distanta și transferul de fișiere se bazează pe utilizarea acestui protocol.
Prima apariție a acestui protocol se datează în mai 1974 sub numele de „protocol for Packet Network
intercomunication” autorii căruia sunt Vint Cerf și Bob Kahn, el descria un proces de comunicare între
computere utilizînd schimbul de pachete prin nodurile de comunicare. Componenta de control în acest model
a fost Transmision Control Program care încorpora atât legături orientate pe conexiune cât și servicii de
transfer de date între gazde. Transmision Control Program a fost ulterior divizat într-o arhitectură modulară
care era constituita din Transmision Control Protocol fiind un protocol orientat pe conexiune și Internet
Protocol. Acest model a devenit cunoscut informal ca TCP/IP, deși a fost numit Internet Protocol Suite.
Pentru scanarea rețelei la realizarea conexiunii directe dispozitive am avut nevoie de a implementa
tehnologia de rețea ce se numește broadcast. Broadcast-ul reprezintă o metodă de transmitere a mesajelor
către toți receptorii simultan.
În rețelele de computere, brodcast-ul se referă la transmiterea unui pachet care va fi recepționat de orice
dispozitiv în rețea. În practică broadcast-ul este limitat la domeniul de broadcast, care de obicei este o rețea.
Nu toate tipurile de rețele suportă această tehnologie, de exemplu rețele de tip X.25 sau Frame Relay nu
suportă această tehnologie. Succesorul protocolului IPv4, IPv6 încă nu suportă această tehnologie de
transmitere a pachetelor prin rețea, cu scopul de a nu perturba toate nodurile din rețea atunci când doar câteva
noduri sunt interesate de acel mesaj.
Pentru transmiterea mesajelor prin broadcast, nodurile de rețea folosesc on adresă specială, rezervată,
pentru așa situații, de obicei ea este reprezentată astfel XXX.XXX.XXX.255, primii trei octeți depind de
configurarea rețelei în care are loc procesul de broadcast.
UTM 526.1.260 ME Coala
26
Mod Coala Nr. document Semnat. Data
Un punct neplăcut al acestei tehnologii este că ea poate fi utilizată abuziv pentru realizarea atacurilor de
tip DoS cu numele de Smurf atac. Atacatorul utilizând tehnologia trimițând pachete către toate dispozitivele
conectate la rețea, supraîncărcându-le ulterior ies din funcțiune.
Pentru realizarea operațiunilor de lungă durată pe platforma Android, așa ca menținerea unei conexiuni
de rețea cu ulterioara utilizare a ei în comunicare cu alte dispozitive s-au folosit Android Services. Un
Service în Android este o componentă a unei aplicații care realizează operațiuni de lungă durată în fundal și
nu posedă interfața grafică. Fiind un component al aplicației ce poate fi pornit de o altă componentă, el va
rula chiar dacă utilizatorul va deschide o altă aplicație decât cea care a creat serviciul.
Adițional serviciile pot fi atribuite altor aplicații, pentru a putea manipula cu ele. Serviciile pot fi
manipulate de alte aplicații doar în cazul în care el a fost pregătit pentru asta.
Serviciile pot fi utilizate la redarea fișierelor audio, descărcarea fișierelor de pe internet, transmiterea unui
email, etc. Toate aste se vor realiza în fundal fără utilizarea unei activități.
3.2 Documentul cerințelor de sistem
Sistemul dat va rula pe două dispozitive diferite, deci este nevoie de specificat cerințele de sistem minime
pentru fiecare dispozitiv în parte, plus sistemul utilizează conexiune de rețea, deci trebuie de specificat ce tip
de rețea este necesară și viteza minimă de trafic.
1. Specificațiile de sistem pentru computer
a. Sistemă de operare Linux, Windows, Mac
b. Memorie operativă 2 GB
c. Placa de rețea WiFi sau Ethernet
d. Java jdk instalat
2. Specificațiile de sistem pentru telefon
a. Sistem de operare Android
b. Versiune Android 4 +
c. Un GB de memorie operativă
d. Modul compatibil WiFi
3. Specificațiile de sistem pentru router
a. Router cu suport pentru oricare altă rețea în afară de X.25
b. Conexiune WiFi
c. Viteza de comunicare minimă de 200 KBit/sec
UTM 526.1.260 ME Coala
27
Mod Coala Nr. document Semnat. Data
3.3 Proiectarea sistemului de intercomunicare mobil - desktop
Proiectarea unui soft este procesul prin care se creează specificația unui sistem software, destinată pentru
realizarea obiectivelor, folosind un set de componente supuse unor constrângeri. Proiectarea softului se
implică la rezolvarea problemelor de planificare pentru reducerea timpului și resurselor utilizate la realizarea
proiectului.
Aceasta poate include atât proiectarea la nivel jos cât și algoritmi de realizare a nivelelor înalte cum ar fi
design-ul sau arhitectura. Conform standardelor de proiectare, vom începe cu cazurile de utilizare ale
sistemului.
Cazurile de utilizare a sistemului sunt prezentate în capitolul 2, în figurile 2.3 și 2.5
Pentru a descrie static un sistem vom construi diagrama claselor, care constituie punctul de plecare în
construirea altor tipuri de diagrame. Vom prezenta diagrama claselor pe modulele sistemului.
3.3.1 Diagramele de clase ale aplicației desktop
Modulul principal al sistemului este alcătuit din 3 clase
1. AddressPack
2. Crypt
3. MDIS
Clasa AddressPack este o clasă obiectul căreia reprezintă un depozit pentru adresa de broadcast și adresa
dispozitivului.
Clasa Crypt este o clasă statică care permite criptarea mesajelor cu scopul trimiterii lor prin canalul de
comunicare. Această clasă mai este utilizată și la decriptarea mesajelor, plus, utilizând expresii regulate
putem verifica componența mesajului la prezența datelor necesare.
MDIS reprezintă clasa rădăcină proiectului.
Figura 3.1 Diagrama de clase a modului principal.
Modulul Broadcast al sistemului este alcătuit din 4 clase
1. Broadcast.
class mdis
AddressPack
+ broadcast_address: InetAddress {readOnly}+ ip_address: InetAddress {readOnly}
+ AddressPack(InetAddress, InetAddress)+ toString() : String
Crypt
- client_pattern: Pattern = Pattern.compile... {readOnly}- datagram_pattern: Pattern = Pattern.compile... {readOnly}- key_offset: byte = 0x04 {readOnly}- random: Random = new Random() {readOnly}
+ byteBaseDecrypt(byte[]) : byte[]+ byteBaseEncrypt(byte[]) : byte[]+ clientName(String) : String+ packetMatche(String) : boolean+ rotateLeft(byte, byte) : byte+ rotateRight(byte, byte) : byte
ApplicationMDIS
+ server: TCPConnectionServer
+ error(String) : void+ info(String) : void+ start(Stage) : void
UTM 526.1.260 ME Coala
28
Mod Coala Nr. document Semnat. Data
2. BroadcastAddress.
3. BraodcastEmitter.
4. BroadcastReceiver
Clasa Broadcast care implementează interfața Runnable și deține principalele metode pentru realizarea
acțiunii de broadcast
Clasa BroadcastAddress crează o listă de obiecte de tip AddressPack la prima apelare a metodei
getBroadcastAddress și o întoarce, la următoarele apelări ea doar va întoarce această listă.
Clasa BroadcastEmitter extinde clasa Broadcast permițând astfel trimiterea mesajelor broadcast în rețea.
Clasa BroadcastReceiver extinde clasa Broadcast permițând astfel ascultarea rețele la mesaje broadcast
pe un anumit port.
Figura 3.2 Diagrama de clase a modului Broadcast.
Modulul Client al sistemului este alcătuit din 2 clase:
1. Client.
2. TCPConnectionServer.
class Broadcast
RunnableBroadcast
# device_name: String# packet_size: short = 40 {readOnly}# port: int# socket: DatagramSocket# socket_timeout: short
# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void
BroadcastAddress{leaf}
- network_address: ArrayList<AddressPack> = null
- BroadcastAddress()+ getBroadcastAddress() : ArrayList<AddressPack>+ reSearchBroadcastAddress() : void
BroadcastEmitter
- broadcast_address: InetAddress
+ BroadcastEmitter(int, short, InetAddress)+ BroadcastEmitter(int, short, InetAddress, String)# getBroadcastMessage() : byte[]- getConnectionData() : byte[]# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void- sendConnectionData(InetAddress) : void
BroadcastReceiv er
+ BroadcastReceiver(int, short)+ BroadcastReceiver(int, short, String)- getConnectionData() : byte[]# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void
UTM 526.1.260 ME Coala
29
Mod Coala Nr. document Semnat. Data
Clasa Client reprezintă o structură ce va fi atribuită unui soclu creat la conexiunea unui client, pentru
realizare unei conexiuni persistente cu un dispozitivul mobil.
TCPConnectionServer reprezintă un server TCP ce rulează de la pornirea sistemului până la oprirea
aplicației desktop. El va returna câte un obiect de tip soclu la realizarea conexiunii cu un dispozitiv.
Figura 3.3 Diagrama de clase a modulului Client
Modulul Communication al sistemului este alcătuit din 14 clase:
1. CommunicationPacket.
2. Command.
3. Call.
4. Message.
5. Close.
6. MessageStatus.
7. FindPhone.
8. BatteryCapacity.
9. CommandResponse.
10. IncomingCall.
11. IncomingMessage.
12. OutgoingMessage.
13. SendingMessageStatus.
14. MessageDeliveryStatus.
CommunicationPacket este clasa de bază, și este unicul tip de obiect care poate fi trimis prin canalul de
comunicare. Din această cauză s-a realizat o ierarhie de clase ce extind CommunicationPacket pentru
reducerea numărul de metode de trimitere a obiectelor prin canal.
class Client
RunnableClient
- in: ObjectInputStream- out: ObjectOutputStream- receiver: Thread- socket: Socket
+ Client(Socket)- receive() : CommunicationPacket+ run() : void- send(CommunicationPacket) : void
RunnableTCPConnectionServ er
+ port: int {readOnly}- server_socket: ServerSocket
+ closeSocket() : void+ run() : void+ TCPConnectionServer()
UTM 526.1.260 ME Coala
30
Mod Coala Nr. document Semnat. Data
Command este o clasă a cărui obiect deține o comandă ce trebuie îndeplinită de dispozitivul de la celălalt
capăt al canalului.
Call este o clasă a cărui obiect deține informația despre sursa apelului cum ar fi numărul de telefon.
Message este o clasă model ce servește ca bază pentru pachetele de tip Message.
Close - obiectul de acest tip de clasă va reprezenta semnalul de deconectare și oprire a aplicației, în
dependența de sursa dispozitivului.
MessageStatus este o clasă model ce reprezintă baza la clasele SendingMessageStatus și
MessageDeliveryStatus.
FindPhone este clasa care va fi utilizată la generarea semnalului de găsire a telefonului.
BatteryCapacity este clasa care fi utilizată la transmiterea valorii capacității bateriei telefonului.
CommandResponse este clasa care va servi drept răspuns la o interogare de tip Command către
dispozitiv.
IncomingCall este o clasă a cărui obiect va fi generat la un apel de intrare.
IncomingMessage este o clasă a cărui obiect va conține informația despre sursa mesajului și textul
mesajului.
OutgoingMessage – obiectele de acesta clasă vor fi generate la crearea unui mesaj pentru a fi trimis de
către dispozitiv prin rețeaua GSM. El va conține adresa destinatarului si textul mesajului.
SendingMessageStatus – un obiect de acest tip va fi generat la transmiterea cu eșec sau cu succes al
mesajului.
MessageDeliveryStatus – un obiect de acest tip va fi generat la livrarea cu succes sau cu eșec al
mesajului.
NOTĂ: Pentru vizualizarea diagramei de clase pentru modulul Communication consultați ANEXA 1.
3.3.2 Diagramele de clase ale aplicației Android
Modulul MDIS este alcătuit din 6 clase:
1. AddressPack.
2. Crypt.
3. MDIS.
4. Person este o clasă ce deține informație despre o persoană ce este înregistrată în contactele
telefonului.
5. FindPhoneActivity este o activitate ce va fi utilizată la funcția de găsire a telefonului.
6. Connection – clasă utilizată la conectarea cu computerul atât la conexiunea de tip remote cât și cea
directă.
UTM 526.1.260 ME Coala
31
Mod Coala Nr. document Semnat. Data
Figura 3.4 Diagrama de clase a modului principal al aplicației Android.
Diagrama de clase a modului Broadcast este compusă din 5 clase
1. Broadcast.
2. BroadcastAddress.
3. BroadcastEmitter.
4. BroadcastReceiver.
5. ConnectionData – este o clasă ce va păstra datele conexiunii. Informația despre dispozitivul cu care a
avut loc conectarea.
class mdis
AddressPack
+ broadcast_address: InetAddress {readOnly}+ ip_address: InetAddress {readOnly}
+ AddressPack(InetAddress, InetAddress)+ toString() : String
Connection
+ connect() : void
Crypt
- client_pattern: Pattern = Pattern.compile... {readOnly}- datagram_pattern: Pattern = Pattern.compile... {readOnly}- key_offset: byte = 0x04 {readOnly}- random: Random = new Random() {readOnly}
+ byteBaseDecrypt(byte[]) : byte[]+ byteBaseEncrypt(byte[]) : byte[]+ connectPacketMatch(String) : boolean+ decryptConnectionData(String) : String[]+ packetMatche(String) : boolean- rotateLeft(byte, byte) : byte- rotateRight(byte, byte) : byte
ActivityFindPhoneActiv ity
- audio_manager: AudioManager- isChanged: boolean = false- media_player: MediaPlayer- ringer_mode: int- stream_volume_value: int
# onCreate(Bundle) : void# onDestroy() : void# onStop() : void
ActivityMDIS
- port: int- timeout: short
- checkWiFiConnection() : boolean- enableWiFi() : boolean+ error(String) : void+ getContactMap() : ExtendedHashMap<String, Person>+ info(String) : void# onCreate(Bundle) : void+ onCreateOptionsMenu(Menu) : boolean# onDestroy() : void+ onOptionsItemSelected(MenuItem) : boolean# onStop() : void
Person
+ name: String {readOnly}+ phone: String {readOnly}
+ Person(String, String)+ toString() : String
UTM 526.1.260 ME Coala
32
Mod Coala Nr. document Semnat. Data
Figura 3.4 Diagrama de clase pentru modulul Broadcast al aplicației Android.
Diagrama de clase a modului BroadcastReceivers al aplicației Android este alcătuit din 5 clase:
1. BatteryBroadcastReceiver – acest receiver va duce evidența capacității bateriei, și la schimbarea
valorii ei va trimite informația spre computer.
2. DeliveryStatusMessageBroadcastReceiver – acest receiver va anunța aplicația desktop despre statutul
de livrare a mesajului.
3. IncomingCallBroadcastReceiver – acest receiver va anunța aplicația desktop despre un apel de
intrare.
4. IncomingSMSBroadcastReceiver – acest receiver va transmite textul mesajului primit la fel ca și
datele despre sursa lui.
5. SendStatusMessageBroadcastReceiver – acest receiver va monitoriza dacă mesajul a fost trimis sau
nu, și va trimite cauza în caz că nu a fost trimis.
class Broadcast
RunnableBroadcast
# device_name: String# packet_size: short = 40 {readOnly}# port: int# socket: DatagramSocket# socket_timeout: short
# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void
BroadcastAddress
- network_address: ArrayList<AddressPack> = null
- BroadcastAddress()+ getBroadcastAddress() : ArrayList<AddressPack>+ reSearchBroadcastAddress() : void
BroadcastEmitter
# broadcast_address: InetAddress
+ BroadcastEmitter(int, short, InetAddress, String)+ BroadcastEmitter(int, short, InetAddress)- capitalize(String) : String# getBroadcastMessage() : byte[]- getDeviceName() : String# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void
BroadcastReceiv er
+ BroadcastReceiver(int, short)+ BroadcastReceiver(int, short, String)- capitalize(String) : String- getByteData() : byte[]- getDeviceName() : String# receive() : DatagramPacket+ run() : void# send(DatagramPacket) : void
ConnectionData
+ device_address: InetAddress {readOnly}+ device_name: String {readOnly}+ port: int {readOnly}
~ ConnectionData(InetAddress, String[])+ toString() : String
UTM 526.1.260 ME Coala
33
Mod Coala Nr. document Semnat. Data
Figura 3.5 Diagrama de clase al modului BroadcastReceivers al aplicației Android.
Modulul Communication este reprezentat în ANEXA 1, iar descrierea claselor este la aplicația pe
computer. Aici va fi descrisă doar diferența dintre aceste module.
Modulul Communication al aplicației Android conține o clasă adăugătoare care se numește
CommunicationService, el răspunde comunicare prin rețea, adică el se ocupă de transmiterea și primirea
mesajelor prin canal.
Figura 3.6 Clasa CommunicationService din modulul Communication al aplicației Android.
Diagrama de activitate este o reprezentarea grafică a funcționalităților sistemului având suport la decizii,
iterări și concurența în execuția acțiunii. Diagramele de activitate ne arată pas cu pas cum decurge o acțiune
pentru o descrie mai deslușită a funcționalității sistemului.
class BroadcastReceiv ers
BroadcastReceiverBatteryBroadcastReceiv er
+ onReceive(Context, Intent) : void
BroadcastReceiverDeliv eryStatusMessageBroadcastReceiv er
+ onReceive(Context, Intent) : void
BroadcastReceiverIncomingCallBroadcastReceiv er
+ onReceive(Context, Intent) : void
BroadcastReceiverIncomingSMSBroadcastReceiv er
~ ACTION: String = "android.provid... {readOnly}
+ onReceive(Context, Intent) : void
BroadcastReceiverSendStatusMessageBroadcastReceiv er
+ onReceive(Context, Intent) : void
class Communication
ServiceCommunicationServ ice
~ batteryBroadcastReceiver: BatteryBroadcastReceiver- CLOSE: byte = 0x00 {readOnly}- COMMAND: byte = 0x01 {readOnly}- MESSAGE: byte = 0x04 {readOnly}
+ onBind(Intent) : IBinder+ onCreate() : void+ onDestroy() : void+ onStartCommand(Intent, int, int) : int- sendSMS(String, String) : void
UTM 526.1.260 ME Coala
34
Mod Coala Nr. document Semnat. Data
3.3.3 Diagramele de activitate ale aplicației desktop
Diagrama de activități pentru vizualizarea mesajelor.
Procesul este relativ scurt ,și se reduce la căutarea în structura de date a mesajului cu un indice din lista
de vizualizare a contactelor.
Figura 3.7 Diagrama de activități pentru vizualizarea mesajelor
Diagrama de activități pentru vizualizarea listei de contacte.
De la început aplicația pe computer trimite o cerere de tip comandă pentru prestarea de către telefon a
listei de contacte, apoi telefonul îi trimite această listă. Prin urmare primim datele de la telefon le vizualizăm,
dar în caz că lista este prezentă deja, vizualizarea contactelor se face instantaneu.
act View message
StorageComputer
Det message by id Search for mesage
Returned message
View message
UTM 526.1.260 ME Coala
35
Mod Coala Nr. document Semnat. Data
Figura 3.8 Diagrama de activitate pentru vizualizarea contactelor
Diagrama de activitate pentru trimiterea mesajelor.
Procesul începe cu completarea formei mesajului, apoi serializarea pachetului ,după transmiterea lui către
aplicația de pe telefon, care o prelucrează, apoi o transmite către destinatar. În cazul apariției erorilor
aplicația va trimite notificare către computer cu informația necesară.
NOTĂ: Diagrama de activitate pentru trimiterea mesajelor este prezentă în ANEXA 2
Diagrama de activitate pentru funcția găsirii telefonului.
Îndeplinirea acestei funcții se reduce la trimiterea unui mesaj către aplicația Android, mai precis un obiect
de tip FindPhone care va da de știre telefonului pentru începerea acțiunii pentru găsire telefonului.
act View contact list
PhoneNetworkComputer
Check if contact list is null
Netwoek packet witching Get contact list
Cretate contact listNetwork pcaket switchingView contact list
Yes
No
UTM 526.1.260 ME Coala
36
Mod Coala Nr. document Semnat. Data
Figura 3.9 Diagrama de activitate pentru găsirea telefonului.
3.3.4 Diagramele e activitate ale aplicației Android
Procesul de schimbare a numelui constă din introducerea numelui și trimiterea lui către aplicație desktop,
pentru ulterioara modificare a datelor vizibile.
act Find my phone
PhoneNetworkComputer
Call findfunction
Send FindPhone message
Network packet switching Reading message
Make actions
Stop
act Change dev ice name
ComputerNetworkPhone
Enter name
Send nameNetwork packet
switching Read ne name
Change name
UTM 526.1.260 ME Coala
37
Mod Coala Nr. document Semnat. Data
Figura 3.10 Diagrama de activități pentru schimbarea numelui.
Conectarea remote este utilizată în cazul situării în rețele diferite sau în aceeași rețea, dar fără suportul
tehnologie de broadcast. Conectarea are loc la creare soclului TCP, care trimite o cerere de tip accept la un
soclu de tip server.
Figura 3.11 Diagrama de activități a conexiuni remote.
act Remote connection
ComputerNetworkPhone
Enter connection data
Create socket and trying to connect
Deliv ery connection request
Accept connection to serv er
UTM 526.1.260 ME Coala
38
Mod Coala Nr. document Semnat. Data
4. Organizarea economică
4.1 Scopul realizării proiectului și cercetări de marketing
Scopul principal al proiectului este crearea și dezvoltarea unui canal de comunicare dintre un dispozitiv
mobil și un computer. Scopul secundar este realizarea pe baza acestui canal o aplicație handoff/handover
pentru utilizarea funcționalităților canalului.
Aspectul de bază a proiectului constă în studierea posibilităților și metodelor de comunicare între
dispozitivele mobile și computere, deci proiectul are un aspect predominant științific însă cu o posibilă
extindere comercială, numai sub licența GPL.
Aspect științific:
1. Crearea unui motor de interconectare a dispozitivelor (mobil și computer).
2. Interconectarea dispozitivelor prin intermediul unei legături persistente de comunicare.
3. Implementarea modulelor de comunicare prin intermediul canalului.
4. Securizarea și protecția canalului (doar la nivel soft).
Aspect comercial:
1. Realizarea unei interfețe de manipulare cu canalul creat.
2. Implementarea funcției de transmitere și primire a mesajelor.
3. Implementarea funcției find my phone.
4. Implementarea funcției de notificare a apariției unui apel de intrare.
Actual pe piață este un singur concurent care este cel mai aproape de conceptul proiectului (AirDroid).
1. Nu e un proiect open source.
2. Nu posedă o interfață simplă și intuitivă.
3. Utilizează mai multe limbaje de programare(ceea ce poate duce la un impact negativ la nivel de
compatibilitate dintre platforme).
4.2 Plan calendaristic
Planul calendaristic al proiectului reprezintă aranjarea în timp a procesului de elaborare și repartizare a
sarcinilor și resurselor. În dependență de durata proiectului, planul poate fi divizat în luni, săptămâni, zile,
ore.
Etapele de planificare a timpului recomandate pentru proiect sunt următoarele:
UTM 526.1.260 ME Coala
39
Mod Coala Nr. document Semnat. Data
1. Obiective.
2. Volum de lucru.
3. Timp necesar.
4. Plan calendaristic.
Durata unei acțiuni se calculează conform formulei
D = Dî – Df + Rt (Zile) ( 5.1 )
D – Durata acțiunii
Dî – data începerii acțiunii
Df – data finalizării acțiunii
Rt – rezerva de timp alocată
Ca executant al acțiunilor va fi o echipă compusă din:
1. Conducător de proiect
2. Programator 1
3. Programator 2
Tabelul 4.1: Planul calendaristic.
Nr. de ordine Denumirea acțiunii Durata
acțiunii Executant Resurse
1. Stabilirea obiectivelor și necesităților de proiectare.
1 zi
Conducător proiect Programator 1 Programator 2
Internet, Computer
2. Analiza domeniului IT în sfera comunicării dintre dispozitive.
Conducător proiect Programator 1 Programator 2
Internet Computer
3. Stabilirea cerințelor de sistem minime necesare proiectului. 1 zi
Conducător proiect Programator 1 Programator 2
Internet, Computer, Telefon
4. Selectarea softului pentru elaborarea proiectului. 1 zi Programator 1
Programator 2 Internet, Computer
5. Determinarea mediilor de testare. 1 zi Programator 1 Programator 2
Computer, Emulator, Telefon
6. Colectarea informației necesare pentru elaborarea proiectului. 10 zile Programator 1
Programator 2
Internet, Android SDK, Java JDK
UTM 526.1.260 ME Coala
40
Mod Coala Nr. document Semnat. Data
Continuare tabelul 4.2 Planul calendaristic.
7. Proiectarea prototipului proiectului. 2 zile Conducător proiect Programator 1 Programator 2
Computer, Enterprise Architect
8. Implementarea motorului de interconectare a dispozitivelor (mobil – desktop).
3 zile Programator 1 Computer, Emulator, Telefon
9. Implementarea modului cu canal persistent de comunicare. 2 zile Programator 2
Computer, Emulator, Telefon
10. Implementarea modulelor de comunicare prin intermediul canalului. 3 zile Programator 2
Computer, Emulator, Telefon
11. Implementarea modului de securizare a canalului. 2 zile Programator 1
Computer, Emulator, Telefon
12. Implementarea funcției de transmitere primire a mesajelor. 2 zile Programator 1
Programator 2
Computer, Emulator, Telefon
13. Implementarea funcției de notificare a apariției unui apel de intrare. 1 zi Programator 1
Programator 2
Computer, Emulator, Telefon
14. Implementarea funcției de găsire a telefonului. 1 zi Programator 1
Programator 2
Computer, Emulator, Telefon
15. Realizarea interfeței grafice de manipulare cu canalul creat. 4 zile
Conducător proiect Programator 1 Programator 2
Computer, Emulator, Telefon
16. Testarea primului prototip 2 zile Programator 1 Programator 2
Computer, Telefon
17. Depanarea primului prototip 2 zile Programator 1 Programator 2
Computer, Emulator, Telefon
18. Testarea prototipului doi 1 zi Programator 1 Programator 2
Computer, Telefon
19. Depanarea prototipului doi 1 zi Programator 1 Programator 2
Computer, Telefon
20. Întocmirea dării de seamă 3 zile Conducător proiect Programator 1 Programator 2
Computer
21. Prezentarea proiectului 1 zi Diplomant Computer, Proiector
UTM 526.1.260 ME Coala
41
Mod Coala Nr. document Semnat. Data
4.3 Analiza SWOT
Pentru identificarea raționalității proiectului e necesar să fie efectuată analiza mediului intern și extern al
proiectului. Pentru aceasta se propune metoda generală – Analiza SWOT, care constă în evaluarea punctelor
forte și slabe ale mediului intern și extern al proiectului.
Mediul intern:
Strengths – puncte forte – descriu atributele pozitive, tangibile și intangibile care țin de organizație și
proiect.
Weknesses – puncte slabe – factorii care sunt aflați sub controlul organizație sau echipei de proiect și
împiedică obținerea sau menținerea unui nivel de cantitate competitiv.
Mediul extern
Opportunities – oportunități – evaluează factorii atractivi externi care reprezintă elementele de care
organizația sau echipa de proiect poate profita.
Threats – riscuri – amenințările includ factori în afara controlului vostru care ar putea să vă pună
implementarea proiectului într-o poziție de risc. Aceștia sunt factori externi și nu se pot controla.
Tabelul 4.2: Analiza SWOT.
Puncte forte Puncte slabe Aplicația este open source. Utilizarea unui singur limbaj de programare. O interfață intuitivă. Suport la mai multe dispozitive conectate
concomitent. Prezența posibilității de interconectare prin două
metode.
Necesitatea de interconecta aplicațiile manual în rețele tip X.25.
Este un produs nou ce nu are popularitate sporită și nu are certificare.
Oportunități Riscuri Concurența slabă în acest sector al pieței. Numărul mare de utilizatori potențiali. O cerere moderată pe piață.
Dispozitive mobile pe Android OS sunt relativ scumpe.
Posibilități de extindere a aplicației reduse.
Rezultatul analizei SWOT:
Am determinat avantajele și dezavantajele proiectului, caracterul căruia este +8 / -4, ceea ce confirmă
fezabilitatea proiectului.
UTM 526.1.260 ME Coala
42
Mod Coala Nr. document Semnat. Data
4.4 Calculul indicatorilor economici
Aici vom calcula toată suma necesară pentru lansarea proiectului. Toate calculele trebuie să fie efectuate
în MDL. Prețurile materialelor, precum și salariile trebuie să fie actuale. (Fără TVA)
4.4.1 Bugetul
În procesul calculării bugetului se determină suma de active materiale și nemateriale necesare pentru
realizarea proiectului. În scopul determinării devizului de cheltuieli, de care avem nevoie pentru realizarea
proiectului, trebuie să prezentă lista de obiecte necesare
Tabelul 4.3: Active materiale pe termen lung.
Nr. de ordine
Denumirea activului
Costul unității, lei Cantitatea
Suma lei Sursa proprie
Sursa externă Total, lei
1 Computer 11300 3 11300 22600 33900 2 Router 580 1 580 - 580 3 Telefon 3000 1 3000 - 3000 4 Monitor 3000 3 3000 6000 9000
5 Enterprise Architect 2439 3 0 7313 7313
Total 20319 11 17880 35913 53793
Tabelul 4.4: Active nemateriale pe termen lung
Nr. de ordine Denumirea activului
Costul unității, lei
Cantitatea Suma lei
Sursa proprie
Sursa externă Total, lei
1 NetBeans 0 2 0 0 0 2 Android Studio 0 2 0 0 0 3 Microsoft Office 1265 3 1265 2330 3795 Total 1265 7 1265 2330 3795
Consumurile directe – reprezintă valoarea materialelor, utilizate în procesul de producție incluse în costul
produselor finite: elemente cu caracter material, utilizarea cărora este necesară în proiect – hârtie, cărți, etc.
Tabelul 4.5: Consumuri directe.
Nr. de ordine Denumirea activului Unitate
materială Costul unității, lei Cantitatea Suma, lei
1 Hârtie Pachet 50 1 50 2 Pix Bucată 5 3 15 3 Disc compact 700 MO Bucată 7 2 14 4 Carnet pentru notițe Bucată 15 3 45 Total 87 9 124
UTM 526.1.260 ME Coala
43
Mod Coala Nr. document Semnat. Data
4.4.2 Uzura activelor pe termen lung
Partea importantă a cheltuielilor indirecte constituie calcularea fondului de amortizare. În scopuri contabile
uzura trebuie să fie calculată uniform pe toată perioada decurgerii proiectului. Aceasta înseamnă că dacă activul
se planifica a fi utilizat trei ani, atunci costul lui va fi împărțit în trei pârți uniforme pentru fiecare an aparte.
Norma uzurii se calculează în dependență de durata utilizării activului.
Formula de calcul al uzurii este
Uz = Ca * Na / 252 * Tpr ( 5.2 )
Unde:
Ca – costul activului, lei
Na – norma uzurii anuale, 25%
Tpr – perioada de utilizare a activului, zile
252 – fondul nominal de lucru anual pe persoană, zile
Tabelul 4.6: Uzura activelor pe termen lung.
Nr. de ordine Activul Calculul Rezultat, lei
1 Computer 33900 * 0.25 / 252 * 44 1479.76 2 Router 580 * 0.25 / 252 * 44 25.31 3 Telefon 3000 * 0.25 / 252 * 44 130.95 4 Monitor 9000 * 0.25 / 252 * 44 392.85 5 Microsoft Office 3795 * 0.25 / 252 * 44 165.65 6 Enterprise Architect 7313 * 0.25 / 252 * 44 319.21 Total 2488.42
4.4.3 Consumuri directe privind retribuirea muncii
Tabelul 4.7: Retribuirea muncii.
Nr. de ordine Funcția angajatului Volumul de lucru,
zile Salariu contractual pe zi, lei
Fondul de retribuire a muncii, lei
1 Conducător proiect 11 500 5500 2 Programator 1 44 350 15400 3 Programator 2 44 350 15400 4 Total 30800
Calculele pentru suma contribuțiilor în fondul social (FS) și valoarea primei de asigurare medicală
obligatorie (AM).
UTM 526.1.260 ME Coala
44
Mod Coala Nr. document Semnat. Data
Fondul social, lei Asigurarea medicală, lei
FS = 0.23 * 30800 = 7084 AM = 0.045 * 30800 = 1386
Consumul direct privind retribuirea muncii.
Formula de calcul a consumului este:
Suma = FR + FS + FAM ( 5.3 )
Suma = 30800 + 7084 + 1386 = 39270 (lei)
Calculul venitului impozitabil
Venitul anual pentru conducător
Vi = 20 * 500 * 12 = 120000 (lei)
Venitul anual pentru Programator 1 și 2
Vi = 20 * 350 * 12 = 84000 (lei)
Tabelul 4.8: Contribuțiile în fondul social și de asigurare medicală.
Nr. de ordine Angajat Fond Calculul Rezultat, lei
1 Conducător Pensionar 0.06 * 120000 7200
2 Conducător Asigurare medicală 0.046 * 120000 5400
3 Programator 1 Pensionar 0.06 * 84000 5040
4 Programator 1 Asigurare medicală 0.045 * 84000 3780
5 Programator 2 Pensionar 0.06 * 84000 5040
6 Programator 2 Asigurare medicală 0.045 * 84000 3780
Calculul venitului impozitabil pentru conducător
Vi = 120000 – 7200 – 5400 – 9514 = 103286 (lei)
Calculul venitului impozitabil pentru programatori
Vi = 84000 – 5040 – 3780 – 9514 = 65666 (lei)
Calculul venitului net pentru conducător
Iv = 27852 * 0.07 + (103286 - 27852) * 0.18 = 15527.76 (lei)
UTM 526.1.260 ME Coala
45
Mod Coala Nr. document Semnat. Data
Vn = 120000 - 15527.76 – 7200 – 5400 = 91872.24 (lei)
Calculul venitului net pentru programatori
Iv = 27852 * 0.07 + (65666 – 27852) * 0.18 = 8756.16 (lei)
Vn = 84000 - 8756.16 – 5040 – 3780 = 66423.84 (lei)
Tabelul 4.9: Consumuri indirecte.
Denumirea articolului Unitate Cantitate Tarif, lei Valoare totală,
lei Energie electrica Kw 360 1.58 568.8 Servicii internet Abonament 1 175 175 Servicii transport Abonament 3 70 210 Serviciu telefon Abonament 3 90 270
Total 1223.8
4.4.3 Costul de producție
Costul de producție reprezintă totalitatea cheltuielilor, corespunzătoare consumului de factori de producție,
pe care agentul economic le efectuează pentru producerea şi vânzarea de bunuri materiale sau prestarea de
servicii. Prețul de cost se calculează pe o unitate. Dacă se elaborează un site sau o aplicație, atunci va fi prețul
de cost al elaborării, dar dacă în cadrul proiectului se planifică multiplicarea produsului, atunci este nevoie de
calculat prețul de cost al unei copii.
Tabelul 4.10: Costul de producție a unei copii.
Articolele de calculație Valoare, lei Ponderea, % Consumurile materiale directe 127.00 0.3 Cheltuielile indirecte 1223.80 2.8 Fondul total de salarizare 30800.00 71.5 Fondul de asigurare socială 7084.00 16.4 Fondul de asigurare medicală 1386.00 3.2 Fondul de amortizare a activelor 2488.42 5.8
Total costul proiectului 43109.22 100.00
Tabelul 4.11: Indicatorii economici ai proiectului.
Indicatorii tehnico-economici ai proiectului Valoarea reală Unitate de măsură
Numărul de zile pentru realizarea proiectului 44 Zile Suma necesară pentru realizarea proiectului, total inclusiv: 43109.22 Lei De elaborare a proiectului 43109.22 Lei Prețul unei copii 50 Unități
UTM 526.1.260 ME Coala
46
Mod Coala Nr. document Semnat. Data
Preț de realizare al unei copii 53886.525 Lei Numărul de copii realizate 50 Unități Profit total Nu se planifică
Economic acest proiect nu este rentabil din cauza licenței sub care sistema este disponibilă, dar din aspecte
de cercetare științifică este unul destul rezonabil.
UTM 526.1.260 ME Coala
47
Mod Coala Nr. document Semnat. Data
5. Concluzii
În urma realizării proiectului de licență „Sistem de intercomunicare mobil - desktop” a fost proiectat și
implementat acest sistem. A fot realizată interfața grafică de comunicare ce manipulează cu un canal pe baza
soclurilor TCP/IP prin intermediul rețelei locale. A fost realizată procesarea datelor primite din rețelele GSM
și transmiterea lor către aplicația desktop.
Interconectarea dispozitivelor are loc în mai mulți pași care reprezintă prin sine două succesiuni de
transmitere și primire a datelor din rețea. Algoritmul de interconectare se bazează pe scanarea rețelei prin
intermediul pachetelor criptate ceea ce exclude din start posibilitatea de bruiaj a aplicație. Luând în
considerare că algoritmul presupune în sine și interschimbarea receptorului cu emitorul posibilitatea de bruiaj
se reduce semnificativ.
Cel mai negativ efect al utilizării clasei ce este o derivată a clasei Service este stoparea ei de către
sistemul de operare, în diferite situații, această situație a fost procesată și în caz de stopare a serviciului
sistemul nu va fi supus deconectării ci doar va aștepta reconectarea telefonului. Din aceste cauze pe
calculator va rula permanent un receptor UDB broadcast pentru a face posibilă reconectare și conectarea altor
dispozitive la sistem.
Structura platformei JavaFX invocă utilizarea pattern-ului MVC ceea ce structurează destul de rigid
aplicația creată. Această structură este relativ anevoioasă și necesită cunoștințe avansate în programarea
concurentă. Pentru a putea accesa firul de execuție a interfeței grafice se poate de utilizat Platform.runlater(),
acestă metodă permite accesare și modificare interfeței grafice doar că ea nu poate fi accesată de oriunde.
UTM 526.1.260 ME Coala
48
Mod Coala Nr. document Semnat. Data
6. Bibliografie
1. Ghid pentru elaborarea și susținerea proiectelor de licența (accesat la 17.02.15)
2. Android Developers http://developer.android.com/index.html (accesat la 22.02.15)
3. Paul Clements, Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little, Robert Nord,
Judith Stafford. Documenting Software Architectures: Views and Beyond. Editura Addison-Wesley
Professional. 2002 (accesat la 3.03.14)
4. n Gorton. Essential Software Architecture. Editura Springer. 2006. (accesat la 3.03.15)
5. Jasper Potts, Nancy Hildebrandt, Joni Gordon, Cindy Castillo Getting started with JavaFX Release 8
(accesat la 25.02.15)
6. StackOverflow https://stackoverflow (accesat între 10.03.15 și 10.05.15)
UTM 526.1.260 ME Coala
49
Mod Coala Nr. document Semnat. Data
ANEXA 1 Diagrama de clase a modului Communication.
class Comm
unication
BatteryCapacity
+ battery_capcity: String {readO
nly}
+ BatteryCapacity(String)
+ toString() : String
Call
+ phone_state: String {readO
nly}
+ Call(String)
+ Call(byte, String)
+ toString() : String
Close
+ Close()
Comm
and
+ com
mand: String {readO
nly}
+ Com
mand(byte, String)
+ Com
mand(String)
+ toString() : String
Comm
andResponse
+ response_data: O
bject {readOnly}
+ Com
mandResponse(String, O
bject)+
toString() : String
SerializableCom
municationPacket
+ PACKAG
E_TYPE: byte {readOnly}
+ Com
municationPacket(byte)
+ toString() : String
FindPhone
~ FindPhone()
IncomingCall
+ caller_nam
e: String {readOnly}
+ caller_phone_num
ber: String {readOnly}
+ Incom
ingCall(String, String, String)+
toString() : String
IncomingM
essage
+ sender_nam
e: String {readOnly}
+ Incom
ingMessage(String, String, String)
+ toString() : String
Message
+ m
essage_text: String {readOnly}
+ phoneNum
ber: String {readOnly}
+ M
essage(byte, String, String)+
toString() : String
MessageDeliveryStatus
+ M
essageDeliveryStatus(String)
MessageStatus
+ status: String {readO
nly}
+ M
essageStatus(byte, String)+
toString() : String
OutgoingM
essage
+ deliveryIntent: boolean {readO
nly}+
scAddress: boolean {readOnly}
+ sentIntent: boolean {readO
nly}
+ O
utgoingMessage(String, boolean, String, boolean, boolean)
+ toString() : String
SendingMessageStatus
+ SendingM
essageStatus(String)
UTM 526.1.260 ME Coala
50
Mod Coala Nr. document Semnat. Data
ANEXA 2 Diagrama de activități pentru Trimiterea mesajului.
act Sending messages
PhoneNetworkComputer
Send
Create OutgoingMessage
object
Serialization
Sending ov er socket Network packet switching Create PedingIntent
Sending message v ia GSM network
Sending message statusNetwork packet switchingStatus deliv ered
Sending over
UTM 526.1.260 ME Coala
51
Mod Coala Nr. document Semnat. Data