conținut licență

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:


10


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.


11


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)


12


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.


13


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.


14


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


15


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.


16


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


17


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


18


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


19


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


20


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


21


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.


22


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ă:


23


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).


24


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.


25


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.


26


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


27


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


28


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


29


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()


30


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ă.


31


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


32


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


33


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


BroadcastReceiverIncomingCallBroadcastReceiv er


BroadcastReceiverIncomingSMSBroadcastReceiv er

~ ACTION: String = "android.provid... {readOnly}


BroadcastReceiverSendStatusMessageBroadcastReceiv er


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


34


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


35


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


36


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


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


37


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


38


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:


39


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.


Internet Computer

3. Stabilirea cerințelor de sistem minime necesare proiectului. 1 zi


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


40


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


10. Implementarea modulelor de comunicare prin intermediul canalului. 3 zile Programator 2


11. Implementarea modului de securizare a canalului. 2 zile Programator 1


12. Implementarea funcției de transmitere primire a mesajelor. 2 zile Programator 1

Programator 2


13. Implementarea funcției de notificare a apariției unui apel de intrare. 1 zi Programator 1

Programator 2


14. Implementarea funcției de găsire a telefonului. 1 zi Programator 1

Programator 2


15. Realizarea interfeței grafice de manipulare cu canalul creat. 4 zile



16. Testarea primului prototip 2 zile Programator 1 Programator 2

Computer, Telefon

17. Depanarea primului prototip 2 zile Programator 1 Programator 2


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


41


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.


42


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


43


http://www.sparxsystems.com.au/products/ea/index.html

http://www.sparxsystems.com.au/products/ea/index.html

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).


44


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)


45


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


46


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.


47


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.


48


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)


49


http://developer.android.com/index.html

https://stackoverflow/

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)


Close

+ Close()

Comm

and

+ com

mand: String {readO

nly}

+ Com

mand(byte, String)

+ Com

mand(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)


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)


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)


SendingMessageStatus

+ SendingM

essageStatus(String)


50


ANEXA 2 Diagrama de activități pentru Trimiterea mesajului.

act Sending messages


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


51


conținut licență

Documents