Analiza domeniului de studiu [305537]

[anonimizat] a lucrării de diplomă și a domeniul de studiu. Descrierea începe cu analiza domeniului și a platformelor și limbajelor ce vor fi utilizate cu tot cu avantaje și explicarea cauzei utilizării lor.

Internetul este o [anonimizat]. La rețeaua Internet pot fi conectate toate tipurile de calculatoare. Toate calculatoarele conectate la Internet fac schimb de informații. [anonimizat]. Totuși, anumite rețele conectate la Internet sunt controlate de anumite companii. În fiecare lună rețeaua Internet se extinde cu milioane de utilizatori. Viitorul Internetului este deosebit de promițător. Programele utilizate devin din ce în ce mai prietenoase și mai ușor de folosit.

În această lucrare voi analiza detaliat realizarea unui sistem informațional ”Monitorizare disciplinei de munca al angajaților”. Sistemul de monitorizare a angajaților este creat pentru a monitoriza și raporta datele privind efectuarea distribuțiilor de pliante. Pe parcursul lucrării voi explica și voi aduce dovezi de necesitate a unui astfel de sistem pe piața noastră. Voi trece în revistă modelul arhitectural după care urmează a [anonimizat]. Pe parcursul lucrării voi pune accent pe importanța temei alese și a domeniului. [anonimizat].

Pentru a realiza un astfel de sistem este nevoie de cunostințe în domeniul dezvoltărilor aplicațiilor WEB , a sistemelor distribuite precum și cunoașterea proiectării bazelor de date. [anonimizat]. [anonimizat], [anonimizat].

[anonimizat], avîntul cărora a “explodat” și tinde să se mărească încontinuu. [anonimizat] a informaticii – ar fi nepotrivit să nu luăm în considerație noile tehnologii dezvoltate în ultimii cinci ani de zile. Una din cele mai mari realizări din aceste domenii a fost crearea rețelei globale Internet la sfîrșitul anilor ’90 ai secolului trecut.

Internetul este o [anonimizat]. La rețeaua Internet pot fi conectate toate tipurile de calculatoare. Toate calculatoarele conectate la Internet fac schimb de informații. [anonimizat]. Totuși, anumite rețele conectate la Internet sunt controlate de anumite companii. În fiecare lună rețeaua Internet se extinde cu milioane de utilizatori. Viitorul Internetului este deosebit de promițător. Programele utilizate devin din ce în ce mai prietenoase și mai ușor de folosit. [1]

[anonimizat], cît și avîntul răspîndirii telefoanelor mobile de ultimă generație cu acces la Internet, putem concluziona că aplicațiile WEB și cele mobile vor fi tot mai întrebate, mai ales că interacțiunea aplicațiilor mobile cu cele WEB nu-i atît de greu de realizat. Mai mult ca atît, și marketing-ul online a sporit considerabil în ultimii ani și atrage venituri tot mai mari.

Alegerea temei și argumentarea ei

Monitorizarea angajatilor poate imbraca diferite forme in contextul dezvoltarii tehnologice actuale: monitorizarea telefoanelor, a e-mailului, a activitatii pe Internet, monitorizarea video etc, însă scopul tuturor modurilor de monitorizare este de a analiza performanța angajaților de către angajator.

În cadrul acestui proiect am studiat modul în care companiile de publicitate organizează proiecte de distribuție a pliantelor și modul în care angajații(distribuitorii) sunt monitorizați.

Analizînd cîteva companii și modul lor de distribuire a pliantelor, mi-am pus întrebare cum clientul rămîne sigur și mulțumit de împărțirea lor, din această cauză am și ales această temă. Nici o companie din cele ce oferă servicii de distribuire a pliantelor nu oferă sisteme de monitorizare a acestui proces. Analizînd aplicațiile Web, piața aplicațiilor mobile și posibilitățile sistemelor WEB+mobile, am concluzionat că un asemenea sistem ar fi un avantaj în prestarea acestui gen de serviciu. Asftel în cît în parteneriat cu una din companiile de publicitate din Chișinău am decis să realizăm acest sistem.

Sistemul va fi realizat în limba română, engleză și rusă și utilizînd mecanismele de localizare sistemul ușor poate comuta între aceste limbi. Sistemul include în sine 3 module:

modulul de administrare;

aplicația mobilă a distribuitorilor;

interfața client.

Funcțiile îndeplinite de partea de administrare sunt:

înregistrarea utilizatorilor și asigurarea autorizării acestora;

înregistrarea clienților(companiilor);

înregistrarea distribuitorilor;

înregistrarea dispozitivelor mobile;

înregistrarea și modificarea planelor de distribuție a pliantelor.

Funcțiile îndeplinite de aplicația mobilă sunt:

înregistrarea în cadrul sistemului;

start/Stop distribuire;

captare imagini.

Funcțiile îndeplinite de interfața client sunt de vizualizare a:

distribuțiilor curente;

distribuțiilor deja terminate;

istoricului;

simulare mișcare distribuitor;

capturare imagine.

Comparație cu alte sisteme existente

În cadrul proiectării sistemului dat, am analizat alte soluții prezente pe piață. Din păcate pe piața autohtonă nu am găsit produse asemănătoare, dar am găsit exemplare elocvente pe piața străină.

În urmare, aș dori să prezint scurt aceste sisteme și dispozitive, să le compar evidențiind punctele slabe și forte ale acestora. În cadrul studiului efectuat am evidențiat următorii lideri de piață:

http://www.soundwave.com/apps.html

Soundwave este o aplicație pentru smartphone, care urmărește cîntecele de pe smartphone. Soundwave urmărește preferințele muzicale a utilizatorilor și formează liste de cîntece personalizate. Utilizatorii pot urmări preferințele muzicale între ei, facilitînd astfel ascultarea, popularizarea, descoperirea și Users follow each other, facilitating listening, sharing, discovery, and dezbaterea muzicii vechi și noi. Una din caracteristicile interesante ale acestei aplicații este „MusicMap”. Utilizatorii aplicației pot desena pe hartă un poligon și urmări ce muzică a fost ascultată recent în acea arie. Aplicația este reprezentată în Figura 1.1 .

Figura 1.1 – MusicMap – Soundwave

http://mygeotracking.com/

MyGeoTracking este un sistem de monitorizare și management a angajaților. El reprezintă un sistem format din aplicația mobile pentru angajatori și aplicația web pentru angajați. MyGeoTracking este un sistem foarte puternic, care o face una din liderii pieții. MyGeoTracking colectează automat informații non-personale despre vizualizarea site-urilor Web și anume data și timpul vizitei. Interfața principală a sistemului este reprezentată în Figura 1.2 .

Figura 1.2 – MyGeoTracking

StreetSmart http://smart.clicksoftware.com/products/overview/product-features/

StreetSmart reprezintă o platformă foarte dezvoltată, care va permite să vă focusați pe nevoile clienților, fără a vă face griji de interacțiunile dintre anagajații de oficiu și cei mobili.

Angajații din oficii sunt conectați cu angajații mobile utilizînd sistmeul de management web, oferind-ule o vizibilitate sporită și putere management a activitătilor ce se petrec în sectoare.

Aplicația Street Smart Mobile App transformă dispozitivele mobile în tool-uri productive, care le permit angajaților să își monitorizeze orele lucrate, să acceseze tascurile curente și să colecteze informație. În Figura 1.3 este reprezentat sistemul StreetSmart.

În urma studiului efectuat asupra sistemului am observat că un punct forte a acestuia este detalizarea task-urile și rapoartelor care se generează în urma lucrărilor pe sectoare, oferindu-se informații despre calitate, timp și statuturi.

Figura 1.3 – StreetSmart

TSheets https://www.tsheets.com

TSheets se prezintă ca a fi sistem GPS de monitorizare în timp a agnajaților mobili cu un design destul de intuitiv și pritenos. Compatibil cu mai multe sisteme e operare ce permite urmărirea locațiilor, sarcinilor și a timpului. Figura 1.4 interfața sistemului Tsheets.

Figura 1.4 – Tsheets

Trackster http://www.phonetrackingemployees.com/

Trackster este un sistem simplist, care oferă un set de funcții de bază, fără rapoarte avansate, dar care își îndeplinește funcția principală, adică monitorizează angajații. Aplicația mobile de asemenea este una simplă și se potrivește pentru utilizatorii, care nu lucrează des cu aplicații mobile. Figura 1.5 reprezintă sistemul Trackster.

Figura 1.5 – Trackster

Avantajele și dezavantajele sistemelor evidențiate

Sistemul MyGeoTracking

Are următoarele avantaje:

vizualizare locație în moment real de timp, statut, alerte pe hartă;

urmărirea poziției echipei și generarea alertelor atunci cînd echipa intră sau iese din zona definită de regulile stabilite;

alocarea jobului echipei cele mai apropiate și preluarea statului de la locul lucrărilor cu geolocație, text sau mesagerie vocală;

calcularea orelor petrecute la serviciu și aggregarea orelor plătite;

estimarea timpului necesar pentru lucrări;

creșterea productivității cu circa 20% datorită inteligenței de monitorizare a locației și statului jobului;

vizualizarea tabelelor complexe;

aplicații mobile de a administra lucrul echipei, managerul pare la îndemînă mereu tabelele cu angajațiiși poate ușor vedea care este următorul serviciu ce trebuie să îl îndeplinească lucrătorul;

oferă companiilor mari gruparea lucrătorilor în echipe și stabilirea orelor lucrate;

compatibil cu Android, iPhone și alte platforme.

Dezavantaje:

Unicul dezavantaj pe care îl putem enunța este următorul, cu toate ca acesta este un sistem foarte complex cu multe facilități, dar nu este gratuit.

Sistemul StreetSmart

Avantaje:

modulul SmartView: cu ajutorul SmartView poți vedea la ce lucrează angajații și ce fac ei zi de zi;

avînd mai multe locații, poți vedea ce se întîmplă la fiecare din ele;

vizualizarea timpului petrecut de un lucrător la o locație și statutul acestuia;

vizualizarea rutei efectuată de lucrător și compararea cu ruta determinată;

o deosebire de celelalte sisteme, este acelă că acest sistem notifică cu un semnal sonor cînd lucrătorul întîrzie;

toate datele care sunt colectate de pe dispozitive mobile sunt instantaneu pe aplicație și pot fi transmise către manager sau alte persoane de vîrf;

vizualizarea statului fiecărui lucrător;

vizualizarea locației fiecărui lucrător pe Google Map;

primirea și expediere în timp real a mesajelor de alertă;

monitorizarea timpului de lucru și sumarea acestuia.

Dezavantaje:

Ca majoritatea sistemelor de acest tip, este unul cu plată, dar luînd în calcul posibilitățile acestuia, se merită investițiile.

Sistemul TSheets

Pentru manageri:

locația în timp real a angajaților;

vizibilitatea statutului;

facturare clienți;

DOL(date pentru departamentul fiscal);

design simplu;

Pentru angajați:

lucru eficientizat prin alocare de taskuri;

statut de lucru;

DOL pentru angajați;

siguranța confidențialității.

Sistemul Trackster

Avantaje:

interfață prietenoasă, dar simplistă;

oferă posibilitatea monitorizării lucrătorilor;

vizualizarea istoricului;

redirecționarea lucrătorului pentru sarcini mai importante utilizînd Google Map pentru a determina cine este mai aproape;

monitorizarea timpului petrecut la locul de muncă și sumarea lui pe un termen de o lună;

mesagerie instantanee despre actualizări fără a fi apelat fiecare lucrător în parte;

urmăririle se efectuiază doar în orele de lucru.

Dezavantaje:

sistemul este contra-plată, pentru o lună achiți 1.99$, cel mai ieftin sistem;

rapoarte simpliste, fără multe detalii.

Cu toate că fiecare din aceste sisteme este contra-plată, luîn în calcul avantajele lor,timpul și banii care îi poate salva, își merită oricare dintre acestea investițiile necesare.

Scopul sistemului

Managementul monitorizării angajaților este crearea unui cadru de lucru în care oamenii pot da, cele mai bune rezultate, manifestîndu-și competențele. Sistemul de monitorizare ajută managerii să administreze sarcinilor atribuite angajaților precum și timpul petrecut la fiecare sarcină. Aplicația client a sistemului de monitorizare permite clienților companiei să monitorizeze activitatea distribuitorilor în cadrul proiectelor active precum și să obțină rapoarte a proiectelor deja finisate. Scopul aplicației este de a permite clienților să obțină notificări în timp real despre activitatea distribuitorilor în cadrul proiectului enrolat.

Notificările pot fi de cîteva tipuri, cum ar fi:

modificare statut distribuție;

captură imagine;

alertă de părăsire a ariei de distribuție.

Pe lîngă activitatea de vizualizare a notificărilor, clineții pot filtra distribuitorii pe hartă, pot vizualiza istoricul distribuției precum și simula activitatea de distribuție a angajaților în timp grăbit.

Proiectarea sistemului utilizînd limbaje de modelare

Limbajul UML – limbajul de destinație generală al modelării vizuale, elaborat pentru specificarea, vizualizarea, construirea și documentarea componentelor produsului soft, business-proceselor și altor sisteme. UML este un mijloc de modelare simplu și puternic care poate fi utilizat efectiv pentru construirea modelelor conceptuale, logice și grafice ale sistemelor complexe de diferită destinație. UML este un instrument standard pentru crearea carcaselor de documentare («desenelor») ale produsului soft. . UML este elaborat în așa fel că să poată satisface cerințele către modelarea oricărui sistem începînd cu sisteme informaționale de dimensiunea unei întreprinderi pîna la Web-aplicații distribuite și sisteme integrate în timp real.

Ca și oricare limbaj, UML constă dintr-un dicționar și reguli care permit combinarea cuvintelor de intrare și primirea construcțiilor cu sens. În limbajul de modelare dicționarul și regulile sunt orientate spre reprezentarea conceptuală și fizică ale unui sistem.

Dicționarul limbajului înclude trei tipuri de construcții de bază:

entități – abstracții ce sunt elemente de bază a modelului;

relații – legături între entități;

diagrame ce grupează interesele entităților și relațiilor.

Entități sunt elementele OO de bază ale limbajului. Cu ajutorul entităților este posibilă crearea modelelor corecte. În UML sunt 4 tipuri de entități:

de structură – reprezintă părți statice ale modelelor care corespund elementelor conceptuale și fizice ale sistemului;

de comportament – descriu comportarea modelului în timpul și în spațiu;

de grupare – reprezintă blocuri în care poate fi divizat modelul;

de adnotare – sunt părțile explicative ale unui model UML.

Relațiile în UML reprezintă modul în care este arătat modul de interacțiune între entități. Există cîteva tipuri de relații:

dependență;

asociere;

agregare;

generalizare;

realizare.

În cadrul limbajului UML toate reprezentările modelului unui sistem complex sunt fixate în calitate de construcții speciale grafice care deseori sunt reprezentate sub formă de graf conex cu noduri – entități și muchii – relații numit diagramă. Fiecare din aceste diagrame detalizează și concretizează diferite reprezentări despre modelul unui sistem complex în termenii limbajului UML.

Descrierea responsabilităților. Cerințele sistemului

Sistemul informațional care urmează a fi implementat are ca scop informatizarea obiectului de distribuție a pliantelor. Partea client a sistemului care este creată în cadrul acestui proiect va fi disponibilă în trei limbi română, engleză și rusă. Deoarece partea client este destinată clienților companiei, ea trebuie să aibă o interfață cît mai simplă și prietenoasă, oferind toate instrumentele necesare pentru a asigura transparența procesului de distribuție.

De asemenea, luînd în considerare obligațiunile pe care și le asuma sistemul, trebuie evitate cazurile de indisponibilitate a serverului pe care este instalată baza de date a clienților, asigurîndu-se o conexiune stabilă la Internet. Pentru a evita suprasolicitarea serverului cu cereri fictive trebuie să fie instalată o aplicație anti-DDoS care să opună rezistență atacurilor de tipul Distributed Denial of Service.

Cerințele funcționale ale sistemului

Cerințele funcționale ale sistemului reprezintă descrieri ale serviciilor oferite de către sistem și a constrîngerilor care sunt generate de-a lungul desfășurării procesului de dezvoltare a proiectului.

Pornind de la cerințele utilizator discutate în urma negocierii contractului am definit următoarele cerințe către partea client a sistemului:

Cerințele funcționale ale unui Sistem Informațional sunt servicii pe care sistemul trebuie să le ofere. Ele precizează cum trebuie SI să reacționeze la anumite intrări și cum trebuie să se comporte în anumite situații particulare. De asemenea, din cerințele funcționale ale sistemului nostru vor face parte atît business cerințele, cît și cerințe ale utilizatorului.

În contiuare vom specifica cerințele funcționale care au stat la baza elaborării proiectului:

vizualizarea distribuțiilor curente;

generare alerte:

început distribuție;

sfîrșit distribuție;

fotografie nouă încărcată;

distribuitorul a părăsit zona de distribuție;

distribuitorul a intrat în zona de distribuție;

vizualizare istoric;

simulare mișcare distribuitori;

simulare istoric;

generare raport de distribuție.

Cerințele nefuncționale ale sistemului

Cerințele non-funcționale reprezintă constrîngeri ale serviciilor și funcțiilor oferite de sistem cum ar fi constrîngeri de timp, constrîngeri ale procesului de dezvoltare, standarte, constrîngeri privind performanța sistemului sau alte constrîngeri.

Ce sunt de fapt cerințele nefuncționale? Cerințele nefuncționale pot fi cerințe legate de atributele de calitate a produsului, cerința privind performanța, respectarea unor standarde, regulamente, contracte sau alte constrîngeri.

interfața utilizator trebuie să reprezintă o aplicație web de tip „One page application” implementată în HTML utilizînd biblioteca AngularJS;

sincronizarea cu serverul trebuie efectuata cu ajutorul tehnologiei SignalR;

dimensiunea maximă a pozelor 10MB;

precizie poziționare distribuitori 10 metri;

întîrziere în timp real față de poziționarea distribuitorului 1 minut;

posiblitate transmitere poze de către utilizaotri cu ajutorul rețelei Wi-fi sau GSM;

disponibilitatea subsistemului client în 3 limbi: română, rusă și engleză.

Diagrama de context și tabelul Gantt

Sistemul de monitorizare a angajaților este format din 3 module și realizat de către 3 developeri. Pentru a reprezenta modul în care dezvoltatorii vor coopera în cadrul proiectului utilizăm tabelul Gantt reprezentat în tabelul 2.1.

Tabelul 2.1 – Tabelul Gantt

Sarcina de bază a acestui sistem o putem reprezenta prin diagrama de context a aplicației, Figura 2.1 :

Figura 2.1 – Diagrama de context corespunzătoare Sistem de monitorizare a angajaților

În Figura 2.2 este reprezentat sistemul prin diagrama de decompoziție corespunzătoare. Diagrama data reprezintă caracteristicile de bază ale sistemului și funcționalitățile acestuia.

Figura 2.2 – Diagrama de decompozitie A0 corespunzătoare Sistem de monitorizare a angajaților

Diagrama caz de utilizare

În Figura 2.3 este reprezentat diagrama cazurilor de utilizare pentru utilizatorul cu rol de administrator. Funcțiile de bază ale acestuia fiind:

adăugarea distribuitorilor;

adăugarea dispozitivelor mobile;

adăugarea planului de distribuție;

generare rapoarte;

adăugare client.

Figura 2.3 – Rolurile administratorului în sistem

Din diagram dată observăm, că administratorul are un rol foarte important în cadrul sistemului, el este cel care se ocupă de crearea entităților din cadrul sistemului cum ar fi: distributori, dispozitive mobile, clienți. Odată ce apar clienți în cadrul sistemului, acestora li se pot crea plane de distribuție. După ce distribuția a fost efectuată administratorul poate genera rapoartele de distribuție.

Conform figurii 2.4 vedem că clientul are următoarele activități:

vizualizare distribuție;

vizualizare distribuție trecută;

vizualizare simulare distribuție;

vizualizare istoric;

vizualizare rapoarte.

Figura 2.4 – Diagrama Use Case pentru funcționalitățile clientului

Clientul este cea mai importantă entitate a sistemului, deoarece ea este cauza creării sistemului. El poate efectua acțiuni devizualizare a datelor generate de sistem. De asemenea el poate genera rapoarte pentru a vedea succint rezultatele distribuției pliantelor.

Figura 2.5 ilustrează activitățile distribuitorului.

Figura 2.5 – Funcționalitățile distribuitorului

Distribuitorul este entitatea sistemului care efectuiază distribuția propriu-zisă și anume datele care sunt preluate de pe dispozitivele mobile utilizate de distribuitori reprezintă sursa pentru rapoartele generate de sistem. Distribuitorii au rolul de a efectua periodic poze, care sunt afișate pe harta din interfața clienților.

Conform figurii 2.6 vedem activitățile care se pot realiza la operațiunea de generare a raportului.

Figura 2.6 – Rapoartele în sistem

Sistemul permite generarea a 3 tipuri de rapoarte:

raport zilnic;

raport total;

raport distribuitor.

Raportul zilnic include activitatea distribuitorilor în ziua aleasă din opțiunile raportului. Raportul total include activitatea totală pentru planul de distribuție creat, iar raportul distribuitor include activitatea distribuitorului ales în cadrul planului de distribuție efectuat. Rapoartele sunt generate de către client, utilizînd aplicația client.

Diagrama de secvență

Figura 2.7 reprezintă diagrama de secvență corespunzătoare procesului de autentificare a utilizatorului în sistem.

În cadrul diagramei avem următoarele obiecte: utilizatorul, baza de date, loginUI, authenticationController, userVmCuserCredentialsVm, userRepository, HashHelper, AuthenticationService.

Figura 2.7 – Autentificarea unui utilizator în sistem

Diagrama dată include actorul generic user, care se autentifică în cadrul sistemului, introducînd numele de utilizator și parola.

Odată ce acesta a transmis datele introduse către sistem, acestea sunt validate la nivel de manager, prin extragerea credențialelor cu același nume și compararea hash-urilor parolelor.

În cazul în care datele sunt valide și corespund cu cele din baza de date utilizatorul este autentificat în sistem, în caz contrat este afișată o eroare.

Conform figurii 2.8 observăm că în procesul de adăugare client participă următoarele obiecte:

administrator;

clientRegistrationUI;

clientController;

clientRepository;

clientValidator;

baza de date.

Figura 2.8 – Adăugarea unui client

Diagrama dată include actorul generic administrator, care adaugă un client nou în cadrul sistemului. Odată ce acesta a transmis datele introduse către sistem, acestea sunt validate la nivel de repozitoriu, prin verificarea dacă în cadrul sistemului nu mai sunt asemenea clienți.

Digrama din figura 2.9 reprezintă procesul de vizualizare a unui proiect. În acest proces participă următoarele obiecte: client, ClientWebUI, HomeController, ProjectManager, ProjectRepository, DistributorsRepository, DeviceRepository și baza de date.

Pentru a vizualiza detaliile despre un proiect, observăm că este necesar de a transmite un identificator unic al proiectului, care identifică datele din sistem care țin de proiectul dorit de a fi vizualizat.

Pentru a colecta toate datele, este nevoie de a fi accesate cîteva colecții și baze de date, în primul rînd sunt accesate datele privind proiectul dorit din baza de date a clientului în cauză, după care utilizînd id-urile din datele obținute sunt accesate și datele privind dispozitivele și distribuitorii implicați în proiect.

Figura 2.9 – Vizualizarea unui proiect

Diagrama 2.10 reprezintă procesul de notificare a utilizatorilor despre recepționarea unei noi imagini. În diagramă este arătat întregul flux de date, începînd cu transmiterea datelor de pe aplicația mobile, salvarea acestora în baza de date și pînă la transmiterea datelor către serviciul de comunicare în timp real, care la rîndul său transmite datele către client.

Figura 2.10 – Transmiterea notificării de recepționare a unei noi imagini

Diagrama de colaborare

În Figura 2.10 putem vedea diagrama de colaborare la nivel de exemplu:

Figura 2.10 – Autentficarea unui utilizator în sistem

Diagrama dată include actorul generic user, care se autentifică în sistem, prin introducerea numelui de utilizator și a parolei corespunzătoare.

Odată ce acesta a transmis datele introduse către sistem, acestea sunt validate la nivel de manager, prin extragerea credențialelor cu același nume și verificarea parolelor. Deoarece parolele în baza de date nu sunt păstrate în clar, parola introdusă de către utilizator de asemenea este criptată și comparată cu has-ul care este înregistrat în baza de date. Dacă hash-urile parolelor corespund, atunci utilizatorul este autentificat în sistem.

În figura 2.11 putem vedea diagrama de colaborare corespunzătoare procesului de vizualizare a unui proiect.

În acest proces participă următoarele obiecte: client, ClientWebUI, HomeController, ProjectManager, ProjectRepository, DistributorsRepository, DeviceRepository și baza de date.

Diagrama dată include actorul client, care introduce id-ul proiectului pentru a vizualiza proiectul dorit. Datele necesare sunt extrase din baza de date utilizînd id-ul introdus de către client.

Datele sunt păstrate în baze de date diferite. Datele despre proiect sunt păstrate în baza de date a clientului. Datele privind distribuitorii implicați în cadrul proiectului de distribuție, cît și dispozitivile mobile implicate sunt păstrate în baza de date sistem.

După necesare sunt extrase din baza de date, acestea sunt agregate și transmise către client.

Figura 2.11- Vizualizarea unui proiect

În figura 2.12 putem vedea diagrama de colaborare la nivel de specificare.

Figura 2.12 – Distribuția pliantelor

Diagrama de clasă

Diagrama de clasă conform, figurii 2.13, reprezintă pachetul Centru de administrare. Acesta are ca scop administrarea întregului sistem.

Figura 2.13 – Centru de administrare

În această diagram este reprezentat partea de administrare a sistemului, care include controloarele și modele necesare pentru crearea entităților din cadrul sistemului.

Conform figurii 2.14 putem observa diagrama de clasă corespunzătoare pachetului Services. Acesta are ca scop :

procesarea;

validarea;

agregarea datelor.

Atunci cînd utilizatorul introduce date pentru a fi salvate în baza de date acesta sunt validate și procesate de către manageri și transmiși către repozitorii pentru a fi salvate în baza de date.

Cînd utilizatorul dorește să acceseze careva pagini cu date, acestea sunt accesate utilizînd manager-ul. Acesta are rolul de a agrega datele și de a le transmite către controloare pentru a fi prezentate către utilizatori și clienți.

Altfel spus nivelul de manageri repezintă fațada infrastructurii, este punctul de acces prin care utilizatorii și clienții sistemului efectuiaza operațiile CRUD.

Figura 2.14 – Pachetului Services

Figura 2.15 reprezintă pachetul Infrastructure, care este poziționat vertical fața de restul pachetelor, adică este utilizat de către mai multe nivele ale arhitecturii sistemului.

Acest pachet conține în primul rînd mecansimsul generic de efectuare a următoarelor operații asupra bazei de date :

Add – adăguarea unei T item într-o colecție;

FindAll – selectează toate elementele de tip T din colecția specificată;

FindBy – permite selecția unui element T din colecția specificată conform id-ului specificat ca parametru;

Remove – șterge elementu-ul T;

Update – actualizează elementul T.

Pe lîngă drive-ul bazei de date, pachetul infrastructure conține multiple clase ajutătoate care permit criptarea datelor, serilizare și deserializare, operare cu imagini, extensii MVC și clase pentru oferirea securității. De asemenea aici se regăsesc și cheile de configurare care permit configurarea sistemului la instalarea pe IIS.

Figura 2.15 – Pachetului Infrastructure

Diagrama data include în sine nivelul de resurse, adică nivelul care efectuiaza operațiile CRUD cu baza de date. El este consumat de către nivelul de servicii.

Conform figurii 2.16 putem analiza diagrama de clasă corespunzătoare pachetului Tracking Web Center. Acesta reprezintă modulul Client al sistemului. Este un proiect ASP.NET Web API care utilizează de asemenea și tehnologiile de One-Page-Aplication.

După cum vedem de asemenea din diagramă în acest pachet este inclus și mecanismul de localizare, care ne permite să schimbăm limba utilizată în cadrul aplicației client utilizînd fișiere de tip “resx”, care nu sunt nimic altceva de cît niște fișiere xml cu un set de chei și un set de valori. Astfel pentru a adăuga o limbă nouă este nevoie doar de mici schimbări în fișierul sursă a paginii web, cît și un fișier adăugator de tip “resx”, care va conține aceleași chei, dar cu valorile corespunzătoare în limba adăugată.

Figura 2.16 – Pachetului Tracking Web Center

În această diagram este reprezentat partea de client a sistemului, care include controloarele și modele necesare pentru vizualizarea distribuțiilor de către clienții sistemului.

Diagrama de stări

Diagrama de stare pentru procedura de autentificare este afișată în figura 2.17.

Figura 2.17 – Controlorul LoginController

Diagrama dată include controlorul LoginController și stările acestiua.

La început se afișează pagina de logare. După ce utilizatorul a introdus credențialele acestea sunt verificate și validate de către sistem.

Dacă datele sutn valide atunci utilizatorul este autorizat pentru a accesa sistemul și îi este creată sesiunea și cheile necesare sunt înscrise în cookie.

În cazul, în care credențialele sunt inroduse greșit, utilizatorul este redirecționat către pagina de autentificare cu mesajele de eroare corespunzătoare, fie de invaliditate a numelui de utilizatorul, fie de invaliditate a parolei introduse.

Stările procesului de înregistrare în cadrul sistemului este afișat în figura 2.18.

Figura 2.18 – Controlorul RegisterController

Diagrama dată include controlorul RegisterController și stările acestiua.

La început se afișează pagina de înregistrare. După ce utilizatorul a introdus datele acestea sunt procesate și salvate în baza de date, după care el este redirecționat la pagina principală.

În cazul în care au apărut erori în date, utilizatorului îi este afișată pagina de înregistrare și erorile apărute.

Diagrama de activități

În Figura 2.19 este arătat diagrama de activități pentru procesul de înregistrare a utilizatorului. Conform diagramei putem vedea care vor fi nivelurile atinse și interogările dintre acestea.

Figura 2.19 – Procedura de înregistrare

Diagrama dată indică procesul de înregistrare a utilizatorilor în sistem. Astfel odată introduse datele sunt validate, atît la nivel de business logică, cît și la nivel de existență a utilizatorului în baza de date. În caz că există utilizator cu asemenea nume de utilizator, în pagină este returnat un mesaj de eroare corespunzător. De asmenea se verifică dacă utilizatorul a reintrodus parola corect. Odată ce sunt valide datele acestea sunt salvate în baza de date.

Diagrama de activități corespunzătoare procesului de autentificare este afișat în figura 2.20. Diagrama dată ne permite să vedem activitățile care se efectuiză la procedura de autentificare în sistem. După cum vedem din diagramă utilizatorul transmite credențialele către server pentru a fi validate. Validarea este efectuată la nivel de UserManager. Acolo sunt extrase datele privind utilizatorii din sistem și comparate numele de utilizator cu cel introdus de către utilizator. Dacă nu a fost găsit utilizator cu numele specificat, este returnată o eroare. În caz că a fost găsit utilizator cu așa nume, sunt comparate parolele utilizatorilor. Parola în baza de date nu este păstrată în clar, ci este criptată în timpul înregistrării. De aceea pentru a compara parolele, este criptată și parola introdusă de către utilizator și apoi comparate hash-urile între ele. Dacă hash-urile parolelor nu sunt egale, atunci în pagină este afișat mesajul de eroare corespunzător, în caz contrar este creată sesiunea utilizatorului și salvate cheile necesare sub formă de cookie în browser-ul utilizatorului.

Figura 2.20 – Procesul de autentificare

Diagrama de componente

Diagrama 2.21 ne permite să analizăm pachetele întregului sistem. Deoarece acest sistem este unul bazat pe modelul MVC, pachetele de bază ale acestuia sunt:

routing component;

controllers;

views;

models.

Figura 2.21 – Controlorul LoginController

Diagrama dată indică structura pachetului TrackingCentre. Interogarea care vine de la utilizator este procesată de componenta de rutare, care decide care controller răspunde de interogarea dată. Se crează o instanță a controlerului și se decide care acțiune a fost chemată. Acțiunea procesează modelul date și returnează o viziune nouă.

Figura 2.22 – Componentele de autentificare

Diagrama dată ne permite să vedem relația dintre componentele care realizează procedura de autentificare în sistem.

Astfel pentru a ne autentifica în sistem trebuie să accesăm controlorul LoginController, care consumă serviciul de autentificare „AuthenticationService”. Acesta la rîndul său extrage datele din baza de date și utilizînd clasa ajutătoare „HashHelper” verifică veridicitatea certificatelor utilizatorului.

Diagrama de amplasare

Figura 2.23 reprezintă diagrama de amplasare a întregului sistem, care are ca scop prezentarea fizică a poziționării sistemului.

După cum vedem din diagrama dată sistemul poate fi distribuit fizic pe noduri, care se pot afla pe diferite calculatoare, comunicarea efectuînduse utilizînd protocoalele de rețea.

În cadrul sistemului se evidențiază următoarele noduri:

stație de lucru;

server DB;

dispozitiv mobil;

Employee Tracking System.

Figura 2.23 –Diagrama de amplasare a sistemului

Stația de lucru este un dispozitiv ce are conexiune la server. Modificarea datelor o face prin intermediul browser-ului accesând paginile .html de pe partea de server;

EmployeeTrackingSystem conține majoritatea componentelor sistemului și are instalate aplicațiile necesare. Acest nod execută codul executabil al tuturor componentelor;

EmployeeTrackingSystem.RealTimeCommunicationService este un serviciu de transmite a datelor către TrackingCentre;

Server DB gestionează operațiile cu baza de date.

MobileTrackingApplication este aplica mobile care este instalată pe dizpozitivele distribuitorilor, pentru a transmite notificări către sistem.

Realizarea sistemului

Pentru a realiza un sistem format din cîteva module care comunică utilizînd protocoalele de rețea, este nevoie de a studia tehnologii web și de a efectua alegerea corectă în modul în care va fi proiectată arhitectura sistemului pentru ca aceasta să fie cît mai ușor extensibilă și modificabilă.

În cadrul realizării a fost aleasă platforma .NET. Aceasta se datorează următoarelor avantaje:

consistența modelului de programare;

suport direct pentru securitate;

efort de dezvoltare simplificat;

implenetarre și întreținere simplă;

suport Linux și Mac.

Modelul de programare rămîne consistent indiferent de limbajul utilizat. Astfel accesînd careva date fie cu C# sau VB.Net, fără a lua în considerație mici divergențe de sintaxă, vor fi efectuați aceeași pași de includere a librăriei System.Data, ambele aplicații vor stabili o conexiune cu baza de date, vor lansa o interogare și vor afișa datele.

Depanarea aplicațiilor este relativ simpla, utilizînd debugger-ul putem să trecem pas-cu-pas prin cod-ul scris, detectînd erori de logică și locurile unde codul aruncă o excepție.

Securitatea aplicațiilor este asigurată de platforma .NET și permite specificarea nivelului și modului de securizare. Spre exemplu aplicațiile web utilizînd Owin security pot specifica autentificarea utilizatorilor utilizînd conturile facebook, google, microsoft etc.

Mentenanța și procedura de deployment este simplifcată datorită mediului de dezvoltare oferit de către platforma.

Dezvoltarea aplicațiilor este foarte simplă, astfel încît utilizînd programul asistent este posibilă construirea unei aplicații web într-un timp foarte scurt.

Modulul client a sistemului are ca scop de a oferi o experiență de utilizare cît mai simplă pentru clienții companiei și este dezvoltat sub forma unei aplicație de tip one-page-application. Aceasta permite clienților să utilizeze sistemul similar cu o aplicație desktop.

Instrumente

În cadrul dezvoltării sistemului au fost utilizate cîteva instrumente de dezvoltare:

Visual Studio;

Team Foundation Server;

Fiddler;

Genymotion;

Robomongo.

Visual Studio include un set complet de instrumente de dezvoltare pentru generarea de aplicații ASP.NET, Servicii Web XML, aplicații desktop și aplicații mobile. Visual Basic, Visual C++, Visual C# și Visual J# toate folosesc același mediu de dezvoltare integrat (IDE) care le permite partajarea instrumentelor și facilitează crearea de soluții folosind mai multe limbaje de programare. Aceste limbaje permit să beneficieze de caracteristicile .NET Framework care oferă acces la tehnologii cheie care simplifica dezvoltarea de aplicații web ASP și XML Web Services cu Visual Web Developer.

Visual Studio Team Foundation Server  (TFS) este produsul Microsoft pentru controlul codului sursă, de raportare și de urmărire a proiectului. Repository-ul de control al sursei este numit Team Foundation Version Control (TFVC).

Cu acest produs se pot crea o mare varietate de rapoarte. De exemplu, rata de modificare a codului sursă în timp, sau o listă de bug-uri care nu au scenarii de test.

Pe baza unui proiect, TFS creează de asemenea un site SharePoint pentru proiect, astfel integrând sarcini de control ale codului sursă si administrare de proiect.

Fiddler este aplicație server proxy pentru depanare HTTP. Acesta capturează traficul http și HTTPS și îl înregistrează pentru necesitățile utilizatorului. Acest de asemenea permite modificarea traficului http pentru necesități de depanare precum acestea ar fi transmise către utilizator. Anume această functionalitate a fost utilizată pentru a simula activității distribuitorilor la etapa de dezvoltare cînd aplicația mobilă nu era funcțională.

Genymotion este o aplicație de emulare a unui dispozitiv android. În versiunea sa gratuită, acesta permite simularea a circa 40 de dispozitive diferite și modul în care acestea vor reacționa la funcționalitățile aplicației. Această aplicație a înlocuit aplicația Fiddler în cadrul testării funcționalității sistemului, odată ce aplicația mobilă avea o versiune stabilă.

Aplicația Robomongo reprezintă o aplicație de managemenet a bazelor de date MongoDB. Aceasta permite vizualizarea bazelor de date, colecțiilor, precum și lansarea unor scripturi de inserare direct din aplicație. Aceasta a fost utilizată în mod special în cadrul depanării sistemului, atunci cînd erau depistate date eronate.

Structura proiectului, Domain driven design

Pentru elaboarea sistemului a fost ales principiul de proiectare orientat pe domeniu(Domain driven design). DDD reprezintă o abordare de dezvoltare software care permite interconectarea implementărilor unui model evolutiv. Premizele alegerii acestei abordări sunt:

plasarea atenției principale asupra domeniului de bază și a logicii acestuia;

necesitatea stabilirii modelului de business comun pentru toate 3 componente(aplicația mobilă, cenrul de comandă, aplicația client);

permite dezvoltarea concomitentă a mai multor module care folosesc aceleași modele de business.

În urma aplicării acestei abordări, proiectul a căpătat structură arhitecturală definită de în figura 3.1:

Figura 3.1 – Arhitectura sistemului

Conform structurii prezentate, în cadrul sistemului se regăsesc următoarele entități:

Domain Layer;

Repository Layer;

Service Layer;

Application Layer;

Presentation Layer;

Infrastructure Layer.

Domain Layer este nivelul în care se regăsesc modele de business din cadrul sistemului, conform principiilor DDD aceste modele se numesc root models adică modele de rădăcină, care agreghează alte modele din cadrul bazei de date;

Repositories Layer este nivelul cu repozitorii, reprezintă nivel acces de date. Acest utilizează driver-ul bazei de date pentru a efectua operațiile CRUD cu colecțiile acesteia. În dependența de numărul de modele din nivelul domain se crează același număr de repozitorii;

Service Layer este nivelul de servicii, acesta conține subnivelul de manageri, care oferă servicii nivelului de prezentare și consumă nivelul de repozitorii. Acestă agreghează datele utilizînd subnivelul de procesare(processorEngines) și le validează, utilizînd subnivelul de validare(validationEngine).

Application Layer este nivelul unde se regăsesc serviciile de procesare a cererilor din partea aplicațiiei mobile și serviciile de comunicare în timp real cu aplicația client.

Presentation Layer este nivelul de prezentare include aplicațiile mobile, client și de administrare, care au fost dezvoltate de membrii echipei.

Infrastructure Layer este nivelu de infrastructură este un nivel cross-cutting adică care întretaie toate nivele prezentate mai sus și include în sine clase ajutătoare, configurări, clase care efectuiază copierea obiectelor etc.

Baza de date

Deoarece proiectul este structurat conform principiilor DDD, iar modelul de business se modifică în cadrul proiectului datorită lucrului depus de către 3 direcții a sistemului, ca SGBD a fost ales MongoDB, care permite crearea bazelor de date și a colecțiilor fără necesitatea lansării cărorva scripturi la instalarea sistemului.

MongoDB este o bază de date NoSQL open-source orientată pe documente. Acestă bază de date beneficiază de suport din partea companiei 10gen. MongoDB face parte din familia de sistemelor de baze de date NoSQL. Diferența principală constă în faptul că stocarea datelor nu se face folosind tabele precum într-o bază de date relațională, MongoDB stochează datele sub formă de documente JSON cu scheme dinamice.[2]

MongoDB este o bază de date open-source NoSQL scrisă în C++. Aceasta poate conține mai multe baze de date, colecții și indecși. În unele cazuri (baze de date și colecții ) aceste obiecte pot fi create implicit. Odată create, ele se găsesc în catalogul sistemului db.systems.collection, db.system.indexes. Colecțiile conțin documente (BSON). Aceste documente conțin la rândul lor mai multe câmpuri. În MongoDB nu există câmpuri predefinite spre deosebire de bazele de date relaționale, unde există coloanele care sunt definite în momentul în care tabelele sunt create. Nu există schemă pentru câmpurile dintr-un document, acestea precum și tipurile lor pot varia. Astfel nu există operația de „alter table” pentru adăugare de coloane. În practică este obișnuit ca o colecție să aibă o structură omogenă, deși nu este o cerință, colecțiile putând avea structuri diferite. Această flexibilitate presupune ușurință în migrarea și modificarea imaginii de ansamblu asupra datelor.

Structura sistemului este creată în așa un mod încît dinamic este nevoie de a crea baze de date, pentru fiecare client în parte. Astfel în cadrul sistemului vom avea 1+n baze de date:

o bază de date penru administrare, care va conține informații privind clienții companiei, distribuitorii și dispozitivele înregistrate;

n baze de date, unde n reprezintă numărul de clienți în cadrul companiei, care vor conține date privind distribuțiile companiilor clienți.

Separarea datelor privind compania și privind distribuțiile clienților a fost făcută pentru securizarea datelor, astfel în orice moment se poate efectua un backup a datelor administrative fără necesitatea creării backup-urilor parțiale, se face un simplu backup la baza de date de administrare.

Deoarece datele în MongoDB sunt păstrate în formatul bson(format-ul json specific SGBD-ului) nu este nevoie de actualizat careva scripturi ale structurii tabelelor, driver-ul SGBD-ului automat va scrie datele în formatul necesar.

Datele care sunt înregistrate în cadrul bazelor de date pot fi vizualizate cu ajutorul aplicațiilor 3rd-party cum ar fi RoboMongo reprezentată în figura 3.2.

Figura 3.2 – Aplicația RoboMongo

Modulul de comunicare în timp real

Modulul de comunicare în timp real ocupă un rol primordial în cadrul proiectului. Ideea de a prezenta clienților informația în timpul procesului de distribuție a fost realizată datorită creării acesstui modul. Pentru obținerea rezultatelor dorite a fost utilizată tehnolgoia oferită de biblioteca SignalR.

ASP.NET SignalR este o librărie pentru dezvoltatorii ASP.NET care simplifică procesul de adăugare a funcționalității de timp real pentru aplicațiile web. Funcționalitatea real-time este abilitatea de a permite codului server-side de a transmite date către clienții conectați odată ce aceasta devine disponibilă, fără a fi necesar ca server-ul să aștepte cereri din partea clientului.[3]

Deși SignalR procesează managementul conexiunilor automat și permite transmiterea broadcast a mesajelor către toți clienții simulta, în cadrul proiectului a fost importantă utilizarea transmiterii mesajelor private clienților, astfel încît un client să primească informația doar despre distribuția sa. Față de conexiunile clasice HTTP, care sunt restabilite pentru fiecare cerere, SignalR oferă o conexiune persistentă între clienți și server.[3]

SignalR suportă funcționalitatea de „server push”, prin care codul server invocă codul client din browser utilizînd RPC(Remote Procedure Calls), în loc de modelul cerere-răspuns obișnuit pentru web.[3]

În figura 3.3 este reprezentat modul de comunicare SignalR.

Figura 3.3 – Modul de comunicare SignalR

Serviciul de comunicare în timp real, în cadrul sistemului realizat reprezintă de fapt o aplicație consolă, care lansează în interior serviciul SignalR hostat cu un URL care poate fi accesat de către instanțele aplicației web.

Hubul „PromoterHub” conține în sine următoarele metode:

JoinGroup;

AlertDistributorOutOfArea;

UpdateDistributorStatus ;

LocationReceived;

DistributionLeafletEvidenceTaken .

JoinGroup se utilizează pentru crearea unui grup de comunicare între distribuitorii implicați în distribuție și instanța browser care se conectează la Hub.

AlertDistributorOutOfArea este metoda care notifică clientul, despre faptul că un distribuitor a părăsit area de distribuție, acesta primește ca parametri id-ul distribuitorului precum și id-ul clientului.

UpdateDistributorStatus este metodă, care transmite date privind modificarea statului de distribuție a distributorului implicat într-un proiect. Această metodă are ca parametru un obiect, care conține id-urile distribuitorului și a clientului, timpul notificării, precum și statutul transmit, care poate fi activ sau inactiv.

LocationReceived este metoda de bază a mecanismului de notificare și are drept rol transmiterea locației distribuitorului, ca parametru de intrare obiectul transmis conține id-urile distributorului și a clientului precum și latitudinea și longitudinea.

DistributionLeafletEvidenceTaken este metoda care transmite date privind o imagine creată de distribuitorul care a transmis notificarea, obiectul – parametru de intrare pe lîngă id-urile distributorului și a clientului și dată mai conține și url-ul imaginii, iar byte-ii imaginii vor fi recepționați utilizînd ASP.NET Web.Api 2.2

Pentru interacțiunea modulului de comunicare în timp real cu aplicația web a clientului, aceasta trebuie să încarce în pagină biblioteca SignalR precum și să inițieze conectarea la hub-ul „PromoterHub”, care va invoca metodele necesare de procesare a datelor. Procedura de conecare la serviciul SignalR este reprezentată de următoarea porțiune de cod javascript:

try {

$.connection.hub.logging = false;

$.connection.hub.url = "@signalr/signalr";

$.connection.hub.start({ transport: ['longPolling'] })

.done(function () {

$.connection.promoter.server.joinGroup('@Model.CustomerID.ToString()');

})

.fail(function (error) {

console.log("Failed to start the hub." + error);

});

$.connection.hub.error(function () {

window.location.href = "~/Views/Home/Error.cshtml";

console.log('services are stopped');

});

} catch (e) {

console.log('services are stopped');

window.location.href = "~/Views/Home/Error.cshtml";

}

După cum vedem din cod, conectarea la serviciu poate crea erori, în cazul în care serviciul nu este conectat, în acest caz este afișată pagină cu eroare.

Tehnologia utilizața la transmiterea datelor că tre clienți este ‚longPolling’, adică Serverul va transmite datele atunci cînd le obține, fără a fi necesar ca clientul să ceară aceste date. În așa mod hub-ul de fapt invocă metodele de pe partea client. Respectiv este strict necesar cunoașterea denumrii metodelor care vor procesa datele pe client de către hub. Spre exemplu metode da de transmitere a unei capturi foto, vom arăta bucata de cod de pe hub, cît și codul javascript:

public void DistributionLeafletEvidenceTaken(DistributionLeafletEvidenceVm distributionLeafletEvidence)

{

Clients.Group(distributionLeafletEvidence.CustomerID.ToString()).NewPhotoReceived(distributionLeafletEvidence);

}

promoter.client.newPhotoReceived = function (distributionLeafletEvidence) {

pushDistributionLeafletEvidence(distributionLeafletEvidence);

distributionLeafletEvidence.timeout = notificationTimeOut;

notifyLeafletRecieved(distributionLeafletEvidence);

var leaflet = {

imageUrl: distributionLeafletEvidence.postedImageUri,

distributorName: distributionLeafletEvidence.distributorName,

createdDate: distributionLeafletEvidence.createdDate,

areaID: distributionLeafletEvidence.areaID

}

comunicationService.sendEvent(leaflet);

$scope.$apply();

};

ASP.NET MVC

ASP.NET este o tehnologie Microsoft pentru crearea de aplicații web și servicii web. ASP.NET este succesorul lui ASP (Active Server Pages) și beneficiază de puterea platformei de dezvoltare .NET, și de setul de instrumente oferite de mediul de dezvoltarea al aplicației „Visual Studio .NET”.[4]

Cateva dintre avantajele ASP .NET sunt:

ASP .NET are un set larg de componente, bazate pe XML, oferind astfel un model de programare orientat obiect (OOP);

ASP .NET ruleaza cod compilat, ceea ce crește performanțele aplictiei web, codul sursa poate fi separat în două fișiere, unul pentru codul executabil, iar un altul pentru continutul paginii (codul HTML și textul din pagină);

NET este compatibil cu peste 20 de limbaje diferite, cele mai utilizate fiind C# si Visual Basic.

Model-view-controller (MVC) este un model arhitectural utilizat în ingineria software. Succesul modelului se datorează izolării logicii de business față de considerentele interfeței cu utilizatorul, rezultând o aplicație unde aspectul vizual sau/și nivelele inferioare ale regulilor de business sunt mai ușor de modificat, fără a afecta alte nivele.[5]

Model

Această parte a controlatorului manipulează operațiunile logice și de utilizare de informație (trimisă dinainte de către rangul său superior) pentru a rezulta de o formă ușor de înțeles.

Viziune

Acestui membru al familiei îi corespunde reprezentarea grafică, sau mai bine zis, exprimarea ultimei forme a datelor: interfața grafică ce interacționează cu utilizatorul final, rolul său este de a evidenția informația obținută până ce ea ajunge la controlator.

Controlator

Cu acest element putem controla accesul la aplicația noastră. Pot fi fișiere, scripts sau programe, in general orice tip de informație permisă de interfață. În acest fel putem diversifica conținutul nostru de o formă dinamică și statică, în același timp.

Structura modelului arhitectural MVC este reprezentată în figura 3.4.

Figura 3.4 – Modelul Arhitectural Model-View-Controller

Structură

Cu ajutorul Controlatorului, modelului sau a viziunii putem manipula următoarele elemente: date. Depinde de noi cum manipulăm și interpretăm aceste "date". Acum cunoaștem că unicele date ale unei adrese web statice sunt: obținerea unui fișier în discul dur (hard disk) sau din Internet, etc. și, interpretat (recunoscut/decodificat) sau nu, serverul răspunde.

Modelul, precum controlatorul și viziunea manipulează toate datele ce se relaționeză cu el. Și numai Viziunea poate demonstra această informație. În acest fel am demonstrat ierarhia programului nostru: Controlator-Model-Viziune.

Logică

Pentru o aplicație web ușoara este necesar să stabilim următoarele elemente:

bază (CMV):

Controlator – acesta trebuie să fie capabil de a manipula rute, fișiere, clase, metode și funcții;

Model – este asemănător unui script obișnuit într-un server, doar că regrupat sub un model reutilizabil;

Viziune – asemănător includerii unui fișier în aplicația noastră;

un sistem:

Router – cu el putem împărți cerințele noastre fără multe condiționale;

Incărcător (Loader).

Aplicația client a sistemului de monitorizare a angajaților este de asemenea un proiect MVC, care conține în sine 3 controloare:

HomeController;

ErrorControlller;

CustomerController.

HomeController este controlorul care este utilizat pentru a stabili contextual current a clientului. Pentru a deschide aplicația client, este generat un URL unic al proiectului și atunci cînd se timpul de început al proiectului se apropie, clientul este notificat printr-un mail, unde îi este și transmis și acest URL. Controlorul conține 2 metode Index, care se diferă utilizînd atributul HttpPost.

Prima metodă este accesată de client utilizînd URL-ul transmis în mesajul de notificare. Aici este setat doar contextual de referință proiect și limba care va fi utilizată de client.

Cea de a 2-a metodă index este accesată doar în cazul în care s-a stabilit conexiunea cu modulul de notificare în timp real. Adică sa stabilit că sistemul funcționează. Această metodă furnizează datele privind proiectul în cauză, cum ar fi data, ora și numărul de pliante. Acesta furnizează de asemenea logoul companiei.

using System;

using System.Threading;

using System.Web.Mvc;

using BMPublic.Models.Customers;

using BMPublic.Models.Projects;

using BMPublic.Services.Customers;

using BMPublic.Services.Projects;

using BMPublic.TrackingCentre.Web.Code;

using BMPublic.TrackingCentre.Web.Models;

namespace BMPublic.TrackingCentre.Web.Controllers

{

public class HomeController : Controller

{

private readonly ICustomerManager customerManager;

private readonly IProjectRepository projectRepository;

private readonly IProjectManager projectManager;

public HomeController(ICustomerManager customerManager, IProjectRepository projectRepository, IProjectManager projectManager)

{

this.customerManager = customerManager;

this.projectRepository = projectRepository;

this.projectManager = projectManager;

}

public ActionResult Index(string referenceCode, Language? language)

{

RoutingVm routingVm = new RoutingVm();

if (referenceCode == null)

{

routingVm.Language = Language.Romanian;

Thread.CurrentThread.CurrentCulture = LocalizationHelper.GetCulture(routingVm.Language.Value);

Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;

return View("InputCode", routingVm);

}

routingVm = new RoutingVm()

{

ReferenceCode = referenceCode,

Language = language

};

return View("Home", routingVm);

}

[HttpPost]

public ActionResult Index(RoutingVm routingVm)

{

var customer = customerManager.GetByProjectReference(routingVm.ReferenceCode);

projectManager.SetCustomerContext(customer.ID);

var projectID = customer.GetProjectByReferenceCode(routingVm.ReferenceCode);

var project = projectRepository.FindBy(projectID);

routingVm.CustomerID = customer.ID;

routingVm.ProjectName = project.Name;

routingVm.Leaflet = project.Leaflet;

routingVm.StartDate = project.StartDate;

routingVm.EndDate = project.EndDate;

routingVm.NumberOfLeaflets = project.NumberOfLeaflets;

routingVm.CustomerName = customer.Name;

routingVm.Logo = customer.Logo;

if (routingVm.Language == null)

routingVm.Language = customer.Language;

Thread.CurrentThread.CurrentCulture = LocalizationHelper.GetCulture(routingVm.Language.Value);

Thread.CurrentThread.CurrentUICulture = Thread.CurrentThread.CurrentCulture;

return View(routingVm);

}

}

}

Controlorul ErrorController este utilizat pentru a afișează pagina cu erori în cazul în care sistemul nu funcționează corect.

CustomerController este un controlor WebApi și este apelat de către aplicația angular pentru a obține datele despre proiectul curent. Controlorul dat conține următoarele metode:

GetDistributionDetails;

GetDistributionImage.

GetDistributionDetails este utilizată pentru a furniza aplicației angular detaliile despre distribuția curentă. Această metodă primește ca parametru codul de referință a proiectului și utilizînd managerul de proiecte extrage toate datele privind proiectul în cauză, encapsulate într-o instanță a clasei DistributionDetailsVm.

GetDistributionImage este metoda care returnează imaginile încărcate de către distribuitori în cadrul proiectului. Acestea sunt cahce-uite pe partea client timp de 600 secunde.

using System;

using System.Collections.Generic;

using System.Configuration;

using System.Linq;

using System.Net.Http;

using System.Net.Http.Headers;

using System.Web.Http;

using BMPublic.Infrastructure.Helpers;

using BMPublic.Models.Distributors;

using BMPublic.Models.Projects;

using BMPublic.Services.Customers;

using BMPublic.TrackingCentre.Web.Code;

using BMPublic.TrackingCentre.Web.Models;

using BMPublic.Services.Projects;

using DistributorLocation = BMPublic.TrackingCentre.Web.Models.DistributorLocation;

using Vertex = BMPublic.TrackingCentre.Web.Models.Vertex;

namespace BMPublic.TrackingCentre.Web.Controllers

{

public class CustomerController : ApiController

{

private readonly IDistributorRepository distributorRepository;

private readonly IProjectManager projectManager;

private readonly ICustomerManager customerManager;

private readonly IImageHelper imageHelper;

private readonly Uri baseImageUri = new Uri(ConfigurationManager.AppSettings["postedImagesUri"]);

public CustomerController(IProjectManager projectManager, IDistributorRepository distributorRepository, ICustomerManager customerManager, IImageHelper imageHelper)

{

this.distributorRepository = distributorRepository;

this.projectManager = projectManager;

this.customerManager = customerManager;

this.imageHelper = imageHelper;

}

public DistributionDetailsVm GetDistributionDetails(string referenceCode)

{

var customer = customerManager.GetByProjectReference(referenceCode);

projectManager.SetCustomerContext(customer.ID);

var projectID = customer.GetProjectByReferenceCode(referenceCode);

projectManager.SetCustomerContext(customer.ID);

var project = projectManager.GetByID(projectID);

var areas = project.DistributionAreas;

var distributors = new List<DistributorVm>();

var distributorsLocations = new List<DistributorLocation>();

var distributorsActions = new List<DistributorActionVm>();

var distributionLeafletEvidencesVm = new List<DistributionLeafletEvidenceVm>();

var distributonAreas = new List<DistributionAreaVm>();

foreach (var area in areas)

{

if (area.DistributionPeriods == null)

break;

foreach (var distributionPeriod in area.DistributionPeriods)

{

if (distributionPeriod.Date.Date == DateTime.Now.Date)

{

distributonAreas.Add(new DistributionAreaVm()

{

ID = area.ID.ToString(),

Name = area.Name,

PolygonVertices = area.PolygonVertices.Select(vertex => new Vertex()

{

Latitude = vertex.Latitude,

Longitude = vertex.Longitude

}).ToList()

});

foreach (var engagedDistributor in distributionPeriod.EngagedResources)

{

var distributor = distributorRepository.FindBy(engagedDistributor.DistributorID);

var distributorVm = new DistributorVm()

{

ID = distributor.ID,

MobilePhone = distributor.MobilePhone,

Name = distributor.Name,

AreaID = area.ID

};

var distributorLocations = engagedDistributor.DistributorLocations;

var latitude = 47.0153720;

var longitude = 28.8288380;

if (distributorLocations.Any())

{

latitude = distributorLocations.Last().Location.Latitude;

longitude = distributorLocations.Last().Location.Longitude;

}

distributorVm.Location = new LocationVm()

{

Latitude = latitude,

Longitude = longitude

};

distributorVm.Status = engagedDistributor.DistributorActions.Any() ? (Status)engagedDistributor.DistributorActions.Last().Status : Status.Inactive;

distributors.Add(distributorVm);

foreach (var distributorLocation in engagedDistributor.DistributorLocations)

{

distributorsLocations.Add(new DistributorLocation()

{

CreatedDate = distributorLocation.DateTime,

DistributorID = engagedDistributor.DistributorID,

Location = new LocationVm()

{

Latitude = distributorLocation.Location.Latitude,

Longitude = distributorLocation.Location.Longitude

}

});

}

foreach (var distributorAction in engagedDistributor.DistributorActions)

{

distributorsActions.Add(new DistributorActionVm()

{

CreatedDate = distributorAction.Created,

Status = (Models.DistributorStatus)distributorAction.Status,

DistributorName = distributor.Name

});

}

foreach (var leaflet in engagedDistributor.DistributionLeafletEvidences)

{

distributionLeafletEvidencesVm.Add(new DistributionLeafletEvidenceVm()

{

AreaID = area.ID,

CreatedDate = leaflet.Created,

DistributorName = distributor.Name,

Location = new LocationVm()

{

Latitude = leaflet.Location.Latitude,

Longitude = leaflet.Location.Longitude

},

PostedImageUri = imageHelper.BuildImageResourceUri(baseImageUri, leaflet.ImageID.ToString()),

});

}

}

}

}

}

return new DistributionDetailsVm()

{

Areas = AutoMapper.Mapper.Map<List<DistributionArea>, List<DistributionAreaVm>>(project.DistributionAreas),

Distributors = distributors,

Leaflets = distributionLeafletEvidencesVm,

DistributorsActions = distributorsActions,

DistributorsLocations = distributorsLocations

};

}

[CacheControl(MaxAge = 600)]

public HttpResponseMessage GetDistributorImage(Guid distributorID)

{

var distributor = distributorRepository.FindBy(distributorID);

using (var thumbnail = imageHelper.GetThumbnail(distributor.DistributorPhoto))

{

HttpResponseMessage response = new HttpResponseMessage

{

Content = new ByteArrayContent(thumbnail.ToArray())

};

response.Content.Headers.ContentType = new MediaTypeHeaderValue("image/jpg");

response.Content.Headers.ContentLength = thumbnail.Length;

return response;

}

}

}

}

Single page application

O aplicație singel page (SPA) este o aplicație web sau un site web care este reprezentat de o singură pagina, care are scopul de a oferi o experientă asemănătoare cu cea aplicației desktop. Aplicația poate funcționa pe una din cele două principii:

încărcarea întregii aplicații – ceea ce este simplu de făcut în cazul unor aplicații web mici, care de fapt nu folosesc multe resurse, în cazul site-urilor complexe cu multiple functionalități cum ar fi magazin online, rețea de socializare, POS system etc, acest principiu nu este de preferat

încărcarea resurselor necesare, adică la prima încărcare se încarcă doar o mică parte a aplicației web, iar restul resurselor sunt încarcate dinamic ca răspuns a acțiunilor utilizatorilor[6].

În cadrul aplicațiilor singel page, pagina nu este încărcată niciodată și niciodata nu este transferat controlul către altă pagină, deși url-ul se poate modifica pentru a crea percepția navigării și pentru a permite navigarea la un modul separat utlerior direct, fără a fi necesar de a efectua careva acțiuni. Interacțiunea cu o aplicație singel page presupune comunicare dinamică cu serverul web în spate.

Aplicația client a sistemului dezvoltat în cadrul proiectului de diplomă de asemenea este o aplicație singel page, Este construit în baza unei aplicații ASP.NET MVC, astfel încît la prima încărcare a paginii sunt încărcate datele existente, harta și contextul utilizatorului. După ce sunt inițializate toate cele necesare, restul datelor sunt aduse dinamic utilizînd mecanismele SignalR.

Din punct de vedere tehnic partea client este realizată utilizînd una din cele mai populare arhitecturi care implementează principiile aplicațiilor single page și anume AngularJS. AngularJS este o arhitectură client-side. Șabloanele AngularJS se bazează pe UI data binding bidirecțional. Data binding reprezintă un mecanism automat de actualizare a paginii atunci cînd modelul este modificat și actualizarea modelului atunci cînd pagina este modificată, de aici și vine denumirea de binding bidirecțional. Șabloanele html sunt compilate direct de browser, acest procedeu este repetat de fiecare dată cînd se modifică modelul. În programarea trandiționala de server-side, conceptul de controlor este legat de server. Arhitectura AngularJS permite menținerea stării modelelor și a controloarelor pe partea client, astfel încît noi pagini pot fi generate fără necesitatea interacțiunii cu serverul.[7]

Pentru asigurarea extensibilității aplicației client, pagina nu este reprezentată de un singur controlor, ci de o întreagă arhitectură, astfel încît în orice moment de timp pot fi adăugate module și funcționalități noi fără afectarea celorlalte module.

Orice pagină care utilizează AngularJS începe cu un „ng-app”, adică aplicația însine sau altfel spus modulul care înregistrează toate controloarele, resursele, enginurile, procesoarele etc. Ng-app-ul pe care l-am creat include în sine următoarele componente:

ComunicationService;

Ienumerable;

CustomerRepository;

CustomerController;

EventHistoryController;

NotificationController.

ComunicationService reprezintă maginstrala sau un modul care asigură comincarea între controloare, deoarece am vrut să decuplez la maxim controloarele din cadrul aplicației construite astfel încît pe viitor să pot să activez și să dezactivez careva module în dependență de drepturile utilizatorului. Comunicarea se efectuiază prin publicarea unui mesaj și ascultarea de către receptor a mesajului. Putem privi acest mecanism ca cel implimentat în cazul unui simplu event-listener a evenimentului de click în cadrul unei pagini web și a unei „bucăți de cod” javascript (vezi Anexa A).

Ienumerable reprezintă o metodă de encapsulare a mecanismelor bine cunoscute în limbajul C#, a operării cu colecțiile de date. Astfel pentru a utiliza metodele standarte de firstOrDefault, First, Where etc am creat această clasă care îmi permite să extind colecțiile utilizate în cadrul sistemului.

CustomerRepository reprezintă modulul acces de date a datelor privind distribuția, acesta este consumat de către alte module și este consumat direct de către controloarele deoarece el nu reprezintă un controlor în sine și nu era nevoie să îl decuplez de controlorul, care îl utilizeaza. Deoarece datele sunt aduse în pagina în mod asincron, pentru funcționare sa utilizat mecanismul de $promise. Acesta este un mecanism oferit de către framewark-ul AngularJS, care permite returnarea unei promisiuni în loc de rezultatul anticipat, iar atunci cînd datele sunt aduse de pe server, utilizînd callback-ul datele sunt aduse în controlorul care consumă serviciul oferit de repozitoriul dat.

CustomerController este controlorul de bază din cadrul aplicației, care setează contextul clientului și inițializează comunicarea cu celelalte controloare. El de asemenea inițializează harta și de asemenea aplică modificările necesare atunci cînd mecanismul SignalR transmite date noi. Vizual controlorul reprezintă întreaga pagina, adică harta și panoul cu ariile de distribuție, care pot fi afișate sau ascunse la alegere. Controlorul de asmenea răspunde și de așa numitul regim „simulare” – adică vizualizarea istoricului distribuției în regim accelerat, precum ai vizualiza un video la viteză sporită.

EventHistoryController reprezintă controlorul care răspunde de istoricul de distribuție. Vizual acesta reprezintă o panelă pe care sunt afișate în mod cronologic toate acțiunile făcute de către distribuitorii implicați în contextul distribuției setate de CustomerController (vezi Anexa B).

NotificationController este un controlor care răspunde de afișărea notificărilor în pagină. Atunci cînd mecanismul SignalR transmite date către CustomerController, acesta la rîndul său utilizînd magistrala de comunicare ComunicationService, notifică controlorul NotificationController despre o activitate nouă, iar acesta la rîndul său o afișează în pagină. Vizual el reprezintă un set de pop-up care apar atunci cînd ceva se întîmplă în cadrul distribuției setate de către CustomerController.

Descrierea și utilizarea sistemului

Acest capitol este destinat descrierii detaliate a sistemului creat și modul în care putem opera cu funcționalitățile acestuia. Urmează o prezentare sumară a posibilităților sistemului.

Sistemul de monitorizare a resurselor umane este un sistem complex, bazat pe tehnolgoii web ASP.NET cît și tehnologii mobile Android și IOS. Sistemul este format din 3 module:

modulul de administrare;

modulul de monitorizare;

modulul client.

Din cele 3 module enumerate mai sus, partea de administrare și partea client sunt bazate pe tehnologiile web, iar partea de monitorizare reprezintă partea care este construită sub formă de aplicație mobile Android și IOS. Această suită de module împreună oferă o functionalitate complexă de monitorizare a distribuțiilor de pliante și de prezentare a acestor date într-un mod user friendly clienților companiei în cauză.

Funcționalitățile de bază ale sistemului sunt:

înregistrarea utilizatorilor și asigurarea autorizării acestora;

înregistrarea clienților(companiilor);

înregistrarea distribuitorilor;

înregistrarea dispozitivelor mobile;

înregistrarea și modificarea planelor de distribuție a pliantelor;

înregistrarea în cadrul sistemului;

start/stop distribuire;

captare imagini;

afișărea distribuțiilor curente;

persistarea unui istori;

simulare mișcare distribuitor;

vizualizare poziționare distribuitor în timp real;

generare raport de distribuție.

Instalarea și configurarea sistemului

Sistemul este format din 2 aplicații web și 3 servicii sub formă de aplicații desktop. Astfel pentru funcționarea sistemului este necesară instalarea aplicațiilor web pe serverul IIS și de asemenea este necesară prezența instanței SGBD-ului MongoDB. În urmare voi prezenta modul în care este instalat sistemul de gestiune a bazei de date MongoDB și modul în care este instalat serverul IIS și aplicațiile pentru el.

Pentru a instala SGBD-ul MongoDB, este nevoie de downloadat fișierul sursă msi pentru sistemul de operare windows, conform figurei 4.1:

Figura 4.1 – Site-ul web pentru SGBD MongoDB

Odată ce fișierul a fost downloadat acesta poate fi instalat fie prin programul ajutor sau utilizînd consola. Pentru a instala SGBD-ul utilizînd consola este nevoie de a deschider o instanță prompt de comandă în regim administrator și de a lansa comanda din figura 4.2.

msiexec.exe / t / i MongoDB-win32-x86_64-2008plus-ssl-3.2.6-signed.msi ^

InstallLocation = "C: \ MongoDB" ^

ADDLOCAL = "all".

Figura 4.2 – Comanda de instalare a SGBD-ului MongoDB

Pentru a instala aplicațiile web pe IIS, trebuie mai întîi de a activa IIS din Windows Feature, pentru aceasta deschideți Panoul de Administrare-> Windows Feature reprezentat în figura 4.3 și verificați dacă sunt setate bifele pentru IIS Managemenet Service.

Figura 4.3 – Windows Features

Odată ce este instalat serverul IIS, este necesar de a crea aplicațiile web pentru modulul de administrare și modulul client. Interfața serverului IIS este reprezentată în figura 4.4.

Figura 4.4 – Interfața serverului IIS

Pentru a instala aplicațiile web, mai întîi este necesar crearea unui site web, făcînd dublu click pe mapa Sites și alegearea opțiunuii „Add website” și introducînd datele necesare în formularul din figura 4.5.

Figura 4.5 – Formularul de adăugare web site

După ce a fost adăugat site-ul web este nevoie de a adăuga aplicațiile pentru modulul client și modulul de administrare. În formularul de adăugare aplicație, reprezentat în figura 4.6, se specifică alias-ul aplicației și folderul unde se află modulul pe calculator.

Figura 4.6 – Formularul de creare aplicație

Pentru proiectul dat de asemnea este nevoie de a crea și un folder virtual care va fi utilizat pentru accesarea imaginilor încărcate de distribuitori și logo-urilor clienților. Folderul creat trebuie să fie formatat conform cheilor de configurare prezente în aplicație, conform figurei 4.7.

<appSettings>

<add key="queueName" value=".\private$\LeafletDistribution" />

<add key="postedImagesPath" value="D:\images" />

<add key="SignalRSelfHostedUrl" value="http://localhost:81" />

<add key="postedImagesUri" value="http://localhost/images/" />

</appSettings>

Figura 4.7 – Cheile de configurare a aplicației

Conform acestor chei se crează directoriul virtual utilizînd forma de creare reprezentată în figura 4.8

Figura 4.8 – Forma de creare a unui director virtual

Prezentarea aplicației client

Aplicația client din cadrul sistemului de monitorizare a resurselor umane este aplicație singel page, care are drept scop oferirea detaliilor de despre distribuția comandată. Aceasta are o interfată user-friendly, care include o hartă, în care sunt afișate ariile de distrubție și poziționarea distribuitorilor în aceste arii.

Prima pagină cu care este întîmpinat clientul, reprezentată în figura 4.9, este pagina unde acesta introduce codul referință a proiectului, fie pentru a vizualiza procesul de distribuție a proiectului, fie pentru a extrage raportul privind distribuția deja efectuată.

Figura 4.9 – Introducere a codului distribuției

Dacă distribuitorul introduce codul de referință și face click pe butonul de încărcare proiect, datele despre proiect sunt încărcate în pagină, în acest timp utilizatorului îi sunt afișate informațiile despre proiectul de distribuție în cauză, conform figurei 4.10.

Figura 4.10 – Landing Page aplicația client

Odată ce au fost încărcate datele despre proiectul de distribuție, este afișată harta și panourile ajutătoare, conform figurei 4.11

Figura 4.11- Interfața totală a sistemului

Ariile de distribuție pot fi ascunse sau afișăte la necesitate, conform figurei 4.12. Iar pentru comoditate istoricul mișcării distribuitorilor poate fi lansată cu un timp mai rapid, adică putem simula mișcarea distribuitorilor și notificările care au apărut în cadrul distribuției.

Figura 4.12 – Panoul cu arii

Istoricul distribuției se află în partea stîngă-jos și reprezintă o listă de acțiuni a distributiorilo în cadrul proiectului de distribuție,reprezentat în figura 4.13, dintre acțiunile care pot fi afișate sunt:

captură imagine – o imagine nouă a fost capturată de către distribuitor și transmisă către server, procesată și apoi transmisă clientuluil(fig 4.16);

statut distribuție – distribuitorul poate fi în una din două staturi:start și stop(figura 4.14 și figura 4.15);

alertă părăsire arie de distribuție – în cazul în care distributorul a părăsit aria de distribuție, atunci client de asemenea este notificat(figura 4.17).

Figura 4.13 – Panoul cu istoric

În partea dreapta-sus se află zona în care apar notificările, de asemenea acolo se află și iconițele pentru a schimba limba.

Figura 4.14 – Notificare statut activ al distribuitorului

Figura 4.15 – Notificare statut inactiv al distribuitorului

Figura 4.16 – Notificare captură imagine

Figura 4.17 – Notificare părăsire arie de distribuție

Argumentarea economică

Din punct de vedere a angajatorului, timpul cheltuit de către angajat este timpul pe care acesta trebuie să îl achite în schimbul muncii pe care angajatul o îndeplinește. Din afirmația precedentă rezultă că pentru angajator este foarte important ca timpul care el îl achită angajatului să fie folosit în scopurile îndeplinirii muncii stabilite și cu un randament cît mai mare. Sistemele de monitorizare a angajaților sunt instrumente care permit controlul calității lucrului pe care îl îndeplinește angajatul, dar care și permite managaementul personalului, stabilirea cărorva obiceiuri pe care le au toți angajații și care trebuie permise sau care trebuie interzise.

Scopul sistemului dat este de asemenea de a monitoriza angajații în cadrul îndeplinirii serviciului și anume distribuirea pliantelor. Ideea de bază a sistemului vine din simpla întrebare a angajatorului care va fi descrisă mai jos.

Să presupunem o companie X, care produce și comercializează produse alimentare de înaltă calitate, dar care nu sunt cunoscute de potențialii clienți. Pentru a crește cererea către produsele comercializate, compania X decide să facă o campanie de marketing care va include panouri publicitare, spoturi și distribuții de pliante. Deoarece procedura de creare a spoturilor, a pliantelor și a imaginii pentru panouri, precum și stabilirea contratctelor cu posturile TV, proprietarii panourilor și a distribuitorilor de pliante este destul de complexă și va necesita mult timp și resurse financiare, cît și resurse umane, compania X decide să apeleze la serviciile oferite de compania Y, care va crea spoturile publicitare și imaginea pentru pliante și panouri și de asemenea va efectua contractele cu companiile terțe pentru afișarea spoturilor publicitare, arenda panourilor și de asemenea stabilirea contractelor cu distribuitorii de pliante care reprezintă de fapt angajații companiei Y. Dacă în cazu spoturilor publicitare este evident dacă acesta apar la TV sau nu și panourile sunt sau nu sunt afișăte în străzi, în cazul distribuțiilor de pliante pot apărea întrebări din partea companiei X. Aceste întrebări vin din încrederea sau neîncrederea că distribuțiile de pliante întradevăr vor fi efectuate. Astfel compania X poate nu poate de unde să cunoască dacă distribuția de pliante întradevăr a avut loc și că pliantele nu au fost aruncate în urnă de către persoanele care de fapt trebuie să împartă aceste pliante.

Sistemul de monitorizare a resurelor umane care este dezvoltat în cadrul acestui proiect de diplomă are drept scop asigurarea companiei „X”, descrise anterior, că proiectul de distribuție într-adevăr va fi efectuat. Acest lucru este posibil prin vizualizarea în timp real a poziționării distribuitorului în timpul desfășurării proiectului de distribuției și obținearea capturilor de imagine de la fața locului. Mai mult ca atît acest sistem permite managementul eficient a resurselor umane în cadrul companiilor de publicitate, astfel în cît atunci cînd este creat un proiect de distribuție a pliantelor este vizibil care dintre distribuitori este disponibil pentru a fi implicat în cadrul proiectului în cauză.

Din punct de vedere al potențialului consumator al sistemului, acesta este ceva nou pentru piața din Republica Moldova, oferind control și încredere asupra distribuției de pliante. Proiectul poate avea un succes enorm doar în cazul în care va fi adusă la cunoștință clienților companiei despre utilitatea acestuia și demonstrarea modului în care acesta trebuie utilizat.

Planul calendaristic

Scopul de bază al proiectului este elaborarea unui sistem informațional web, pe platforma ASP .NET, care ar permite monitorizarea resurselor umane. Accentul pus în cadrul acestui proiect este distribuția de pliante și monitoizarea distribuitorilor în cadrul lor. Adică sistemul trebuie să includă o serie de module care ar permite gestionarea distribuitorilor și a activități efectuate de către aceștea. Pentru atingerea unor astfel de rezultate, au fost formulate clar o serie de obiective, îndeplinirea deplină a cărora ar duce la atingerea scopului de bază al proiectului. Proiectul este realizat în 3 etape de către 3 dezvoltatori:

crearea modulului de genstionare a distribuitorilor în cadrul proiectelor în care sunt enrolați;

crearea modulului mobil ncesar pentru a transmite date din cadrul distribuțiilor;

crearea modulului de monitorizare a distribuitorilor în timp real.

Modulul de monitorizare a distribuitorilor, care este descris în acest memoriu explicativ își propune următoarele obiective de bază:

vizualizarea distribuitorilor de pliante în timp real;

crearea istoricului de distribuției;

simulare mișcare distribuitori pe hartă;

alerte de distribuție;

crearea rapoartelor despre distribuția efectuată.

Planul calendaristic include informația referitoare la executarea în timp a acțiunilor planificate. În procesul de realizare a proiectului au fost implicați următorii executanți:

conducătorul proiectului (C) – cu scopul de proiectare și de coordonare a resurselor disponibile (umane și materiale) necesare pentru realizarea proiectului;

programatorul (P123) – sarcina căruia a fost de a dezvolta modulele software server și client, precum și aplicația mobilă;

tester (T) – rolul căruia a fost de a testa și de a depista defecte ale sistemului;

proiectant(P) – rolul căruia a fost de a proiecta arhitectura sistemului.

Planul calindaristic cu sarcinile efectuate de fiecare executant în parte, este reprezentat în tabelul 5.1.

NOTĂ: Prezentul proiect este realizat de aceeași persoană pentru a demonstra capabilitățile și cunoștințele acumulate pentru toți anii de studii, executantul real al proiectului este conducătorul proiectului scopul căruia este de a demonstra că este capabil să realizeze sarcinile pentru un:  coordonator, programator și tester.

Tabelul 5.1 – Reprezentarea etapelor de dezvoltare a proiectului

Continuare Tabel 5.1

Calculele manoperei muncii pentru executorii de proiect:

– Conducătorul proiectului : 23 zile;

– Proiectant : 17 zile;

– Programatorii : 40 zile;

– Tester : 10 zile.

În Tabelul 5.1. sunt reprezentate etapele de dezvoltare a proiectului integral, inclusiv timpul necesar pentru crearea celor 3 module ale sistemului, precum și numărul de zile de dezvoltare pentru fiecare etapă. Dezvoltarea întregului proiect a fost realizată timp de 90 de zile lucrătoare, fiecare zi lucrătoare fiind formată din 8 ore de lucru.

NOTĂ: Prezentul proiect este realizat de o echipă de 3 persoane, care în cadrul tabelului sunt notați cu P1,P2 și P3.

Analiza SWOT

În Tabelul 5.2 este reprezentată Analiza SWOT a proiectului care are ca scop ajutarea la proiectarea unei viziuni de ansamblu asupra unui proiect, unei firme.

Tabelul 5.2 – Analiza SWOT

Calculul indicatorilor economici

Investiții în active material și nemateriale pe termen lung

Realizarea oricărui proiect necesită cheltuieli de dezvoltare și investiții, unele dintre care fiind necesare calculate pînă la realizarea proiectului pentru a stabili finanțele disponibile. Deoarece proiectul dat este realizat în cadrul proiectului de licență, au fost alese tehnologii și resurse care ar aduce cît mai puține cheltuieli materiale. Proiectul „Monitorizarea resurselor umane” este unul de tip comercial, scopul căruia este de a aduce venit proprietarului de produs.

Pentru a calcula corect beneficiile financiare pe care îl poate aduce un proiect, este necesar inițial de a identifica caracteristicile proiectului, unde el va fi utilizat, care pot fi potențialii utilizatori și nu în ultimul rînd suma de bani investită în realizarea acestuia care va reprezenta costul produsului. Costul de producție reprezintă totalitatea cheltuielilor, corespunzătoare consumului de factori de producție pentru producerea și vînzarea sistemului.

În Tabelul 5.3 sunt reprezentate investițiile materiale și nemateriale pe termen lung.

Tabelul 5.3 – Investiții materiale și nemateriale pe termen lung

Consumuri directe de materiale

În Tabelul 5.4 sunt reprezentate consumurile directe de producție.

Tabelul 5.4 – Consumul direct de materiale

Continuare Tabel 5.4

Consumuri directe privind retribuirea muncii

La finile proiectului fiecare angajat va fi remunerat cu 10% în plus la salariu pentru a stimula lucrul angajaților. În Tabelul 5.4 este reprezentat salariul contractual pe o zi și Fondul de retribuire a muncii în baza căruia se calculează contribuția de asigurări sociale de stat obligatorii și prima de asigurare obligatorie de asistență medicală.

Tabelul 5.5 – Retribuirea muncii

În Tabelul 5.6 este calculat Fondul asigurării sociale și Fondul asigurării medicale, conform formulelor 5.1 și 5.2:

FAS = FRM * Cfs(%) (5.1),

unde:

Cfs – cota contribuțiilor de asigurări sociale de stat obligatorii. Conform „Legii bugetului asigurarilor sociale de stat pe anul 2015” contribuția la bugetul asigurărilor sociale de stat obligatorii, suportata de angajator, constituie 23% din fondul de remunerare a muncii.

FAM = FRM * Cam(%) (5.2),

unde:

Cam – Cota primei de asigurare obligatorie de asistență medical. Conform „Legii privind fondurile asigurării obligatorii de asistență medicală pe anul 2015”, cota primei de asigurare obligatorie de asistență medicală suportata de angajator constituie 4,5 % din fondul de remunerare a muncii.

Calculcul Fondul asigurării sociale pentru programatorul 3 conform formulei 5.1:

FAS = 18080 lei x 23 : 100 = 4158 lei

Calculcul Fondul asigurării medicale pentru programatorul 3 conform formulei 5.2:

FAM = 18080 lei x 4,5 : 100 = 813.6 lei

Tabelul 5.6 – Contribuțiile FAS și FAM

Angajatul Programator3 va beneficia de un venit brut anual în sumă de 101800 lei. Astfel vom calcula suma netă a venitului obținut de această persoană în baza prevederilor legale.

Calculăm reținerile în fondul de pensionare FP și fondul Asigurare Medicală (FAM):

FP = 6% x 101800 = 6108 lei

FAM = 4,5% x 18080 = 4581 lei

Calculăm venitul impozabil, conform formulei 5.3:

VI = VB-FP-FAM-SP-SiP-SM (5.3),

unde:

VI – venitul impozabil;

VB – venitul brut;

FP- fondul de pensionare (asigurări sociale);

FAM – fondul de Asigurare Medicală;

SP – scutirea personală;

SiP – scutirea pentru persoană întreținută;

SM – scutirea personală majoră.

VI = 101800 – 6108 – 4581 – 10128 = 80983 lei

Impozitul pe venit este calculate conform formulei 5.4:

IV=VI-I ( lei) (5.4),

unde:

I – Impozit pe venit;

pentru venituri anuale de pina la 29640 lei–se aplica cota de impozitare 7%;

pentru venituri mai mari de 29640 lei–se aplica cota de impozitare 18%.

Impozitul pe venit pentru angajatul Porgramator3 este calculat conform formulei 5.4:

IV= 29640 x 7% + (80983 -29640) x 18% = 2074,8 + 9241,74 = 11316,54 lei

Suma venitului net este calculat conform formulei 5.5:

VN=VB-IV-FP-FAM (5.5),

unde:

VB – venitul brut;

IV – impozit pe venit;

FP – fondul de pensionare (asigurări sociale);

FAM – prima de Asigurare Medicală.

Suma venitului net anual pentru programatorul3 este de 79794.46 lei.

VN = 101800 – 11316,54 – 6108 – 4581 = 79794.46 lei

Consumuri indirecte

În Tabelul 5.7 sunt reprezentate cheltuielile privind consumurile indirecte la dezvoltarea proiectului, cum ar fi:

arenda încăperii;

energia electrică;

servicii Internet;

servicii transport.

Tabelul 5.7 – Consumuri indirecte

Uzura mijloacelor fixe

Uzura mijloacelor fixe reprezintă repartizarea sistematică a valorii uzurabile a mijloacelor fixe în decursul durate de funcționare utilă. Durata utilizării activului se determină după categoria lui. AMTL – 3-5 ani, ANTL –  2-3 ani. Fondul amortizării este calculat conform formulei 5.6:

FA = Vi :DFU x T1 (5.6),

unde:

FA – fondul amortizarii, lei;

MFi – valoarea de intrare;

T1 – durata proiectului;

DFU – durata de funcționare utilă .

Fondul amortizării pentru calculator este calculat conform formulei 5.6:

FA = 16000 : 1825 x 90 = 789 lei

În Tabelul 5.8 este reprezentat uzura activelor materiale și nemateriale pe termen lung

Tabelul 5.8 – Uzura mijloacelor fixe

Costul de Producție

Costul de Producție al modulului reprezintă totalitatea cheltuielilor care sunt suportate pentru dezvoltarea și mentenanța modulului. Acestea sunt reprezentate în Tabelul 5.9.

Tabelul 5.9 – Costul de elaborare a modului Client

Calculul indicatorilor economico – financiari

Etapa data se efectuează pentru a determina prețul de realizare a proiectului. Constul total al sistemului este calculat în tabelul 5.10:

Tabelul 5.10 Costul de elaborare al sistemului

Acest sistemeste elaborat în cadrul unei companii de publicitate și oferit ca serviciu pentru clienții săi. Sistemul este unic în Republica Moldova, de aceea prețul de referință a fost obținut în baza sistemelor asemănătoare de pe piețe străine. În urma analizei de marketing, compania a stabilit prețul de livrare a produsului de 500 de lei. Pentru a face calculul indicatorilor economico – financiari utilizăm metoda „up – down”. Prețul de realizare a produsului este calculat conform formulei 5.7:

Prz = Plv + TVA (5.7),

unde:

Prz – preț de realizare;

Plv – preț de livrare;

TVA – taxa pe valoarea adăugată, egal cu 20%.

Prețul de realizare a serviciului oferit se calculează conform formulei 5.7:

Prz = 500 + 100 = 600 lei

Calculu venitului brut din vînzări este calculat conform formulei 5.8:

VVB=q x Prz , lei (incl TVA) (5.8),

unde:

q – nr. de copii planificate spre comercializare.

Efectuînd analiza vînzărilor pentru anul precedent sa stability o cifră de aproximativ 500 de clienți pentru anul current care vor beneficia de serviciul dat:

VVB = 500 x 600 = 300 000 lei

Profitul brut de realizare a proiectului se calculează în modul următor:

Pb=VVN-CT = 300 000 – 216733 = 83 267lei (5.9),

unde:

VVN – suma netă a venitului din vînzări fără TVA;

CT- costul total de realizare a proiectului.

Profitul net se calculează prin deducerea taxelor și impozitelor în vigoare din suma impozabilă în modul următor:

PN=Pb-Iv = 83 267 – (83 267 x 12 : 100) = 66 613 lei,

unde:

Iv – impozit pe venit conform legislației.

În urma calculelor realizate, utilizînd metoda „up-down” am obținut un profi net de 66 613 lei anual.

Sistemul elaborat în cadrul proiectului de licență este realizat pentru o companie de publicitate din Republica Moldova. Acest sistem este revoluționar și unic la noi în țară și va avea o mare popularitate prin comoditatea de utilizare și efectul care îl aduce asupra încrederii clienților față de companie. Dezvoltarea proiectului este realizată de către o echipă tînără, care deși efectuiază lucrarea într-un timp mai îndelungat de cît cel enunțat în cadrul planului calendaristic, nu necesită asemenea salarii mari, din această cauză prețul brut al sistemului este cu mult mai mic.

Concluzii

Elaborînd această lucrare de practică, am studiat și analizat un business nou, cel de monitorizare disciplinei de muncă al angajaților. Am proiectat și stabilit interacțiunea componentelor acestui sistem complex format din partea Web și cea mobilă. Am stabilit cerințele funcționale și ne-funcționale pe care le va îndeplini sistemul. Scopul primordial a fost acela de analiză a business-ului și a platformelor de lucru pentru ca în viitor să se realizarea implementarea. Am făcut o analiză cu sistemele deja existente pentru a scoate în evidență avantajele sistemului și a concluziona ce se poate de modificat pentru acest sistem complex.

În timpul efectuării lucrării am stabilit funcționalitățile actorilor cum ar fi: manager, client, distribuitor și am stabilit cum va avea loc procedura de autentificare, de adăugare a unui client si proiect, de monitorizare a distribuitorului de către sistem și alte proceduri de care este capabil acesta.

Sistemul are ca scop menirea ca să asigure distribuirea pliantelor la locul stabilit de client și asigurare că acestea au ajuns în mîinele potențialilor beneficiari de servicii, produse sau reducere care sunt reclamante pe pliante.

BIBLIOGRAFIE

CISCO, Ce trebuie să știți despre rețelele wireless [Resursă electronică]. – Regim de acces: http://www.cisco.com/web/RO/solutions/smb/products/wireless/wireless_primer.html

Kristina Chodorow MongoDB: 50 Tips and Tricks for MongoDB Developers[Text]/ Kristina Chodorow; O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472 – ISBN: 978-1-449-30461-4.

Introducere în SignalR[Resursă electronică]. – Regim de acces:

http://www.asp.net/signalr

Cristian Darie ASP.NET: Beginning ASP.NET E-Commerce in C# From Novice to Professional [Text]/ Cristian Darie; Karli Watson; Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505 – ISBN-13 (electronic): 13: 978-1-4302-1073-3;

John Wiley ASP.NET: Professional ASP.NET MVC 4 [Text]/ JON GALLOWAY, PHIL HAACK, BRAD WILSON, K. SCOTT ALLEN, EILON LIPTON; John Wiley & Sons, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 – ISBN: 978-1-118-34846-8;

Singel Page Application with ASP.NET [Resursă electronică]. – Regim de acces:
https://msdn.microsoft.com/en-us/magazine/dn463786.aspx;

Frederik Dietz AngularJS: AngularJS Succinctly [Text]/ Frederik Dietz ; 2013 by Syncfusion Inc. 2501 Aerial Center Parkway Suite 200 Morrisville, NC 27560 USA All rights reserved.

Anexa A

Codul sursă al clasei CommuncationService.js

*****************************************************************************

'use strict';

var registrationModule = angular.module("registrationModule", ['uiSlider', 'ngRoute', 'ngResource', 'toaster', 'ngAnimate', "leaflet-directive"])

.config(function($routeProvider, $locationProvider) {

});

registrationModule.factory('comunicationService', function($rootScope) {

var comunicationService = {};

comunicationService.data = {};

comunicationService.event = {};

comunicationService.sendMessage = function(data) {

this.data = data;

$rootScope.$broadcast('handleNotification');

}

comunicationService.sendEvent = function (event) {

this.event = event;

$rootScope.$broadcast('handleEventHistoryNotification');

}

return comunicationService;

});

Anexa B

Codul sursă al clasei EventsHistoryController.js

'use strict';

registrationModule.controller("EventsHistoryController", function ($filter,customerRepository, $scope,distributorImageUrl, comunicationService, $rootScope) {

$scope.eventsHistory = [];

$scope.markers = [];

$scope.distributionScheduleAreas = [];

$scope.showEvents = true;

$scope.historyDistributorPopUp = {

img: '',

name: '',

phone: '',

position: {

x: 0,

y: 0

},

visible: false

};

$scope.historyLeafletPopUp = {

img: '',

createdDate: '',

distributorName: '',

visible: false

}

$scope.eventHistoryPanelClass = "animateEventsPanel";

customerRepository

.getDistributionDetails()

.then(function (distributionDetails) {

angular.forEach(distributionDetails.areas, function (distributionArea) {

$scope.distributionScheduleAreas.push(distributionArea);

});

angular.forEach(distributionDetails.distributors, function (distributor) {

pushDistributor(distributor);

});

angular.forEach(distributionDetails.leaflets, function (distributionLeafletEvidence) {

pushDistributionLeafletEvidence(distributionLeafletEvidence);

$scope.eventsHistory.push(distributionLeafletEvidence);

});

angular.forEach(distributionDetails.distributorsActions, function (distributorAction) {

pushDistributorActionInEventHistory(distributorAction);

});

$scope.eventsHistory.sort(function (a, b) {

return new Date(b.createdDate) – new Date(a.createdDate);

});

});

$rootScope.$on('handleEventHistoryNotification', function () {

$scope.eventsHistory.push(comunicationService.event);

$scope.eventsHistory.sort(function (a, b) {

return new Date(b.createdDate) – new Date(a.createdDate);

});

});

$scope.animateEventsPanel = function () {

if (!$scope.showEvents)

$scope.eventHistoryPanelClass = 'animateEventsPanel';

else

$scope.eventHistoryPanelClass = '';

$scope.showEvents = !$scope.showEvents;

}

$scope.distributorMouseOver = function (distributorName, event) {

var distributor = Array.firstOrDefault($scope.markers, function (d) { return d.name == distributorName; });

displayDistributorPopUp(distributor, event);

}

$scope.eventImageClick = function (imageUrl) {

var leaflet = Array.firstOrDefault($scope.markers, function (d) { return d.imageUrl == imageUrl; });

displayLeafletPopUp(leaflet);

}

var displayLeafletPopUp = function (leaflet) {

var leafletPopUp = $scope.historyLeafletPopUp;

leafletPopUp.img = leaflet.imageUrl;

leafletPopUp.distributorName = leaflet.distributorName;

leafletPopUp.createdDate = leaflet.createdDate;

leafletPopUp.visible = true;

}

var displayDistributorPopUp = function (distributor, event) {

var distributorPopUp = $scope.historyDistributorPopUp;

distributorPopUp.visible = true;

distributorPopUp.position.x = event.clientX + 10 + 'px';

distributorPopUp.position.y = event.clientY – 70 + 'px';

distributorPopUp.name = distributor.name;

distributorPopUp.phone = distributor.phone;

distributorPopUp.img = distributorImageUrl + "/?distributorID=" + distributor.entityID;

}

var pushDistributor = function (distributor) {

var distributorMarker = {

entityID: distributor.id,

name: distributor.name,

phone: distributor.mobilePhone,

type: "distributor",

lat: distributor.location.latitude,

lng: distributor.location.longitude,

status: distributor.status,

layer: distributor.areaID

};

$scope.markers.push(distributorMarker);

};

var pushDistributionLeafletEvidence = function (distribtuionLeafletEvidence) {

var marker = distribtuionLeafletEvidence;

marker.imageUrl = marker.postedImageUri;

marker.type = "leafletEvidence";

$scope.markers.push(marker);

};

var pushDistributorActionInEventHistory = function (distributorAction) {

var distributor = Array.firstOrDefault($scope.markers, function (d) { return d.name == distributorAction.distributorName; });

var area = Array.firstOrDefault($scope.distributionScheduleAreas, function (a) { return a.id == distributor.layer; });

distributorAction.areaName = area.name;

$scope.eventsHistory.push(distributorAction);

}

});