Sistem de gestionare a cererilor de despăgubire pentru o societate de [627802]

Sistem de gestionare a cererilor de despăgubire pentru o societate de
asigurări
Rareș-Neagu Florian
17 iunie 2017

Cuprins
1 T ehnologiile folosite 6
1.1 PHP 5.6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Laravel 5.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1 Directive Blade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.2 Laravel F orms / HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.3 Consola Artisan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.4 Eloquent ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.5 Migrări . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Baza de date – MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.1 Relații . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3.2 PhpMyAdmin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.4 GitHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.5 Certificat SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1 StartCom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.2 CloudFlare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6 jQuery & jQuery UI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7 Knockout.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.8 Mențiuni speciale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8.1 Google Analytics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.8.2 Găzduire partajată . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.8.3 PhpStorm IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8.4 Heroku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8.5 Amazon W eb Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.8.6 Composer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.8.7 Laravel Elixir și npm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.8.8 LaT eX și Sublime T ext . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2 O scurtă istorie a dezvoltării aplicației 19
2.1 Primul modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2 Problema datelor incomplete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3 Modulul de rapoarte și decizii . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Decuplarea deciziilor de vânzări . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4.1 Modificări în viitorul apropiat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 După planul inițial de dezvoltare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5.1 Introducerea datelor și rapoartele avansate . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.2 În continuare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3 Structura aplicației 24
3.1 Un exemplu de cerere . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Baza de date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Laravel MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 Models – Eloquent ORM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3.4 F uncții ajutătoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4 Excel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.1 Implementarea platformei de rapoarte Excel . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1

4 Manual de utilizare 39
4.1 Înregistrarea unei cereri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Secțiunea de mesaje din cadrul cererilor de despăgubire . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Interfața de administrare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3.1 Modulul de administrare a cererilor de despăgubire . . . . . . . . . . . . . . . . . . . . . . 45
4.3.2 Modulul introducerii datelor în sistem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.3 Sales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.4 Decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.5 Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.6 Modificări necesare asupra structurii bazei de date . . . . . . . . . . . . . . . . . . . . . . 60
2

Introducere
Condițiile preexistente
În momentul în care am interacționat prima oară cu F andu, doreau o redirectare simplă a paginii de internet
http://www.fandu.uk/claims [1] către
http://wsgp.co.uk/claims/ [2].
Proiectul era administrat pe server-ul companiei angajate să scrie codul. Pagina principală încânta utiliza-
torul cu o avertizare în engleză ce spunea că sistemul ales de gestionare a bazei de date va fi în curând scos
din limbajul de programare ales de ei. Nu aveau validări a datelor, nu scoteau rapoartele necesare. Sistemul de
gestiune a cererilor de despăgubire era centrat în jurul unor fișiere Excel, ținute de angajați și distribuite între
ei.
Astfel, F andu și-a dorit să poată să scoată rapoartele dintr-o aplicație. Fără să treacă cineva prin fiecare
daună înregistrată. Fără să copieze informațiile dintr-un mail trimis automat. Au dorit să automatizeze o mare
parte din munca asiduă a angajaților F andu. De a putea scoate oricând rapoartele necesare pe orice perioadă
de timp, fie ea o lună, un an, sau de la prima cerere de despăgubire.
Soluția a venit din partea mea. Dorind să mă afirm și să am experiență în domeniu, m-am oferit ca în
timpul liber să ajut F andu. Să scot problema umană din ecuația rapoartelor, să trimit automat mail și să ofer
o soluție completă, eficientă, construită de jos în sus pentru fiecare parte a dorințelor lor. Ei au fost sceptici
că pot, așa că de menționat ar fi că metoda „rudimentară” de a păstra datele în fișierele Excel a fost activă pe
perioada dezvoltării aplicației, pentru a se asigura exactitatea rapoartelor scoase de sistem cu cele „manuale” .
Și asta a ajutat enorm. Multe probleme mici au apărut în timpul dezvoltării, ce au fost reparate o dată ce au
fost comparate datele.
Servicii prestate clienților
Utilizatorii primesc în regulamentul de „Mobile Protect”, valabil online și la https://mediagalaxy.ro/
regulament-mobile-protect [3], în momentul achiziției unui telefon sau unei tablete, indicațiile de a se uita
lawww.fandu.uk/claims pentru cererile de despăgubire. Pot să trimită la adresa respectivă și documentele
relevante pentru a soluționa cererii de despăgubire.
Sunt rugați de a completa cât mai complet și a da cât de multe detalii posibile pentru soluționarea mai
rapidă a cererii.
Regulamentul mai avertizează repercursiunile legale posibile în cazul falsificării informațiilor (și automat
respingerea cererii). Important de menționat, pentru victimele furtului agravat, este necesitatea raportului
poliției în cazul furtului.
Societatea „F andu Holdings Ltd. ” cu sediul în Zinonos Kitieos nr. 8, Kato Lakatamia P .C. 2322, Nicosia,
Cyprus[ 1] este o societate ce se ocupă cu cererile de despăgubire pentru Altex și Media Galaxy[ 3].
Aceasta răspunde în numele lui „AmT rust International Underwriters Limited” .[ 3].
Detalii despre dezvoltarea aplicației
Dezvoltarea aplicației a început cu prima întâlnire între fondatorii companiei, cei ce aveau grijă de sistemul
de rapoarte în Excel și mine. Ne-am așezat la masă și astfel am început să discutăm despre cerințele aplicației.
Accentul s-a pus pe dorința de a scoate rapoarte mai ușor, fără a putea interveni eroarea umană. Să nu
se mai verifice manual câte asigurări s-au vândut într-o perioadă de timp determinată. Eliminarea nevoii de a
căuta în fiecare fișier trimis săptămânal de Altex / Media Galaxy .
Pe tot parcursul dezvoltării aplicației, am fost singurul ce s-a ocupat de aranjarea sistemului informatic,
migrarea spre o soluție de găzduire partajată, construirea bazei de date, relațiilor, securitatea datelor și inte-
racțiunii utilizatorului cu aplicația.
3

Figura 1: Pagina principală a https://fandu.info
Structura bazei de date a fost gândită prima oară a fi rigidă, a forța utilizatorul și persoanele ce se ocupă de
gestiunea lor să introducă datele corecte, a nu avea probleme ulterioare. Ideea a fost întâmpinată cu rezistență,
datorită libertății oferite de Excel, dar într-o scurtă perioadă de timp, rigiditatea a dat roade. Rapoartele erau
exacte și erorile ne-existente.
Interacțiunea cu utilizatorul de rând a fost gândită a fi cât mai rapidă. Atunci când intră pe pagina
aplicației, el poate deja să completeze cererea de despăgubire, așa cum se poate observa în poza 1. Utilizatorul
este îndrumat pentru a completa cât mai detaliat detaliile despre cererea de despăgubire și este avertizat atunci
când apare o eroare sau a uitat să completeze un câmp necesar.
Am ales să salvez toate datele utilizatorului în baza proprie de date, la o companie de încredere ce oferă
soluții de găzduire partajată https://xServers.ro [4]. Dar pozele și spațiul de stocare a pdf-urilor încărcate de
utilizatori sunt găzduite de Amazon W eb Services[ 5], pentru a beneficia de prețul redus și valabilitatea extinsă
a fișierelor pe „cloud” .
Revenind la soluția de găzduire partajată, am ales xServers.ro[ 4] pentru că aplicația se încadrează lejer în
oferta lor. Cel mai important atu este traficul de internet necontorizat și spațiu de stocare suficient.
Soluția de backup, oferită de cei ce găzduiesc aplicația, salvează baza de date în fiecare zi.
De asemenea, mă ocup personal pentru a asigura un backup săptămânal a bazei de date pe un volum
encriptat cu „ V eraCrypt”[ 6], un utilitar gratuit ce construiește un disc virtual securizat într-un simplu fișier.
Cele două soluții complementare asigură securitatea datelor și rezolvarea instantanee a problemelor bazei de
date, cheia aplicației.
Codul sursă este ținut într-un proiect „ git”, un sistem de gestionare și versionare a codului de programare,
încărcat pe GitHub, un aliat de încredere oricărui programator.
Despre aplicație
Pentru a putea reduce costurile aplicației, am optat pentru o metodă tradițională de găzduire partajată, ce
oferă PHP și o bază de date MySQL inclusă în pachet.
Chiar dacă experiența mea unde lucrez își spune cuvântul în alt limbaj de programare (C#), am descoperit
plictisindu-mă Laravel[ 7], o platformă modernă de a scrie cod PHP , inspirată din arhitectura sistemului „Ruby
on Rails” .
Înainte să interacționez cu persoanele de la F andu, aveam deja mai multe proiecte ușoare terminate. Știam
cât de important este să nu te avânți cu capul înainte, fără a ști un nou cadru în care să programezi, pentru că
rezultatul ar fi deplorabil.
Nu folosisem până acum într-un mediu de producție Laravel, dar eram încrezător că nu mi-ar oferi surprize
neplăcute. De asemenea, văzusem oportunitatea de a folosi cele mai ridicate standarde de programare pentru
PHP , și până la urmă am ales să merg el.
Astfel, am învățat cum este să gestionezi de unul singur dezvoltarea unei aplicații de la concept la problemele
de memorie când nu poți să scoți rapoarte cu peste 30000 de linii, cu baza de date de pe producție.
Alt avantaj este încercarea minimizării complexității ascunse[ 8], ce face codul mult mai ușor de întreținut și
permite dezvoltarea mai rapidă, fără a petrece mult timp înțelegând arhitectura sau codul scris anterior.
Sintaxa ușor de înțeles și ambiguitatea redusă fac din Laravel, în opinia mea, un bun provocator chiar și
pentru „ASP .NET MVC”[ 9], liderul pe piață în momentul actual. Ambele platforme oferă soluții de la modele,
4

la gestionarea bazei de date, la rularea migrațiilor, la salvarea stării și chiar și integrarea automată a unui sistem
de utilizatori.
Dar spre diferență de soluția Microsoft, toată platforma necesară construirii și distribuirii aplicației nu este
blocată pe sistemul de operare Windows (cu .NET Core situația se schimbă, dar în acest moment nu a fost
adoptată la scară largă), ci poate să funcționeze pe orice sistem de operare.
5

Capitolul 1
T ehnologiile folosite
1.1 PHP 5.6
Când a apărut internet-ul, toate paginile erau statice. Nu puteai să interacționezi cu conținutul paginii.
Dar apoi Netscape a revoluționat paginile, construind limbajul de programare LiveScript (redenumit ulterior
JavaScript). În puțini ani, Netscape a revoluționat și modul în care paginile sunt distribuite utilizatorilor prin
conceptul de JavaScript pentru aplicațiile ce serveau paginile. Astfel, s-a construit primul scenariu de cod folosit
de servere. [ 10]
În continuare, s-a definit „Common Gateway Interface” (CGI), ce oferă un protocol pentru serverele web de
a executa programe pentru a genera pagini de web dinamic atunci când este nevoie de o pagină de internet.
Serverul web permite administratorului să seteze ce URL-uri vor fi folosite de ce programe CGI prin setarea
unui folder cu scripturi. În loc să trimită fișierul respectiv, serverul HTTP apelează script-ul și trimite orice ar
fi afișat ca și rezultat pentru client. [ 11]
Un astfel de program a fost și invenția lui „Rasmus Lerdorf” . Și-a extins programele ce gestionau pagina
lui personală pentru a interacționa cu baze de date și formulare, dând numele implementării „Personal Home
Page/F orms Interpreter” (sau pe scurt, PHP/FI). Nu a avut o viziune clară asupra limbajului de programare,
a continuat să adauge ceea ce considera a fi următorul pas logic. [ 12]
Printre îmbunătățirile aduse limbajul se numără „superglobalele” (o metodă ușoară de a accesa parametrii
trimiși de formularele paginilor HTML) în versiunea 4.1, metode de gestiune a codului orientat pe obiecte,
o interfață standardizată pentru a accesa bazele de date. Ulterior, adăugându-se pe parcursul dezvoltării
limbajului suport pentru „namespace”-uri, generatoare, funcții anonime, extinderi, pe 28 August 2014, a fost
lansat PHP 5.6, ce va fi întreținut până pe 31 Decembrie 2018. [ 13]
1.2 Laravel 5.3
Laravel este o librărie gratuită de PHP . Pentru Laravel 5.3, minimul necesar librăriei este PHP 5.5.9 sau
mai nou. Librăria a fost concepută de „T aylor Otwell”, pentru a construi aplicații web bazate pe arhitectura
„Model-View-Controller” . Printre numeroasele avantaje de a folosi Laravel se află sistemul modular de pachete,
cu propriul său sistem de gestionare, moduri diferite de a accesa bazele de date relaționale, utilitare pentru
scrierea și menținerea aplicației și orientarea spre expresivitatea codului.[ 14]
Arhitectura „Model-View-Controller” se bazează pe cele trei componente inter-conectate slab ale unei apli-
cații: Modelul, Controller-ul, respectiv View-ul. Modelul este componenta centrală a șablonului, pentru că se
ocupă de datele, logica și regulile aplicației. Acest model este gestionat de Controller, ce acceptă datele de la
utilizator și le transformă în comenzi pentru model și/sau View. View-ul este orice metodă de vizualizare a
informației unui Model.[ 15]
A vantajele arhitecturii, mulțumită separării conceptuale, ajută dezvoltarea simultană și ușurința modifică-
rilor. Astfel, mai multe persoane pot lucra simultan la o parte a aplicației. Dar din păcate, trebuie studiată în
detaliu, pentru că nu este ușoară de folosit pragmatic.
1.2.1 Directive Blade
Un mare avantaj al librăriei este un simplu, dar foarte puternic și eficient sistem de șablonare — Blade. Spre
deosebire de alte sisteme de șablon, Blade nu inhibă dezvoltatorul a folosi cod PHP în View-uri. De fapt, toate
View-urile Blade sunt traduse în cod simplu PHP și salvate până ce sunt modificate. Astfel reușește să adauge
aproape zero logică în plus aplicației.
Pentru a afișa ceva pe ecran folosind PHP în mijlocul codului HTML, ar trebui să scrii:
6

<?= $variabila ?>
Dar asta te face vulnerabil la „XSS” .
XSS (Cross Side Scripting) este o vulnerabilitate a securității unei aplicații, des întâlnită în aplicațiile web,
ce permite adăugarea oricărui cod, fie el malițios sau inocent, paginilor vizualizate de clienții normali.
Astfel, pentru a preveni exploatarea datelor trimise de la Controller, pentru a afișa valorile variabilelor
trimise, directivele Blade indică folosirea sintagmei:
{{$variabila}}
Desigur, nu ești limitat la doar nume de variabile, ci la orice s-ar putea considera parametrul unei funcții,
deoarece sunt trimise prin metoda
htmlspecialchars a PHP-ului.
Printre cele mai folositoare beneficii folosind Blade se află și construirea fișierelor ce definesc structura
HTML-ului aplicației. Nu se definește practic o pagină principală, doar se specifică pentru paginile existente
deja a se folosi structura găsită în pagina specificată prin comanda:
@extends('layouts.app')
unde în acest caz în folderul „layouts” găsim fișierul „app.blade.php” .
Pentru a introduce conținutul paginii ce extinde șablonul, Blade folosește secțiuni. Declarate în pagina
principală, acestea indică locul unde se așteaptă conținut, putând fi denumite după nevoile șablonului. De
asemenea, în cazul definirii unei secțiuni, se poate folosi și o valoare implicită. Cel mai des e folosit un șablon
în definirea titlului, cu o valoare implicită a numelui proiectului. În cazul acestui proiect, am folosit ca sufix
numele configurat în fișierul mediu, lăsând la dispoziția fiecărei pagini a seta titlul.
F olosind secțiuni, am descoperit o problemă la refolosirea unor componente vizuale. Blade adaugă precum
PHP conținutul fișierului ce trebuie să existe unde ai scris instrucțiunea respectivă folosind comanda:
@include('decisions.includes.search')
// ce adaugă fișierul
// resources/views/decisions/includes/search.blade.php
Continuând șirul dezvoltării, descopăr o altă problemă la introducerea a mai multor segmente de cod Ja-
vaScript în aplicație, din fișiere Blade separate. Pentru a rezolva și această problemă, Blade se folosește de:
@push('scripts')
pentru a adăuga informații într-o stivă, ce va fi afișată în pagina ce definește structura HTML prin simpla
comandă:
@stack('scripts')
Printre marile îmbunătățiri aduse de Blade, folosite în acest proiect, se numără și directivele. Acestea sunt
propriile comenzi, definite de programator, ce extind limbajul. Sunt traduse în simple instrucțiuni de cod PHP .
Am scris astfel propria directivă de a construi automat codul necesar afișării, folosind HTML și librăria vizuală
„Bootstrap”, a unui câmp dintr-un formular, cu nume, tip și validare proprie:
@input(['eveniment_strada', ['Strada', false]])
// unde 'eveniment_strada' – id-ul câmpului.
// unde 'Strada' – denumirea câmpului.
// unde 'false' – necesitatea completării câmpului.
1.2.2 Laravel F orms / HTML
O mare parte a oricărei aplicații web este interacțiunea cu clientul. Pentru asta, există formulare ce sunt
trimise către calculatorul aplicației. O fostă librărie inclusă în Laravel, dar acum extinsă și desprinsă este librăria
ajutătoare pentru formulare și HTML. Este întreținută de „Laravel Collective”, o comunitate ce se ocupă de
menținerea componentelor scoase din Laravel de „T aylor Otwell” . Astfel, el are prilejul de a se concentra pe
munca sa (Laravel) și comunitatea susține componentele îndrăgite de programatori în viață, independent.[ 16]
Un astfel de proiect este „F orms & Html” [ 17], ce simplifică codul ce trebuie scris de un programator Laravel.
În loc de a scris de fiecare dată ce câmp are ca referință ce obiect din model, se definește în schimb în momentul
construirii formularului modelul de referință. Când se construiește un câmp, trebuie doar să fie bine specificat
identificatorul câmpului, iar când va fi trimis către client, va fi completat automat cu valoarea din model. De
asemenea, un al treilea parametru lasă loc programatorului să completeze celelalte atribute ale nodului HTML
printr-un vector unde cheia reprezintă numele atributului și valoarea reprezintă conținutul.
7

Nu doar metode ajutătoare, „F orms & Html” acceptă și componente specializate, definite de programator,
ca șabloane Blade. Prin definirea lor într-un folder special, acestea pot fi folosite precum cele deja definite,
pentru a ușura clasele și atributele necesare pentru dezvoltatorii ce folosesc „Bootstrap” . Cum acest proiect se
folosește de Bootstrap și „F orms & Html”, vă pot da un exemplu de două componente des folosite în aplicație:
{{Html::panel_begin('Delete Assurance', 'in')}}
// aici scriu cod…
{{Html::panel_end()}}
// unde 'Delete Assurance' – numele panoului
// unde 'in' – starea panoului: de a fi deja deschis
1.2.3 Consola Artisan
Degeaba poți avea o soluție elegantă a unei probleme, dacă pentru a crea un Controller nou ai nevoie de a
scrie o grămadă de linii de cod. Este adevărat, poți să scurtezi mult din timpul prețios folosind șabloanele unui
mediu inteligent de programare. Dar poate uiți dacă trebuie să modifici în mai multe locuri.
Aici intervine consola „Artisan”, o interfață prietenoasă pentru programatorii obișnuiți cu liniile de comandă
din „Ruby on Rails” . Ajută programatorul la a construi mai rapid aplicația, bazată pe arhitectura „Symfony” .
Printre cele mai des folosite opțiuni se numără:
• Construirea rapidă a mai multor tipuri de clase (Migrare, Controller, Model, Request, Event).
• Gestionarea migrărilor bazei de date.
• Curățarea fișierelor precompilate sau aflarea rutelor definite.
• Generarea codului necesar unui sistem rudimentar de înregistrare, intrare și resetare parolă, cât și filtrarea
accesului utilizatorului în aplicație.
De menționat ar mai fi extensibilitatea consolei prin pachetele salvate, care pot adăuga funcții vitale pentru
mediul de dezvoltare ales. Aici mă refer la „Laravel PhpStorm IDE Helper” ( barryvdh/laravel-ide-helper ),
despre care voi discuta în subcapitolul despre PhpStorm.
1.2.4 Eloquent ORM
Un ORM („Object-relational mapping”) este o tehnică de programare care traduce datele incompatibile
(tabelele unei baze de date) în obiecte PHP , care pot fi folosite în cadrul aplicației. Spre diferență de tehnicile
tradiționale de a transforma un obiect dintr-un limbaj orientat pe obiecte într-o linie dintr-un tabel al unei baze
de date relaționale, ORM-ul adesea reduce numărul liniilor de cod scrise.[ 18]
F olosit în conjuncție cu un ORM, șablonul de linie activă („active record pattern”) este folositor pentru
a salva în memorie datele obiectului dintr-o bază de date relațională. Interfața obiectului conceput care se
conformează șablonului va avea metode de a adăuga, modifica, șterge linii din baza de date, dar și câmpuri care
corespund mai mult sau mai puțin coloanelor tabelei care stă la baza obiectului. Acest șablon arhitectural a
fost denumit de „Martin F owler” în 2003. [ 19]
Eloquent ORM, inclus cu Laravel, oferă programatorului o elegantă implementare a șablonului „Active
Record” . Fiecare tabel are un Model corespunzător, ce este folosit pentru a interacționa — a adăuga sau
modifica — baza de date.
Laravel diferă de alte librării și se aseamănă cu ASP .NET cu puternica sa preferință a convențiilor împotriva
configurației. Este recomandat deci de a denumi tabelele cu litere mici cu sublinie (e.g: „test_cases” ), în
cazul în care nu se specifică explicit tabelul folosit pentru model. Numele modelului ar trebui să urmeze ghidul
de denumire a claselor conform standardului PHP PSR-1 [ 20] (i.e.:„TestCase” ).
1.2.5 Migrări
Pentru a simplifica munca programatorilor, Laravel a ales să folosească un sistem de migrare a bazelor de
date. Asigura la pornirea aplicației că versiunea bazei de date corespunde ultimelor modificări aduse codului
prin tabela numită „migrations” . A vantajul gestionării incrementale și reversibile a schimbărilor a schemei
unei baze de date relaționare asigură pierderi minime a datelor de pe calculatorul de producție. În avantajul
programatorului mai există și ușurința de a reveni la varianta originală a bazei de date, când se dezvoltă o
migrare nouă, în cazul în care aceasta are lipsuri sau se încearcă altă abordare.
Pentru a construi o migrare, se apelează comanda Artisan:
php artisan make:migration create_users_table –create=users
# sau, o variantă ce construiește și migrarea și modelul asociat
php artisan make:model –migration User
8

Comanda construiește un nou fișier în folder-ul special pentru migrări și scrie în interiorul lui o clasă nouă
CreateUsersTable .
Se observă că această nouă clasă respectă principiul gestionării incrementale și reversibile a schimbărilor
schemei bazei de date pentru că are două metode denumite „up”, „down”, pentru când se va aplica, respectiv
scoate migrarea respectivă.
Clasa ce se ocupă de construirea tabelului are majoritatea funcțiilor ajutătoare pentru a construi orice schemă
dorită de programator. Păstrează în spatele sintaxei ușor de folosit abilitatea de a se putea aplica asupra oricărui
sistem relațional de baze de date. A vantajul programatorul este că nu trebuie să se mai complice cu duplicarea
codului și testarea pe mai multe baze de date a migrării. T otul este asigurat de Laravel.
1.3 Baza de date – MySQL
Baza de date relațională cu sursa sa deschisă MySQL este un sistem de gestionare a unei baze de date rela-
ționale. Numele provine de la numele fiicei fondatorului „Michael Widenius”[ 21] și abrevierii SQL („Structured
Query Language”). Dezvoltarea sa, cu codul sub termenii licenței GNU GPL, a fost sponsorizată și proprietatea
companiei suedeze „MySQL AB” . În momentul actual, compania nu mai există, fiind cumpărată de corporația
Oracle.
Această componentă vitală face parte din platforma cu codul deschis pentru dezvoltarea aplicațiilor web
LAMP:
• Linux
• Apache
• MySQL
• PHP/Perl/Python
Multe aplicații, de la cele pentru amatorii paginilor personale, a buletinelor de știri sau a canalelor de discuție,
se bazează pe MySQL. Printre marile companii ce folosesc MySQL, se numără:
• Google
• F acebook
• T witter
• Flickr
• Y ouT ube
1.3.1 Relații
În Octombrie 2005, corporația Oracle a achiziționat „Innobase OY”, o companie finlandeză ce a dezvoltat
InnoDB. [ 22] Sistemul dezvoltat de salvare permite bazei de date MySQL a oferi tranzacții și „chei străine” .
După achiziție, Oracle a confirmat prelungirea contractului ce permite folosirea lui de către „MySQL AB” .
Cheile străine, în contextul bazelor de date relaționale, se referă la un câmp sau mai multe ce identifică unic
o coloană sau o linie a unui tabel de alt tabel[ 23]. De asemenea, un tabel poate să aibă una sau mai multe
referințe, ce se pot referi la alte tabele părinte, dar chiar și la el însuși (numindu-se „cheie străină recursivă”).
Pentru a păstra legăturile între tabele, atunci când se modifică date sau se șterg, se oferă următoarele opțiuni:
•CASCADE – se șterge și referința.
•RESTRICT – nu se poate șterge linia atâta timp cât există o referință spre el.
•NO ACTION – asemănătoare RESTRICT , ce se verifică în schimb la finalizarea tranzacției.
•SET NULL – referința se va transforma în NULL .
•SET DEFAULT – referința se va transforma în variabila cu care este inițializat câmpul în mod implicit.
9

1.3.2 PhpMyAdmin
PhpMyAdmin este un sistem gratuit și cu codul liber de administrare a bazelor de date MySQL și MariaDB.
Ca o aplicație portabilă scrisă majoritar în PHP , a devenit una dintre cele mai populare sisteme de administrare,
mai ales pentru serviciile de găzduire, precum xServers și nu numai.
A început dezvoltarea „T obias Ratschiller”, un consultant IT și mai târziu fondator a companiei Maguma, a
unei interfețe bazate pe PHP a bazei de date MySQL în 1998. În anul 2000, din cauza lipsei de timp, a renunțat
la proiect, dar până în acel moment, devenise deja una dintre cele mai populare aplicații administrative. A vând
o comunitate mare, un grup de trei dezvoltatori, pentru a coordona mai bine numărul care tot creștea de
modificări, înregistrează la SourceF orce „The phpMyAdmin Project” și preiau dezvoltarea în 2001. [ 24]
În continuare, principalul website a migrat spre un sistem distribuit și au mutat ulterior urmărirea proble-
melor pe GitHub. Înainte de versiunea 4, ce folosește apeluri asincrone pentru a optimiza folosința, se foloseau
cadre HTML.
În afară de a gestiona bazele de date și a oferi o interfață web, mai poate să:
• importe datele din CSV și SQL.
• să salveze într-o multitudine de formate, printre care și CSV, SQL, XML, Excel.
• caute orice date dintr-un context global sau local.
• transforme orice „blob” într-un format predefinit.
• ofere grafice actualizate în timp real pentru monitorizarea:
– conexiunilor
– memoriei
– consumului procesorului
1.4 GitHub
T rebuie să ne asigurăm că păstrăm undeva codul sursă al aplicației, pentru a fi siguri că nu se vor corupe
datele. De asta am ales să folosesc un program de gestionare a codului.[ 25]
Sistemul de gestiune a codului se ocupă cu organizarea și aflarea modificărilor fișierelor cu cod, construind
revizii pentru fiecare modificare în parte, ușoare de identificat. De asemenea, comunică cu un server ce păstrează
codul sursă și lasă programatorii să aibă o variantă ce funcționează pe mașina locală.
F uncționând pe un modelul tranzacțional, ajută enorm lucrului în echipă pentru că păstrează pentru cele
mai des folosite operații (salvare, vizualizare istoric, revenind la modificări anterioare) sunt optimizare și deci
rapide. Modelul tranzacțional asigură și că nu vor apărea probleme la modificări concurente de două sau mai
multe persoane asupra aceluiași fișier.
Un astfel de sistem de gestiune a versiunii (VCS), pentru a urmări schimbările fișierelor și coordonarea
lucrului în echipă, este „Git” .[ 26] A fost conceput de „Linus T orvalds” în 2005 împreună cu alți dezvoltatori ai
kernel-ului LInux pentru dezvoltarea kernel-ului. Se concentrează asupra vitezei, integrității datelor și susținerea
unui mod de lucru distribuit și neliniar. Astfel, fiecare folder „Git” pe fiecare calculator conține istoricul complet
al proiectului, independent de accesul la rețea. Este cel mai folosit sistem, mulțumită multiplelor garanții
împotriva coruperii datelor, iar conform unui studiu făcut în 2015, 69.3% dezvoltatori folosesc activ „Git” .
Pentru că un sistem de gestiune a versiunii se folosește de un server, am ales varianta online și bazată pe
web „GitHub”, ce folosește „Git” și adaugă și funcționalitate pentru lucrul în echipă, precum [ 27] :
• „bug tracking” – gestionarea problemelor în cod.
• „feature requests” – gestionarea propunerilor pentru funcționalitate nouă.
• „task management” – cine, ce, când are de modificat în cadrul proiectului.
• „wiki” – un loc comun despre tot ce ține de documentația proiectului.
GitHub valorifică securitatea informațiilor confidențiale și asigură de furtul intelectual sau de majoritatea
problemelor de natură fizică, distrugerea laptop-ului, spre exemplu.
F andu folosește de la prima variantă a codului de programare „ git” și „GitHub”, în modul privat. Sunt
singurul ce are acces la codul sursă pentru că sunt și singurul dezvoltator. Pentru a fi extra precaut, tot codul
este salvat pe un disc virtual encriptat cu V eraCrypt. Pentru a fi pus pe serverul de producție, se folosește doar
FTP encriptat. La fel și pentru mediul de testare. Consider că astfel șansa de furt intelectual este infimă.
10

1.5 Certificat SSL
Certificatele SSL sunt fișiere mici ce leagă digital o cheie criptografică de detaliile unei organizații. Atunci
când este instalat pe un server web, activează protocolul HTTPS și permite legăturilor encriptate de la server
la clienți. De obicei, SSL este folosit pentru a securiza tranzacțiile cu cărțile de credit și transferul de date sau
de înregistrări. Dar mai nou, este normal să fie folosit la orice, de la media la paginile personale.[ 28]
Certificatele SSL leagă împreună:
• Un nume de domeniu sau server.
• O identitate organizațională (i.e: numele companiei) și locația sa.
O autoritate de certificate este o entitate ce distribuie certificate digitale SSL. Acesta acreditează deținătorul
asupra unei chei publice cu numele său. Astfel se asigură prin semnături digitale anumite presupuneri despre
cheia privată. Autoritatea de certificate are aici rolul de terță de încredere, pentru deținător și nu numai.
O astfel de autoritate de certificate este StartSSL. StartSSL face partea din compania StartCom, fondată de
„Eddu Nigg” în Israel. Aceasta oferă gratuit certificate SSL clasa 1, ce funcționează pentru un singur domeniu
al unui website.
Mai nou se promovează „Let’s Encrypt”, o altă autoritate de certificate, ce oferă gratuit certificate HTTPS
(SSL/TLS), pentru a opri terțele din a vedea traficul de la client la server. Dar din păcate, pentru sistemele
găzduite la comun, în acest caz xServers, această opțiune nu este valabilă și nici preferată. Pentru că oricine
poate să semneze un certificat, se pune problema legării acelui certificat la identitatea organizațională.
În concluzie, am preferat să mergem cu StartCom.
1.5.1 StartCom
La începutul dezvoltării aplicației, o mare necesitate era o puternică securitate a paginilor. Pentru că mai
folosisem înainte StartCom și aveam o oarecare încredere în ei, am ales pentru a activa rapid modulul HTTPS
pe gazda de producție un certificat de la ei.
StartCom a fost achiziționat în secret de „ W oSign Limited” (Shenzen, China), o altă autoritate de certificate.
Din cauza numeroaselor probleme cu ei, Mozilla, Apple și Google au anunțat retragerea încrederii în certificatele
după 21 octombrie 2016 (Mozilla, Google), 30 septembrie 2016 (Apple). În continuare, Google Chrome 57 va
avea încredere în certificatele website-urilor în topul Alexa 1M, iar Chrome 58 va avea încredere în cele în topul
500000. [ 29]
Din păcate, acest proiect de gestionare a cererilor de despăgubiri a fost prins la mijloc, pentru că aveam o
oarecare încredere în această autoritate de certificate. Apăruse astfel problema că după o perioadă de timp nu
o să mai funcționeze sistemul HTTPS.
1.5.2 CloudFlare
Din fericire, știam o soluție temporară, ce după multe dezbateri cu personalul de la F andu, a intrat în
funcțiune cât de curând posibil.
CloudFlare este o companie în Statele Unite ale Americii. Oferă un sistem de livrare al conținutului și un
sistem distribuit de nume de domeniu. Sistemul distribuit de nume de domeniu stă între serverul administra-
torului aplicației și aplicația mobilă a clientului. Astfel, nu numai că poate să prevină orice atac malițios, dar
poate să și optimizeze paginile trimise.
Un alt mare avantaj pentru CloudFlare, introdus recent, este un sistem de gestiune a certificatelor SSL.
Astfel, am putut folosi certificatul ce nu mai putea fi folosit pentru a face o legătură „F ull SSL”:
• Se asigură legătura client – CloudFlare prin certificatul lor. Apare iconița ce indică transmisia encriptată
a datelor către server (lacătul verde).
• Se asigură legătura CloudFlare – server prin certificatul deja existent pe F andu. Nu se trimite nicio
informație nesecurizată prin Internet.
De asemenea, mai oferă și redirectarea automată a website-ului către domeniul securizat, dar deja se ocupă
de asta Laravel.
Principalul motiv pentru care CloudFlare este în momentul actual indispensabil pentru F andu este protec-
ția de atacurile DDoS. Un atac DDoS („Distributed Denial of Service”) poate să aducă în genunchi întreaga
arhitectură. Cum CloudFlare oferă o opțiune de „sunt sub asediu”, ce poate fi activată cât mai repede, poate
să blocheze orice om frustrat.
11

Mulțumită juxtapoziției între server și client, se mai poate optimiza orice resursă trimisă. Se poate renunța
la spațiile inutile din stilul sau codul interactiv JavaScript. Dar nu este nevoie de optimizarea la nivel de
CloudFlare, deoarece se face la nivelul dezvoltării aplicației de Laravel.
Mulțumită „Laravel Mix”, se optimizează, concatenează și minimizează tot codul și stilul afișat utilizatorului.
Cu cât mai puține dependențe externe, cu atât mai bine pentru securitatea aplicației.
1.6 jQuery & jQuery UI
Orice programator ce dorește o pagină interactivă o să folosească o dată măcar în viața lui cu jQuery . jQuery
este o librărie de JavaScript ce ajută la: [ 30]
• Navigarea DOM-ului („Document Object Model” — toate componentele ce formează pagina)
• Găsirea ușoară a elementelor relative, precum a părinților sau a unor copii a unor noduri, folosind sintaxa
similară CSS („Cascading Style Sheet”).
• Construirea ușoară a animațiilor și gestionarea ușoară a anunțurilor rezultate (și nu numai)
• Ușoara integrare a elementelor preluate dinamice din altă parte, folosind metodologia asincronă de a
trimite și recepționa informații.
De asemenea, mulțumită arhitecturii, jQuery permite dezvoltatorilor a construi „plug-in”-uri, pentru a
extinde funcționalitatea. O astfel de librărie ce extinde jQuery este „ jQuery UI” [ 31].
jQuery UI este o colecție de elemente vizuale, animate, testate, ce permit dezvoltatorilor un timp mai scurt
de a pune produsul pe piață. Oferă efecte profesionale și „widget”-uri (elemente vizuale predefinite), precum
un modul de a putea selecta data dintr-un calendar vizual.
Pentru sistemul de gestiune a cererilor de despăgubire, am folosit „ jQuery” și „ jQuery UI” pentru majoritatea
interacțiunilor specifice paginilor. Am și extins platforma, prin trei metode, pentru a trimite și primi mai ușor
informațiile de la Laravel.
Spre exemplu, logica de a încărca vânzările săptămânale se bazează pe această platformă. Utilizatorul o
dată ce adaugă fișierul dorit de a fi încărcat în sistem, nu navighează de la pagina curentă, ci este întâmpinat
cu o bară a progresului. În acest moment, fiecare fișier este încărcat separat și preluat de sistem. Se salvează
rezultatul pentru fiecare fișier și la final se combină toate rezultate într-o interfață ce ajută persoana ce folosește
sistemul de a înțelege ce a funcționat și ce nu.
Mai este folosit jQuery exhaustiv pentru a construi legătura dintre o vânzare și o cerere de despăgubire.
Sistemul astfel refolosește codul deja existent prin intermediul cadrelor HTML („iframe”) pentru a selecta
vânzarea. La final, reies mai multe câmpuri obligatorii, ce se completează automat dacă a fost ales o cerere de
vânzare. Din cauza problemelor rapoartelor de vânzare, această abordare oferea cea mai mare flexibilitate și un
număr minim de linii de cod scrise.
O altă bună integrare cu „ jQuery” vine din partea librăriei „Bootstrap V alidator”, un „plug-in” simplu de
folosit pentru a adăuga elemente de validare pentru formulare. [ 32] Mulțumită directivelor Blade, am integrat
ușor construirea unor câmpuri cu validare necesară, pentru a ajuta utilizatorul să completeze cât mai corect
formularul de despăgubire.
Am reușit astfel de a scurta timpul de dezvoltare și de a asigura o interfață unificată în modul de abordare
a înfățișării aplicației, mulțumită acestor trei platforme.
1.7 Knockout.js
Knockout este o implementare de sine stătătoare a structurii șablon de „Model-View-ViewModel” . Structura
se referă la o separare clară a datelor primite din exterior, a componentele și a datelor ce vor fi folosite pentru a
fi afișate, dar și la prezența unui cod specializat de a gestiona relațiile dintre cele două (componente și interfață).
[33]
A fost concepută de „Steve Sanderson”, un angajat Microsoft, drept un proiect cu codul distribuit gra-
tuit. [ 34] Mulțumită arhitecturii, Knockout simplifică relațiile complexe dintre componentele vizuale, ce ajută
aplicația de a fi mult mai echilibrată și rapidă.
Am folosit Knockout pentru a rezolva problema codului duplicat. În momentul actual, este folosit pentru
a gestiona pozele încărcate de utilizator și de a salva extern baza de date. Am ales tocmai în această arie cu
probleme majore, pentru că dacă o componentă nu ar fi mers, tot sistemul ar fi fost inutilizabil. Dar mulțumită
codului modular și a folosirii șabloanelor ce repetă același element cu alte modele legate în spate, Knockout
asigură funcționalitatea identică pentru toate modulele folosite.
Sistemul de gestiune a pozelor este împărțit în cele patru categorii:
12

1. F acturi.
2. Pozele cu produsul avariat.
3. F oile cu termenii și condiții.
4. Raportul poliției, în caz de nevoie.
Pentru fiecare element, se construiește o funcție nouă, pentru că JavaScript nu are clase. F uncția respectivă
gestionează identic modelul și vizualizarea acestuia prin păstrarea detașată de celelalte modele a datelor proprii.
Pentru a putea fi încărcate asincron, câte o poză pe rând spre soluția distribuită de stocare a datelor,
combin Knockout.JS cu jQuery . Astfel, datele sunt primite de la server, în format JSON, folosind o cale
specială, determinată la momentul construirii rutelor.
Knockout fiind o librărie de sine stătătoare, nu oferă o legătură strânsă între datele primite de la server și
reprezentarea internă a structurii, dar permite extensibilitatea cu orice alt limbaj, pentru că se folosește doar
de spațiul de nume („namespace”) ko . Dar mulțumită librăriei ajutătoare jQuery și a metodelor scrise de mine,
asigur o performanță și un număr redus de probleme ce pot apărea, pentru orice sistem al oricărui client, ce
poate vizita website-ul.
Un alt exemplu pentru aplicație este metoda de a salva baza de date. Primește de la server atunci când se
încarcă o listă cu toate tabelele bazei de date. Nu am specificat clar ce tabele sunt folosite, pentru a asigura
independența codului de structura bazei. În cazul în care apare o modificare, algoritmul va funcționa identic,
incluzând și noul tabel.
După ce primește de la server o listă cu toate tabelele, atunci când utilizatorul dorește să scoată toate datele
din sistem, pornește un contor. Pentru fiecare tabel în ordine, se face o cerere sistemului de a salva tabelul
respectiv într-o locație temporară. La final, se face o cerere separată, cu toate numele fișierelor rezultante,
pentru a concatena și trimite arhiva rezultantă utilizatorului sistemului.
Este accesibilă pentru oricine are nevoie de ea, atâta timp cât este un utilizator înregistrat, deci un membru
al echipei F andu. Nu strică să ai o variantă actualizată înainte de a importa date în aplicație, decât o dată pe
săptămână.
1.8 Mențiuni speciale
Fără părinți nu ajungeai cea mai bună variantă a ta. Eu n-aș fi putut să obțin tot ceea ce mi-am propus, în
timpul alocat, dacă n-ar fi existat aceste utilitare.
Așa cum pentru Laravel există consola Artisan, pentru gestionarea proiectului am folosit PhpStorm, un
mediu de dezvoltare integrat oferit de cei de la JetBrains.
Pentru a gestiona cunoștințele dobândite despre acest proiect în particular, mai ales ce pași trebuiesc res-
pectați în momentul în care încarc pe server-ul partajat ultima variantă a codului, fără să uit ceva și ulterior
codul pentru a face asta automat, am folosit o tablă Kanban.
Pentru a testa, am folosit Heroku, iar pentru a asigura salvarea eficientă a datelor am folosit A WS („Amazon
W eb Services”).
Pentru a include diverse mici proiecte, scrise de alți oameni puși în aceeași situație, am folosit Composer
împreună cu npm.
Iar pentru lucrarea de licență am folosit Sublime T ext 3 și L ATEX.
1.8.1 Google Analytics
Pentru a înțelege traficul venind, am ales să folosesc analizatorul gratuit (cu elemente premium) oferit de
Google. Oferă o sumedenie de detalii despre cum interacționează utilizatorul cu aplicația, de la cât timp petrece
un client web pe o anumită pagină, la cele mai des folosite butoane sau cele mai des folosite drumuri (legături
între mai multe pagini). [ 35] De asemenea, poți vedea ce a declanșat o eroare, ceea ce pentru un dezvoltator
ajută la identificarea și rezolvarea problemelor din momentul în care apar, nu după ce primești un apel furios
de la unul dintre fondatorii companiei.
Am descoperit, urmărind traficul pentru o săptămână, că punctul sensibil și cel mai des folosit era în
momentul în care se căuta o cerere de despăgubire. De cele mai multe ori, se știa deja numărul cererii, trebuia
doar să se acceseze panoul de căutare și să se introducă numărul în căsuță.
Astfel am realizat o mică modificare a panoului de navigare principal. Se regăsește mulțumită structurii
Laravel de organizare a unei aplicații, pe fiecare pagină. Modificarea constă în includerea unui câmp completabil
rapid. După ce s-a completat și utilizatorul a validat codul, se apelează aceeași funcție de căutare în spate,
precum accesare panoului de căutarea și introducerea sa în căsuță.
S-a mai observat durata lungă petrecută de clienți în momentul introducerii datelor cererii de despăgubire.
Din fericire, Laravel a fost conceput cu un sistem avansat de „uitare” a sesiunii, pentru a preveni abuzurile.
13

Dar acesta interfera cu durata lungă în care clienții își completau probabil informațiile și apărea des o eroare a
expirării sesiunii. Am reușit să previn această problemă apelând constant, prin jQuery , un punct al aplicației
ce avea singurul rol de a actualiza sesiunea pentru Laravel, declarând-o activă. Utilizator putea în final să stea
liniștit și să completeze toate datele, indiferent de cât i-ar fi luat.
1.8.2 Găzduire partajată
Găzduirea partajată se folosește pentru a pune un web server conectat la internet valabil pentru mai multe
persoane. Partajându-se mai multor clienți, se amortizează costul îngrijirii și astfel prețurile sunt reduse.
Am ales pentru F andu soluția oferită de xServers[ 4] pentru că nu era doar convenabilă și aveam încredere în
ei, pentru că mai găzduisem înainte propria mea pagină, ci pentru certificatele ce asigură calitatea și securitatea.
Aplicația se mișcă rapid, totul fiind salvat pe servere virtuale cu SSD-uri („Solid State Drive”).
Un mare avantaj, dar în același timp și dezavantaj este oprirea comenzii de interpretare și executare a codului
PHP ,eval . Din păcate, este problematic pentru consola Artisan, pentru că nu poate să aplice în momentul
actualizării bazei de date tot codul de migrare.
Soluția, la care s-a ajuns drept compromis în urma dezbaterilor cu departamentul tehnic, ce migrează codul
și baza de date a server-ului, este:
1. Se salvează toate datele existente, folosind utilitarul oferit de xServers.
2. Se introduce un fișier nou în directorul aplicației la:
storage/framework/down
Se închide astfel accesul la server cât timp se migrează baza de date și conținutul aplicației în sine.
3. Se află codul necesar migrării bazei de date prin comanda:
php artisan migrate –pretend -vvv
Ce reiese va fi cod SQL ce va fi copiat cu ușurință în phpMyAdmin-ul de pe server.
4. După ce s-a migrat cu succes baza de date, se copiază următoarele foldere:
•app – tot codul important al aplicației.
•bootstrap – sistemul de încărcare a platformei Laravel.
•config – setările implicite Laravel, în lipsa valorilor în fișierul mediului curent ( .env ).
•database – migrările bazei de date
•public – pentru că folosim „Laravel Elixir”, ce se ocupă de gestiunea variantelor codului JavaScript
și CSS, se vor copia și în calea publică public_html , pentru că acestea vor fi servite clienților și
trebuie să poată să fie accesibile.
•resources – directivele Blade, codul JavaScript și SASS.
•routes – rutele ce determină Controller-ul apelat.
•storage – doar structura, pentru că va conține fișierele temporare traduse din Blade în PHP .
•tests – se poate sări, pentru că nu afectează rezultatul final.
•vendor – dacă s-a modificat composer.json , adăugând sau modificând sau ștergând pachete.
5. Se va șterge fișierul nou creat:
storage/framework/down
și astfel migrația va fi completă.
În cazul unor migrări minore, ce nu implică baza de date, se pot suprascrie direct fișierele modificate în
cadrul aplicației. PhpStorm ajută aici prin opțiunea de a încărca prin FTP (encriptat) fișierele modificate.
Observație: Se copiază directorul public de două ori, când se fac modificări la stil sau la codul JavaScript:
o dată în cadrul directorului ce conține întregul proiect Laravel și o dată în directorul public_html .
„Laravel Elixir” funcționează bazându-se pe un fișier JSON, ce spune ce versiune de stil și cod să folosească,
aflat la:
/public/build/rev-manifest.json
Această cale nu este valabilă clienților, pentru că aplicația nu se află în directorul public. S-au făcut deci
mici modificări asupra fișierului index.php , aflat tot în directorul public, pentru a arăta calea corectă.
T rebuie să se copieze, în concluzie, codul și stilul și în acest director.
14

1.8.3 PhpStorm IDE
Chiar dacă Laravel a fost gândit cu cât mai puține referințe, cu cât mai mult cod ajutător pentru dezvoltator
și o grămadă de resurse valabile pe diverse site-uri, nu se poate compara cu un mediu de dezvoltare avansat, ce
se ocupă de fișierele dependente, regulile de scriere și formatare a codului.
PhpStorm este un mediu de dezvoltare comercial, oferit de JetBrains. Suportă completarea avansată a
codului PHP 5.6 (și mai nou 7.0), dar și analiza sintactică, prevenirea erorilor. Suportă oficial și sistemul
relațional de bază de date MySQL. Chiar și directivele Blade sunt înțelese de analizatorul sintactic. Stilul și
codul scris în JavaScript, cunoștințele despre cum poți să rescrii mult mai ușor codul PHP . Integrarea cu modul
de depanare „XDebug” îl ajută să ajungă în fața multor simple editoare de text. Pentru mine, este cel mai de
nădejde prieten în bătălia cu codul dezorganizat și inabordabil.
Pentru a profita din plin de cunoștințele sintactice acestui mediu de dezvoltare, un pachet des întâlnit în
PhpStorm când se construiește o aplicație folosind platforma Laravel este:
„Laravel PhpStorm IDE Helper” ( barryvdh/laravel-ide-helper )
Mulțumită „Eloquent ORM”, de cele mai multe ori PhpStorm nu poate înțelege de ce a fost apelată o metodă
ce nu există – pentru că se va interpreta codul scris în metoda magică __callStatic , ce va traduce numele
metodei statice într-un text, iar apoi într-o clasă ce va construi o cerere SQL. Dar aici intervine „phpDoc”,
sistemul preferat de adnotare a funcțiilor, metodelor și variabilelor PHP . Pachetul astfel introduce trei funcții
ce pot fi apelate de dezvoltator prin intermediul consolei:
•php artisan ide-helper:generate – generare cod „phpDoc” pentru fațade.
•php artisan ide-helper:models – generare cod „phpDoc” pentru modele.
•php artisan ide-helper:meta – generare cod „phpDoc” pentru structura aplicației.
De asemenea, se integrează cu sistemul de gestiune a versiunii codului. Poate să și încarce automat modifi-
cările făcute pe server-ul de producție, folosind protocolul FTP (encriptat, desigur).
Asigură deci rapiditatea și fluența necesară reparării unor probleme critice și a dezvoltării codului concis,
după ghidul dorit de stil.
1.8.4 Heroku
N-ar trebui niciodată să scrii cod direct pe mediul de producție. Dacă ceva nu merge de prima oară, ai
clienți și operatori nemulțumiți. Dar poate că nu ai testat destul pe mediul tău local schimbările făcute. Nu ai
avea de unde să-ți dai seama de toate scenariile posibile.
Pentru a minimiza impactul unei migrări de asemenea proporții, se recomandă un mediu de testare. Heroku
este o platformă distribuită ce oferă platforma sa ca un serviciu („PaaS”). Oferă servicii pentru mai multe
limbaje de programare, printre care și PHP .
Un mare avantaj al platformei Heroku nu este doar modelul gratuit (până la un punct) de implementare.
Este implementarea ultimelor modificări prin intermediul proiectului aflat în sistemul de gestiune a codului.
Preluând ultimele modificări, se pot verifica ultimele modificări aduse codului înainte de a fi urcate pe serverul
de producție.
Oferind și acces în cadrul aplicației la consola Artisan, se pot verifica mai multe sisteme deodată, inclusiv
testele automate. T estele automate pot fi rulate înainte de a se schimba versiunea activă a mediului de testare
pe ultima versiune, pentru a se asigura că nu s-a stricat nimic critic în aplicație.
T oate aceste motive fac din Heroku mediul meu de testare favorit, ce și-a văzut folosința în cadrul acestui
proiect de gestionare a cererilor de despăgubire. Mulțumită ușurinței de a schimba variabilele de mediu, am
putut să testez de fiecare dată când modificam codul sursă al aplicației schimbările. F olosesc în momentul actual
o bază de date de test, inclusă gratuit în pachet.
Doresc să mai investesc timp și să înțeleg mai bine platforma de teste automate, pentru a mă asigura că
majoritatea funcționalității existente, la o schimbare, va continua să funcționeze.
1.8.5 Amazon W eb Services
Inițial, tot proiectul ar fi fost într-o platformă distribuită. Dar problema datelor tot rămânea. T rebuia să
asigur existența și valabilitatea lor pentru o perioadă de minim doi ani. Pentru asta, îmi trebuia un sistem
distribuit de salvare a datelor.
Inițial, mă gândeam să aleg soluția oferită de Azure, pentru că mai interacționasem cu ei. Dar după ce
am mai prospectat piața, am ajuns la concluzia că ar fi mult mai benefic din punctul de vedere al costului
întreținerii și a numărului mare de date să aleg „Amazon W eb Services” — S3.
15

1.8.5.1 Integrarea cu Laravel
Integrarea cu Laravel s-a făcut aproape instantaneu, mulțumită fișierului:
config/filesystems.php
ce se ocupă cu gestionarea fișierelor aplicației.
T ot ce a trebuit să se modifice a fost valoarea implicită pentru „cloud” și să se introducă în fișierul de mediu
cheia (publică și secretă), precum și regiunea server-ului S3 oferit de A WS.
Inițial gândisem un sistem de construire a unei imagini cu o rezoluție mult mai mică și a unei imagini normale
ca dimensiuni, pentru a păstra cât mai mică dimensiunea imaginilor transferate.
După o scurtă perioadă de dezvoltare, după ce s-a ajuns la o variantă finală a algoritmului, descoperisem
că până la urmă, problema era constrângerea de 5000 de acțiuni de a pune în sistemul de date. Optimizasem
prematur o problemă inexistentă. Astfel am renunțat la construirea imaginii cu rezoluție mult mai mică și
nu mai modific imaginea normală. Cu această modificare a crescut imens și numărul de tranzacții posibile de
server-ul găzduit, pentru că nu mai trebuia să modifice fiecare imagine în parte.
Dar eram limitați și de numărul de „GET”-uri (i.e: afișarea unei poze de către un client web). Am setat
ca fiecare obiect încărcat să fie agresiv salvat în memoria clientului web. Atunci când se redeschide cererea de
despăgubire, se află deja salvat în „cache” și nu numai că nu mai face o cerere sistemului de date, dar se și
încarcă instantaneu, ca prin magie.
O problemă ușor rezolvabilă este ștergerea datelor vechi. Am propus și încă aștept un răspuns din partea
firmei ca atunci când o cerere de despăgubire nu va mai fi valabilă, să poată să fie salvate pe calculatorul unei
persoane autorizate din firmă datele încărcate de client și șterse din sistemul distribuit.
1.8.6 Composer
Composer este un utilitar pentru a gestiona referințele externe într-un proiect PHP . Permite dezvoltatorului
să declare librăriile de care depinde proiectului tău și le va gestiona (instala sau actualiza) pentru tine. Spre
diferență de un sistem de gestionează pachetele pentru un sistem de operare bazat pe Linux (precum „ Y um”
sau „Apt”), acesta instalează pachetele în folderul proiectului numit „vendor” , dar permite restrâns instalarea
într-un spațiu „global” , a unor referințe. [ 36]
Laravel depinde de Composer pentru a gestiona referințele. Pentru a porni un nou proiect de Laravel, trebuie
să-l descarci folosind comanda:
composer global require "laravel/installer"
Am vorbit despre extensia mediului de dezvoltare PhpStorm prin pachetul „Laravel PhpStorm IDE Helper” .
Lista completă a pachetelor folosite, în detaliu, în afară de Laravel, a acestui proiect este:
•barryvdh/laravel-ide-helper – extensia mediului de dezvoltare, vezi secțiunea în care prezint mediul
de dezvoltare PhpStorm.
•doctrine/dbal – extensie ajutătoare pentru „Laravel PhpStorm IDE Helper”, pentru a afla toate inte-
racțiunile cu modelele Eloquent.
•laravelcollective/html – extensia „Laravel – F orms & Html”, întreținută de „Laravel Collective” .
•phpoffice/phpexcel – extensie ce ajută citirea și scrierea fișierelor în Excel.
•guzzlehttp/guzzle – extensie ajutătoare pentru A WS S3
•league/flysystem-aws-s3-v3 – principala extensie pentru integrarea Laravel – A WS S3
•golonka/bbcodeparser – librărie ce se ocupă de traducerea „BBCode – HTML” și viceversa.
Composer mai are opțiuni de a porni mai multe aplicații după ce se asigură existența celor mai nou pachete,
prin adăugarea următorului câmp obiect în composer.json :
"post-update-cmd": [
"Illuminate\\Foundation\\ComposerScripts::postUpdate",
"php artisan ide-helper:generate",
"php artisan ide-helper:meta",
"php artisan ide-helper:models -W"
]
După cum observați, comenzile adăugate generează codul ajutător pentru mediul meu de dezvoltare, asigurând
un mediu gata de dezvoltare.
16

1.8.7 Laravel Elixir și npm
„npm” este un utilitar de gestionare a librăriilor pentru limbajul de programare JavaScript. De asemenea,
este utilitarul folosit implicit de mediul de dezvoltare „Node.js” . Este compus dintr-un client accesibil prin linie
de comandă și o bază de date pe internet formată din pachete publice, numit „npm registry” . Registrul este
accesat de client, iar pachetele valabile pot fi găsite și accesate prin intermediul website-ului npm.[ 37]
„ gulp” este un utilitar găsit pe platforma „npm” ce are ca scop automatizarea elementelor ce necesită mult
timp, precum compilarea și mutarea fișierelor dintr-o parte în alta. Acesta preferă codul peste configurație, ce
asigură un sistem rapid de dezvoltare, fără a scrie în fișiere intermediare pe disc.
Laravel a extins interfața sa ușoară de folosit și atunci când vine vorba despre trebuirile legate de „ gulp” .
Elixir astfel știe despre cele mai des folosite procesoare de „CSS” (i.e: „SASS”) și JavaScript (i.e: „ W ebpack”).
F olosind sintaxa de a concatena metode una după alta, Elixir ajută dezvoltatorul a defini propria structură.
De asemenea, împreună cu Laravel, poate gestiona foarte ușor versionare fișierelor. Asigura de fiecare dată
când un client vizitează orice pagină că fișierele de stil și cod sunt actualizate.
În cadrul aplicației, am transformat simplul fișier dat implicit de Laravel „gulpfile.js” într-o platformă
elegantă. Algoritmul constă în următorii pași:
1. Citesc toate fișierele aflate la calea:
resources/assets/js/pages/*
2. Construiesc pentru fiecare fișier în parte o variantă a sa minimizată și cu propriul nume (i.e: numele
concatenat cu versiunea). De asemenea, construiesc pentru principalul stil ( app.scss ) și librăria de cod
a aplicației ( app.js ) la fel varianta minimizată cu propriul nume.
3. La final, Laravel Elixir se ocupă de mutarea lor în fișierul public și modificarea referințelor prin fișierul
JSON aflat la calea:
/public/build/rev-manifest.json
F olosesc „ W ebpack”, un utilitar ce combină mai multe fișiere JavaScript într-unul singur. Prin intermediul
„npm”, am instalat componentele necesare validării timpului, a afișării soluțiilor posibile și a diagramelor prin
simplele comenzi:
// pentru sistemul vizual
require('./bootstrap');
// pentru validarea timpului
require('./components/timepicker.min');
// pentru afișarea soluțiilor posibile
require('./components/typeahead.min');
// pentru diagrame
require('chart.js');
// extensiile proprii
require('./extensions');
1.8.8 LaT eX și Sublime T ext
Din momentul în care m-am apucat să scriu licența, mi-am dat seama de importanța unui sistem ce îmi
asigură legătura între tabelul de conținut și bibliografia. Dar în același timp, trebuie să-mi ofere flexibilitatea
de a putea modifica ordinea instantaneu și de a nu duplica informațiile. Astfel am ajuns la concluzia că cel mai
bun mod de a-mi scrie documentația este să folosesc L ATEX.
T eX este un program de calculator pentru a redacta documente, conceput de „Donald Knuth” . Programul
preia un fișier pregătit și-l transformă într-un format ce poate fi tipărit în diferite moduri, cu diferite imprimante.
LaT eX este un set de macro-uri pentru T eX ce țintesc a reduce din treburile utilizatorului, pentru a se
concentra pe scrisul propriu-zis. [ 38]
Știam că puteam să folosesc conceptele de la programarea „DR Y” („Don’t Repeat Y ourself” – „Nu T e
Repeta”) și astfel am împărțit fiecare capitol în fișierul său separat, cu fiecare fișier având la nevoie sub-directoare
cu secțiunile importante.
17

Am ales să folosesc „Sublime T ext 3” pentru că este unul dintre cele mai versatile editoare de text în
momentul actual. F olosind o extensie, m-a ajutat să pot compila întregul proiect, oriunde m-aș afla în cadrul
lui, în formatul PDF („Portable Document F ormat”), ce poate fi deschis pe orice calculator, cu orice sistem de
operare.
F olosind gândirea de proiect, am setat în „Sublime T ext 3” folosirea unui font cu diacritice. De asemenea,
am activat și descărcat un dicționar gratuit pentru Română.
Asigurându-mă că văd doar ceea ce-mi trebuie în afișajul proiectului, am pornit la scris și nu m-am mai
oprit până când nu am vrut să-mi salvez datele. Știind cât de important este să ai mereu salvat documentele
importante, am decis să-mi țin toată licența pe GitHub, pentru a-mi putea analiza modelul de lucru și orele
cele mai productive.
Codul sursă L ATEX și setările proiectului „Sublime T ext 3” se pot găsi la https://github.com/xiodine32/
licenta_unibuc .
18

Capitolul 2
O scurtă istorie a dezvoltării aplicației
Dezvoltarea a început în Septembrie 2016, când s-au stabilit primele module.
Conform metodologiei de lucru „Agile”, ce se concentrează pe modificări incrementale a cerințelor și a livrării
rapide unei baze funcționale. [ 39]. Chiar dacă am fost singurul dezvoltator al aplicației și nu am avut un lider
de echipă sau o echipă, am vrut să câștig experiența lucrului rapid și să mă folosesc de un canal deschis de
discuții cu persoanele cărora le voi dezvolta aplicația.
Doresc să fac acum distincția între cele trei obiecte în jurul cărora a fost gândită baza de date, înainte de
a vorbi despre structura aplicației, pentru a familiariza cititorul cu aceste noțiuni importante pentru istoria
dezvoltării aplicației.
Baza de date a fost gândită în jurul a trei obiecte: cererea, decizia și vânzarea.
Cererea este scrisă de clientul ce are produsul avariat și îl dorește înlocuit sau reparat. Constă din detaliile
despre sine, obiect, circumstanțe, locație. Este legată conceptual și relațional de pozele pentru:
• Paginile contractului.
• Raportul poliției în caz de furt agravat.
• Copia bonului cu ștampilă.
• Copia actului de identitate.
• Pozele produsului.
Aceasta poate să fie ori respinsă, ori acceptată, construindu-se astfel o decizie.
Decizia este construită în momentul acceptării cererii de despăgubire. Conține datele relevante pentru
rapoartele de vânzare, precum:
• Prețul reparației.
• F ostele decizii asociate. (i.e: foste reparații)
• F ranciza.
• Data livrării produsului în service.
• Costul inspecției și a curierului.
Aceasta, pentru o bună perioadă de timp, era legată obligatoriu de o decizie și de o vânzare.
De la un punct, când trebuia să se importe toate vechile vânzări din raportul păstrat în Excel, s-a luat
decizia de a se decupla aceste două entități. Se construiau până în acel moment vânzări generice, ce nu existau.
Practic, existau într-un raport vânzările respective, dar nu puteau fi găsite din cauza lipsei informațiilor din
partea rapoartelor de la Altex / Media Galaxy . Nu se putea lega IMEI-ul sau numărul facturii, din cauza
modului de organizare a organizației. A veau nevoie urgentă de rapoartele de vânzare, așa că am fost anevoios
de acord să decuplez legătura dintre decizie și vânzare.
Mai nou decizia conține numele produsului, prețul, data achiziționării și perioada asigurată, deși informațiile
tot se citesc din tabelul de vânzări.
Vânzarea conține:
• Numele produsului.
• Prețul produsului.
19

Figura 2.1: Descriere evenimente
• Data achiziționării.
• Perioada de asigurare.
• Numele clientului (ce poate lipsi)
O vânzare poate conține una sau mai multe asigurări, precum unul sau mai multe produse.
2.1 Primul modul
Primul modul și cel mai important era cel de înregistrarea a cererilor de despăgubire. Am discutat despre
soluția actuală, ce probleme are, ce câmpuri ar trebui să fie obligatorii și unde am putea optimiza interacțiunea
clientului cu pagina web.
Un bun exemplu de modificări iterative asupra primului concept este la descrierea evenimentelor, după cum
puteți observa în figura 2.1 .
Inițial fusese vorba despre un simplu câmp text ce va fi la latitudinea utilizatorului spre a fi completat,
dar mulțumită experienței în domeniu, cele mai des folosite motive au fost puse în schimb în această listă. În
cazul în care s-a selectat „Altceva”, detaliile despre descrierea evenimentului devine obligatorie, pentru a ajuta
clientul să identifice câmpurile ce trebuiesc completate.
De asemenea, data și ora au un format ușor de înțeles și respectat, iar atunci când se selectează câmpul
respectiv, apare un element vizual ajutător pentru a introduce corect data și ora.
Pentru acest modul, trebuia să fie funcțională partea din spate de încărcare poze și gestionare a cererilor,
dar și mai important, trebuia să fie gândită deja structura bazei de date, pentru modulele ulterioare.
Am gândit ca fiecărui utilizator să-i atribui un identificator unic, format din 64 caractere, pentru a nu putea
fi abuzat sistemul de încărcare a pozelor. A vantajul clar abordării generării unui „token” unic asigură și metoda
ulterioară de comunicare client – corespondent al companiei prin construirea unei platforme de a trimite și primi
mesaje în Octombrie 2016.
Secțiunea de rapoarte nu exista, dar puteai să cauți în sistemul de cereri în funcție de:
• Nume.
• Prenume.
• Număr de telefon.
• Numele aparatului.
20

• Email.
• Id-ul cererii de despăgubire.
2.2 Problema datelor incomplete
Sistemul de importare al datelor săptămânale, primite de la Altex / Media Galaxy se face printr-un fișier
Excel. Din păcate, nu știam și nu aveam experiența să întreb despre ce format de raport trebuia aplicația mea
să suporte, deci din punctul lor de vedere îmi luasem angajamentul de a importa cu succes toate tipurile de
rapoarte existente de-a lungul timpului.
Când am început dezvoltarea, aveam un singur format ce trebuia respectat și am gândit baza de date astfel
încât să nu mai păstrez câmpurile redundante, precum categoria și codul de bare al produsului. Din păcate,
trebuia să revin asupra algoritmului de a introduce datele aproape pentru fiecare săptămână, când am primit
toate vânzările anterioare. Acest modul a fost în dezvoltare continuă, inclusiv pe perioada dezvoltării altor
module, din cauza discrepanțelor datelor rapoartelor săptămânale.
În aceeași perioadă se termină sistemul de încărcare al pozelor spre Amazon W eb Services și trimiterea
clienților un email de confirmare în momentul înregistrării cererii de despăgubire.
Algoritmul final, finalizat în Ianuarie 2017, ținea cont nu de liniile și de coloanele prestabilite, ci de ce
câmpuri se aflau pe prima linie în raport. Se normalizau și se foloseau pentru a determina ce coloane apăreau
sau nu în raport.
Au fost puține rapoarte ce nu s-au putut importa din cauza lipsei unei coloane obligatorii — a numelui
clientului. Au încercat șefii companiei să discute cu Altex / Media Galaxy și au primit confirmarea schimbării
rapoartelor pe modelul vechi, dar nu au primit rapoartele modificate. S-a ajuns în final la un compromis de
a pune numele clientului „GENERIC”, pentru că existența lor ca o vânzare în perioada respectivă era mai
importantă decât legătura (ce în momentul compromisului nu mai exista) între decizie și vânzare.
2.3 Modulul de rapoarte și decizii
O dată ce a fost implementat modulul de vânzări săptămânale, într-o stare incipientă (după cum s-a explicat
în secțiunea anterioară), s-a trecut la dezvoltarea modulului de decizii.
A fost conceput să se lege obligatoriu de o cerere de despăgubire și de o vânzare.
Inițial, s-au construit rapoarte în format „.csv” (valori delimitate prin virgule). Ulterior s-a adăugat opțiunea
de a putea vedea într-un tabel, în josul paginii, a rezultatelor rapoartelor, precum în figura 2.2 .
Gândirea pentru legătura dintre o vânzare și o decizie se învârte în jurul imposibilității existenței unei cereri
de despăgubire, fără a fi fost vândut, al unui produs.
A vantajul acestei abordări era ușurința aflării deciziilor multiple. Se putea afla ușor pentru că era aceeași
vânzare, dar avea cereri multiple legate.
În această perioadă de timp s-au mai adăugat și culori pentru starea curentă a unei cereri de despăgubiri,
după cum se poate observa în figura 4.8(a) .
După ce s-a terminat modulul de rapoarte, s-a revenit asupra modului de decizii pentru repararea micilor
probleme numerice. Nu înțelesesem cum funcționează franciza, sau a sumei totale de plată.
În acest moment s-a lucrat la adăugarea unei verificări a IMEI-ului clienților ce salvau o cerere de despăgubire
de a limita depunerea unei cereri la un interval de 24 de ore pentru același IMEI. O problemă des întâlnită
de operatorii aplicației erau cererile multiple de la aceeași persoană, cu puține modificări între ele. Prin limita
de 24 de ore pentru același IMEI se împiedicau abuzurile. A fost scrisă astfel încât să nu se afle mai multe
informații decât necesare.
2.4 Decuplarea deciziilor de vânzări
La scurt timp după ce a intrat modulul de legare a deciziilor de vânzări în funcțiune, structura bazei de date
s-a izbit de prima problemă a lumii reale, datele incomplete sau lipsă.
Utilizatorii sistemului nu găseau vânzările asociate cererilor, din cauza incompatibilităților datelor săptămâ-
nale trimise de Altex / Media Galaxy . Problema aceasta a fost accentuată de adăugarea obligativității de a
asocia decizia cu cererea de despăgubire. Înainte de a putea modifica orice câmp ce ținea de cerere, mulțumită
dezvoltării treptate, trebuia astfel găsită asocierea, pentru a reduce din numărul cererilor fără decizie, pentru a
recupera din datoria tehnică.
De la un punct, când trebuia să se importe toate vechile vânzări din raportul păstrat în Excel, s-a luat
decizia de a se decupla decizia de vânzare.
21

Figura 2.2: Statistici
Am încercat pentru un scurt moment de a modifica interfața de asociere a cererii și a vânzării pentru a forma
o despăgubire, adăugând opțiunea de creere a unor vânzări generice. Problema apare când se dorește scoaterea
unui raport de vânzare într-o anumită perioadă, deoarece nu se știe magazinul ce a vândut produsul.
Deci, într-un final, am decuplat decizia de vânzare. Am renunțat la structura strâns legată a cererilor de
vânzări, în favoarea căutării manuale. Fiecare decizie acum conține detalii și despre produs și despre asigurare.
Altă soluție mai elegantă nu s-ar fi putut găsi, deoarece lipsa de informații ce n-ar putea să difere din cadrul
cererii de despăgubire și a datelor primite nu există.
2.4.1 Modificări în viitorul apropiat
Doresc să reintroduc în viitorul apropiat descoperirea automată a deciziilor vechi înapoi prin adăugarea unui
câmp de factură la asocierea unei noi cereri de o vânzare.
Diferența acum, față de sistemul decuplat, este că pot să aflu ce decizii au fost legate înainte, mulțumită
serviciului de backup, dar și a modului actual de legare a informațiilor, pentru că informațiile legate de vânzare
nu au fost modificate până acum de mână.
A vantajul existenței opționale a câmpului de factură ajută la funcționarea algoritmului elegant de găsire a
deciziilor, pentru că ar fi același număr de factură, adică aceeași vânzare. Normal că ar trebui să fie trecut prin
prisma utilizatorului sistemului, deoarece s-ar putea referi factura la un alt produs și o altă asigurare. De aceea
sistemul ar fi opțional, precum sistemul actual de IMEI duplicat.
2.5 După planul inițial de dezvoltare
În urma discuțiilor și finalizării modulelor inițiale, s-a finalizat dezvoltarea modulelor pe orizontală, dar
s-a mutat pe verticală. A dezvolta pe orizontală reprezintă dezvoltarea modulelor și a legăturii dintre ele, iar
a dezvolta pe verticală reprezintă aprofundarea unui domeniu (în cazul acesta, a construirii rapoartelor și a
introducerii datelor).
După o întâlnire, s-a decis introducerea fostelor facturi plătite în sistem și ulterior posibile planuri pentru
un sistem modular de rapoarte.
22

2.5.1 Introducerea datelor și rapoartele avansate
La fel ca în cazul datelor primite de la Altex / Media Galaxy , rapoartele primite (de data asta complete)
au determinat o parcurgere completă a lor și modificarea coloanelor ce existau într-un raport, dar lipseau
dintr-altul.
Mulțumită numărului redus de rapoarte dorite s-a reușit parcurgerea lor și asigurarea unui algoritm mai
simplu din punctul de vedere al condițiilor posibile.
S-au mai descoperit probleme în momentul introducerii lor de două ori in baza de date – operație ce n-ar fi
trebuit să mai arate diferențe între datele introduse și cele deja existente. Unele câmpuri se modificau de două
ori. De vină a fost greșeala umană și după ce s-a discutat cu persoanele responsabile de rapoarte s-au mutat
pe server-ul de producție.
2.5.2 În continuare
Chiar dacă s-a terminat dezvoltarea și pe verticală, mai există o mică problemă nu-mi dă pace: problema
tabelelor prea mari. T abela cu cele mai multe informații, a cererii, are în momentul actual 48 coloane.
Doresc să construiesc o migrare cu următoarele tabele:
• Persoană
• Eveniment
• F actură
• Produs
• Garanție veche
Aceste tabele vor avea o relație unu-la-unu cu tabela cererii. Se vor încărca din baza de date doar valorile
necesare. Se va putea implementa mult mai ușor și statistici pentru fiecare persoană, eveniment sau factură.
Legat de statistici, se dorește după o scurtă pauză de dezvoltare implementarea unui sistem modular de
rapoarte. S-ar defini prin intermediul unei interfețe grafice ce câmpuri să fie scoase, din ce tabele, cu ce legături
între ele. Rapoartele vor fi salvate în Excel și se vor putea reutiliza șabloane pentru cele mai des folosite.
Practic, se dorește înlocuirea sistemului actual de rapoarte cu unul nou, modular.
23

Capitolul 3
Structura aplicației
3.1 Un exemplu de cerere
Pentru a recapitula tehnologiile folosite și pentru a putea intra în detalii despre cum funcționează aplicația
per ansamblu, voi detalia cum interacționează un utilizator cu acest sistem de gestiune a cererilor de despăgubire,
bazat pe Laravel. Cererea pornește de la premiza accesării paginii scrise în regulamentul contractului „Mobile
Protect” și parcurge pașii unui client web (ceea ce nu se observă când se încarcă pagina).
1. Clientul navighează spre www.fandu.uk/claims .
2. El este redirectat spre https://fandu.info , prin intermediul „header”-ului, pagina livrată fiind goală.
3. F olosind un sistem distribuit de nume de domeniu, presupunând că domeniul nu a fost descoperit până
acum de client, se face cererea către CloudFlare. Presupunem că nu este un atac malițios, altfel ar fi fost
oprit în acest punct și ar fi fost posibil obligat să rezolve o serie de întrebări pentru a continua. Depinde
de severitatea atacului.
4. Aplicația Laravel se încarcă. Își identifică astfel mediul de lucru și variabilele definite.
5. Se conectează la baza de date MySQL și încearcă să identifice sesiunea clientului, în funcție de „cookie”-ul
denumit „laravel_session” . Pentru că presupunem că este un client nou, nu va găsi o sesiune deja existentă.
Nu este un client înregistrat.
6. Laravel observă rutele predefinite și încearcă să găsească o rută ce se potrivește căii, reținând contextul.
7. În acest moment, Laravel deține numele Controller-ului, numele metodei ce va fi apelate și toate denumirile
scurte ale claselor intermediare ce trebuiesc validate pentru a ajunge cererea la metoda clasei, aceste clase
mijlocii fiind denumite „middleware” .
Un exemplu bun al unei clase middleware este „auth”, ce asigură un utilizator înregistrat, cu o sesiune
activă.
8. Se construiește Controller-ul folosind calea determinată la pasul anterior și se actualizează (în cazul în
care apare cod de adăugare unei clase „middleware” în interiorul metodei ce construiește obiectul) lista
de „middleware” .
9. Se construiește și se validează fiecare clasă „middleware”, iar în cazul unui eșec, nu se va continua mai
departe.
10. Se apelează metoda clasei asigurându-se prin intermediul unui obiect ce rezolvă legăturile dintre obiectele
dorite și cele existente trimiși ca parametrii metodei Controller-ului. Se va primi un răspuns.
11. În cazul în care răspunsul nu este o directivă Blade, se va afișa sau va redirecționa clientul web. Altfel,
se va compila directiva Blade dacă nu există fișierul deja compilat, sau dacă timpul ultimei modificări
directivei e mai recent decât timpul ultimului rezultat al compilării.
3.2 Baza de date
T abelele din baza de date sunt denumite cu pluralul obiectului la care se referă, folosind în loc de spații
sublinia „_” . Puteți observa în detaliu diagrama bazei de date la figura 3.1
Aceasta este salvată o dată pe săptămână și conține datele despre:
24

int(10) unsigned
id
char(13)
external_id
date
date
text
customer
text
customer_code
text
shop
timestamp
created_at
timestamp
updated_at
text
shop_id
sales
int(10) unsigned
id
char(13)
external_id
date
date
text
customer
text
customer_code
text
shop
timestamp
created_at
timestamp
updated_at
text
shop_id
sales
int(10) unsigned
id
int(10) unsigned
claim_id
int(10) unsigned
user_id
text
message
timestamp
created_at
timestamp
updated_at
messages
int(10) unsigned
id
int(10) unsigned
claim_id
int(10) unsigned
user_id
text
message
timestamp
created_at
timestamp
updated_at
messages
int(10) unsigned
id
int(10) unsigned
sale_id
text
name
double
price
int(11)
quantity
timestamp
created_at
timestamp
updated_at
products
int(10) unsigned
id
int(10) unsigned
sale_id
text
name
double
price
int(11)
quantity
timestamp
created_at
timestamp
updated_at
products
varchar(255)
id
int(11)
user_id
varchar(45)
ip_address
text
user_agent
text
payload
int(11)
last_activity
sessions
varchar(255)
id
int(11)
user_id
varchar(45)
ip_address
text
user_agent
text
payload
int(11)
last_activity
sessions
int(10) unsigned
id
varchar(255)
migration
int(11)
batch
migrations
int(10) unsigned
id
varchar(255)
migration
int(11)
batch
migrations
int(10) unsigned
id
int(10) unsigned
claim_id
int(10) unsigned
user_id
text
message
timestamp
created_at
timestamp
updated_at
chat_claims
int(10) unsigned
id
int(10) unsigned
claim_id
int(10) unsigned
user_id
text
message
timestamp
created_at
timestamp
updated_at
chat_claims
int(10) unsigned
id
text
tip
text
nume
text
prenume
text
strada
text
localitatea
text
tara
text
cod_postal
text
telefon
varchar(64)
email
text
nume_aparat
text
producator
text
pret_aparat
text
imei
text
numar_serie
varchar(64)
numar_factura
date
data_factura
text
localitate_filiala
text
locatie_eveniment
text
eveniment_strada
text
eveniment_localitate
text
eveniment_cod_postal
text
eveniment_tara
text
p_varsta
text
p_prenume
text
p_nume
text
p_strada
text
p_localitate
text
p_cod_postal
text
p_tara
text
p_telefon
text
descriere_evenimente
date
eveniment_data
time
eveniment_timp
text
descriere_defecte
tinyint(1)
detalii
text
add_companie
text
add_numar
text
add_despagubire
timestamp
created_at
timestamp
updated_at
char(32)
token
text
status
text
descriere_evenimente_add
tinyint(1)
viewed
tinyint(3)
real_status
tinyint(1)
finished
date
reminder_date
claims
int(10) unsigned
id
text
tip
text
nume
text
prenume
text
strada
text
localitatea
text
tara
text
cod_postal
text
telefon
varchar(64)
email
text
nume_aparat
text
producator
text
pret_aparat
text
imei
text
numar_serie
varchar(64)
numar_factura
date
data_factura
text
localitate_filiala
text
locatie_eveniment
text
eveniment_strada
text
eveniment_localitate
text
eveniment_cod_postal
text
eveniment_tara
text
p_varsta
text
p_prenume
text
p_nume
text
p_strada
text
p_localitate
text
p_cod_postal
text
p_tara
text
p_telefon
text
descriere_evenimente
date
eveniment_data
time
eveniment_timp
text
descriere_defecte
tinyint(1)
detalii
text
add_companie
text
add_numar
text
add_despagubire
timestamp
created_at
timestamp
updated_at
char(32)
token
text
status
text
descriere_evenimente_add
tinyint(1)
viewed
tinyint(3)
real_status
tinyint(1)
finished
date
reminder_date
claims
int(10) unsigned
id
text
location
int(10) unsigned
claim_id
timestamp
created_at
timestamp
updated_at
int(10) unsigned
category
photos
int(10) unsigned
id
text
location
int(10) unsigned
claim_id
timestamp
created_at
timestamp
updated_at
int(10) unsigned
category
photos
int(10) unsigned
id
int(10) unsigned
decision_id
int(10) unsigned
parent_id
decisions_decisions
int(10) unsigned
id
int(10) unsigned
decision_id
int(10) unsigned
parent_id
decisions_decisions
varchar(255)
email
varchar(255)
token
timestamp
created_at
password_resets
varchar(255)
email
varchar(255)
token
timestamp
created_at
password_resets
int(10) unsigned
id
int(10) unsigned
sale_id
char(64)
name
double
price
int(11)
quantity
date
expire_date
timestamp
created_at
timestamp
updated_at
assurances
int(10) unsigned
id
int(10) unsigned
sale_id
char(64)
name
double
price
int(11)
quantity
date
expire_date
timestamp
created_at
timestamp
updated_at
assurances
int(10) unsigned
id
varchar(255)
name
varchar(255)
email
varchar(255)
password
varchar(100)
remember_token
timestamp
created_at
timestamp
updated_at
users
int(10) unsigned
id
varchar(255)
name
varchar(255)
email
varchar(255)
password
varchar(100)
remember_token
timestamp
created_at
timestamp
updated_at
users
int(10) unsigned
id
int(10) unsigned
claim_id
date
approval_date
date
in_date
date
out_date
tinyint(3) unsigned
resolution
decimal(8,2)
courier_cost
text
courier_invoice_number
decimal(8,2)
franchise
text
payee
decimal(8,2)
payee_cost
timestamp
created_at
timestamp
updated_at
text
payee_invoice
decimal(8,2)
premium
decimal(8,2)
to_pay
decimal(8,2)
repair_replace_cost
text
observations
date
payee_date
decimal(8,2)
inspection
text
product_name
decimal(8,2)
product_price
date
product_expire_date
date
product_sale_date
decisions
int(10) unsigned
id
int(10) unsigned
claim_id
date
approval_date
date
in_date
date
out_date
tinyint(3) unsigned
resolution
decimal(8,2)
courier_cost
text
courier_invoice_number
decimal(8,2)
franchise
text
payee
decimal(8,2)
payee_cost
timestamp
created_at
timestamp
updated_at
text
payee_invoice
decimal(8,2)
premium
decimal(8,2)
to_pay
decimal(8,2)
repair_replace_cost
text
observations
date
payee_date
decimal(8,2)
inspection
text
product_name
decimal(8,2)
product_price
date
product_expire_date
date
product_sale_date
decisions
sale_id:id
sale_id:id
decision_id:id
claim_id:id
parent_id:id
claim_id:id
claim_id:id
user_id:id
user_id:id
claim_id:id
Figura 3.1: Diagrama bazei de date
25

1.claims – Cererile de despăgubire.
2.sales – Vânzări, cu legăturile de cheie primară (una-la-multe) la următoarele tabele:
(a)products – Produse
(b)assurances – Asigurări
3.decisions – Decizii, cu legătura circulară folosind tabelul
decisions_decisions .
4.chat_claims – Mesajele trimise în cadrul cererilor între utilizatorii sistemului, ce depinde de tabelul de
cereri.
5.messages – Mesajele trimise în cadrul cererilor între client și utilizatorii sistemului, ce depinde de tabelul
de cereri.
6.migrations – Migrările schemei bazei de date, menținut de Laravel.
7.users – Utilizatorii aplicației, cu parola encriptată.
8.photos – Legăturile între locația pozelor și cererea, respectiv categoriilor lor, ce depinde de tabelul de
cereri.
26

3.3 Laravel MVC
Revenind la definiția arhitecturii, „Model-View-Controller” se bazează pe separarea puterii celor trei com-
ponente definitorii pentru o aplicație: Modelul, View-ul, respectiv Controller-ul.[ 15]
Modelul este componenta centrală a șablonului. Ea se ocupă de datele aplicației, iar mulțumită Laravel
Eloquent, face legătura dintre baza de date și aplicație.
Modelele sunt gestionate de Controller, ce acceptă datele de la utilizator și le transformă în comenzi pentru
model și/sau View.
View-ul este orice metodă de vizualizare a informației unui Model – în cazul nostru directivele Blade.
Laravel construiește astfel aplicații web bazate pe arhitectura „Model-View-Controller” . Deci și această
aplicație respectă arhitectura.
În cadrul aplicației următoarele căi sunt notabile:
• Model – /app/
• View – /resources/views/
• Controller – /app/Http/Controllers/
3.3.1 Controllers
În afară de separarea conceptuală a arhitecturii MVC, Laravel se folosește și de un sistem de gestionare a
rutelor aplicației. [ 40]
Spre deosebire de alte librării precum CakePHP , Laravel nu pune mult accent pe numele Controller-ului. Ci
mai degrabă se folosește de un fișier principal unde se specifică legătura dintre un URL și un Controller, ce se
regăsește în cadrul proiectului Laravel la:
/routes/web.php
În cazul proiectului de gestionare a cererilor de despăgubire, se pune foarte mult accent pe securitatea
datelor. Din acest motiv, printre primele linii ale fișierului, regăsim
URL::forceSchema("https");
ce indică schemei de rutare Laravel rescrierea oricărui link a folosi HTTPS, pentru a menține legătura encriptată
cu clientul. În cazul în care clientul cere varianta normală (HTTP) a unei pagini, el este redirectat automat
spre varianta HTTPS. Din acest motiv nu am activat în cadrul „CloudFlare” opțiunea de „Automatic HTTPS
rewrites” (rescrieri automate HTTPS), pentru că deja se ocupă de asta librăria Laravel. În cazul în care aș fi
activat opțiunea respectivă, s-ar fi bătut cap în cap cu implementarea Laravel. Nu am descoperit cauza, dar
încă investighez.
Un mare avantaj al sistemului de rutare este gruparea rutelor prin includerea automată a unor „middleware”,
precum sistemul de asigurare a unui utilizator cu o sesiune activă, dar și scurtarea căilor Controller-lor sau căilor.
Se poate observa prin intermediul codului:
Route::group([
'middleware' => 'auth',
'prefix' => 'admin',
'namespace' => 'Admin',
], function () {
// funcții aici
});
• prefixarea căilor cu „admin”
• în numele spațiului claselor „Admin”
• ce sigur va conține „middleware”-ul „auth”
Laravel în afară de cererile simple poate combina mai multe dintre cererile simple într-o „resursă” . Cererile
simple pot fi:
• GET – citește una sau mai multe informații.
• POST – salvează (de obicei prin adăugare) o informație (de obicei nouă).
27

• PUT / P A TCH – modifică de obicei o informație deja existentă.
• DELETE – șterge informația.
O „resursă” în Laravel atribuie rutele „CRUD” (Create / Read / Update / Delete) unui Controller cu o
singură linie de cod:
Route::resource('obiecte', 'ObiectController');
Și mulțumită consolei Artisan, se poate construi la fel de rapid și codul necesar unui astfel de Controller, prin
simpla comandă:
php artisan make:controller ObiectController –resource
Următoarele acțiuni sunt definite și gata de a fi modificate de dezvoltator pentru a fi gestionate:
V erb URI Acțiune Nume rută
GET /obiecte index obiecte.index
GET /obiecte/create create obiecte.create
POST /obiecte store obiecte.store
GET /obiecte/{obiect} show obiecte.show
GET /obiecte/{obiect}/edit edit obiecte.edit
PUT/P A TCH /obiecte/{obiect} update obiecte.update
DELETE /obiecte/{obiect} destroy obiecte.destroy
În cadrul proiectului, am următoarea structură a directoarelor controalelor:
• F olderul implicit:
–MessagesController.php – gestionează mesajele trimise între client și operatorul cererii de despă-
gubire.
–HelperController.php – ajută la testarea sistemului de mail și menținerea sesiunii clientului.
–ClaimsController.php – construiește cererea de despăgubire, afișează pagina principală și clauza de
confidențialitate.
• F olderul Json :
–ImagesController.php – gestionează încărcarea pozelor asincron de către client sau operator spre
soluția distribuită de stocare a datelor — Amazon W eb Services S3.
• F olderul Admin :
– F olderulJson :
∗SearchController.php – gestionează încărcarea rezultatelor parțiale asincron de către operator.
–ClaimsController.php – gestionează vizualizarea, modificarea și finalizarea cererilor de despăgubire.
În cazul în care se găsește în parametrul GET (ce urmează dupa „?” în cadrul URL-ului) id , se va
încerca redirecționarea spre cererea de despăgubire cu acel id . Dacă este aplicată o căutare, afișează
toate rezultatele, altfel paginează câte 100 cereri pe pagină folosind Eloquent.
În momentul în care se salvează o cerere noua de despăgubire, se trimite un mail cu datele create
către căsuța principală a operatorilor sistemului și către client. El este rugat să-și verifice și căsuța
de mail, iar cât mai curând să încarce toate pozele necesare completării dosarului său.
Sistemul de căutare poate căuta în:
∗ Număr de telefon.
∗ Nume.
∗ Prenume.
∗ Model telefon.
∗ Email.
∗ O dată de început a facturii.
∗ O dată de sfârșit a facturii.
–DecisionController.php – gestionează vizualizarea, modificarea și posibila șterge a deciziilor cere-
rilor de despăgubire. În cazul în care există o căutare, acesta caută și în cerere, și în decizie, folosind
următoarele câmpuri:
28

∗ Număr de telefon.
∗ Nume.
∗ Prenume.
∗ Model telefon.
∗ Email.
∗ O dată de început a înregistrării cererii.
∗ O dată de sfârșit a înregistrării cererii.
∗ Numele produsului conform deciziei.
În cazul creării unei noi decizii în funcție de o cerere de despăgubire, se încearcă mai întâi găsirea
automată a vânzării asociate după numărul facturii. Dacă căutarea nu reușește, atunci se va indica
utilizatorului necesitatea unei construirii unei legături manuale.
Pentru a salva o legătură între o cerere de despăgubire și o decizie, trebuie să existe următoarele
câmpuri completate valid, ce nu trebuie să fie vide:
∗claim_id – id-ul cererii de despăgubire.
∗product_name – numele produsului de pe factură.
∗product_price – prețul produsului de pe factură.
∗product_premium_price – prețul asigurării.
∗product_sale_date – data vânzării produsului.
∗product_expire_date – data expirării asigurării.
Dacă se salvează cu succes decizia, ea va apărea asincron, integrată în pagina de vizualizării a cererii
de despăgubire, în josul paginii.
–HomeController.php – gestionează o interfață simplă cu două rapoarte, împreună datele de contact
personale, în cazul în care apare vreo problemă.
Sistemul arată precum în figura 4.7 .
–ImportController.php – gestionează sistemul de introducere de date prin fișierele Excel în sistem.
Acesta construiește automat un adaptor ce preia fișierul Excel și afișează un răspuns, de obicei printr-
un View. Este împărțit în două categorii de fișiere — cele standarde, despre care s-au discutat la
momentul definitivării modulelor și cele personalizate pentru fișierele apărute pe parcursul dezvoltării.
Această diferențiere apare mulțumită notificării trimise pe email în momentul salvării cu succes a
datelor din fișierele standard.
Sistemul arată precum în figura 4.11(a) .
–ReportsController.php – gestionează sistemul de rapoarte. Inițial scris astfel încât dintr-o singură
metodă să reiasă un raport, acum funcționează modular și necesită cod asincron JavaScript pentru
a scoate un raport.
Sistemul a fost conceput astfel din cauza numărului imens de date ce trebuia să treacă prin modulul
ce transformă datele în fișierul de format Excel. Fiecare raport are o metodă ce decide dacă mai
are nevoie de pași suplimentari și deci de încă o cerere asincronă, pentru a folosi apoi la final, la
pasul de combinare, toate datele din fișiere pentru a scoate raportul în formatul dorit. A vantajul
folosirii fișierelor temporare și a mai multor apeluri asincrone este de a face interfața cu utilizatorul
mai plăcută și în același timp de a reduce din consumul de memorie.
Pentru a arăta interactiv că fișierul s-a descărcat cu succes, setez un „cookie” atunci când descarcă
fișierul utilizatorul, iar în pagina de rapoarte aștept apariția acestui „cookie” pentru a semnala
finalizarea descărcării. După ce l-am identificat, îl șterg setându-l să expire pe „1 Ianuarie 1970
00:00:01 GMT” .
Sistemul arată precum în figura 3.3 .
–SalesController.php – gestionează existența, modificarea, afișarea și căutarea vânzărilor introduse
în sistem.
F uncția de căutare, prezentă în figura 3.4 se referă la:
∗Product – Numele produsului căutat.
∗Customer – Numele clientului ce a cumpărat produsul.
∗Date Start – Data de început de când s-ar fi putut vinde produsul.
∗Date End – Data de sfârșit de când s-ar fi putut vinde produsul.
∗Date Added – Data când a fost importat fișierul (acest câmp, conform statisticilor Google Ana-
lytics, este degeaba și va fi scos într-o variantă ulterioară, cel mai probabil).
29

Figura 3.2: Sistemul de rapoarte
Figura 3.3: Căutarea vânzărilor
30

Figura 3.4: Sistemul de salvare a bazei de date
∗External ID – Numărul facturii.
–ProductsController.php șiAssurancesController.php – gestionează doar construirea și ștergea
produselor, respectiv asigurărilor, din interfața ce modifică vânzările. Nu au niciun alt rol.
–ExportController.php – gestionează compunerea unor fișiere .CSV cu toate datele, fără a fi trecute
printr-un filtru, a unui tabel din baza de date.
A fost folosit într-un moment de „criză”, unde era nevoie obligatoriu de a putea scoate datele din
sistemul informatic pentru a trimite un raport rapid, când nu era gata sistemul de raportare.
Nu are interfață grafică.
–BackupController.php – gestionează sistemul actual de salvare a bazei de date de orice operator al
companiei. Acest sistem necesită din cauza acelorași probleme de memorie mai multe apeluri, pentru
a construi arhiva cu toate datele tabelelor bazei de date. Se folosește de punctul de colectare:
storage_path("app/*.sql")
și comprimă tot ce găsește obținut din apelurile asincrone din JavaScript anterioare pentru a compune
o arhiva finală „.tar.gz” .
Pe serverul de producție este foarte lentă compunerea arhivei finale, așa că voi considera scoaterea
comprimării arhivei și transmiterea folosind unei arhive „.zip” . Nu pot să folosesc și algoritmi de
comprimare a datelor pentru arhivele „.zip” deoarece s-a adăugat abia în PHP 7 opțiunea.
În prima parte a figurii 3.5 este interfața ce permite salvarea individuală a tabelelor. În momentul
apăsării butonului de „Download All”, o să arate precum în a doua parte a figurii.
–SettingsController.php – gestionează
• F olderul Auth este cel construit implicit de Laravel atunci când construiește codul de a autentifica utili-
zatorii.
O mică modificare ce s-ar putea să treacă neobservată este schimbarea controller-ului RegisterController
de a fi folosit împreună cu grupul algoritmului 3.3.1 , ceea ce indică puterea de a adăuga utilizatori aparține
doar utilizatorilor de sistem.
De asemenea, singurul mod prin care se poate înregistra un utilizator nou este prin cunoașterea adresei
specifice Controller-ului:
Route::get('register', [
'middleware' => 'auth',
'as' => 'register',
'uses' => 'Auth\RegisterController@showRegistrationForm
']);
Route::post('register', [
'middleware' => 'auth',
'as' => 'register.post',
'uses' => 'Auth\RegisterController@register'
]);
Pentru a nu fi blocați pe dinafară, se adaugă mereu un utilizator în baza de date printr-o migrare.
31

3.3.2 Models – Eloquent ORM
Baza noastră de date relațională conține multe relații. Spre exemplu, cererea de despăgubire poate că este
legată la o decizie. Eloquent ORM ajută gestionarea și lucrul cu aceste legături foarte ușor și suportă majoritatea
legăturilor, printre care:
1. One T o One
2. One T o Many
3. Many T o Many
Relațiile Eloquent sunt definite ca metode în clasele noastre. Precum modelele în sine, acestea sunt folosite
precum generatoare de sistem. Definind relațiile precum funcții ajută la propagarea metodelor și concatenarea
mai multor constrângeri, precum pozele facturii determinate de această metodă aflată în clasa cererii:
public function factura_photos()
{
return $this->hasMany('App\Photo')
->where('category', Photo::FACTURA);
}
În acest caz, pentru că fotografie se poate afla în oricare dintre cele patru categorii, se pune constrângerea ca
ea să se afle în categoria facturii. Punându-se în legătură mai multe poze la un singur obiect, această relație
„One T o Many” are nevoie de câmpul claims_id să fie prezent în coloana tabelei de poze, conform convenției
Laravel. [ 41]
Acum că putem să accesăm toate pozele unei cereri, putem defini și relația inversă. Schimbând registrul de
la poze la decizii, putem accesa având decizia cererea din care provine. Pentru asta, se folosește următoarea
metodă în clasa deciziei:
public function claim()
{
return $this->belongsTo('App\Claim');
}
La fel, pentru că respectă convenției Laravel – se regăsește câmpul claims_id – se va completa și încărca
modelul Eloquent a cererii, atunci când va fi apelată metoda.
De asemenea, toate metodele folosite sunt „puturoase” . Ele nu sunt interpretate și nu rețin rezultatul până
când nu au fost chemate cel puțin o dată.
Presupunând că am dori să avem un număr rotund în loc de cel rotunjit cu virgulă mobilă cu o simplă
precizie, am putea să definim un accesor. Un accesor cu numele getFirstNameAttribute va fi apelat în
momentul apelării aflării valorii proprietății first_name . Cel mai bun exemplu este calcularea valorii de plată
nete din modelul „Decision”:
public function getNetPayableAttribute()
{
if ($this->resolution == Decision::REPAIRED) {
return $this->repair_replace_cost – $this->franchise
+ $this->courier_cost;
}
if ($this->resolution == Decision::REPLACED) {
return $this->payee_cost – $this->franchise
+ $this->courier_cost;
}
return "N/A";
}
O altă problemă delicată ce ar putea apărea într-un sistem de legare relațională între obiecte și reprezentările
bazei de date constă în câmpurile ce pot fi atribuite „la grămadă” . O vulnerabilitate „la grămadă” apare atunci
când un utilizator mai adaugă să spunem un câmp „Administrator” când se înregistrează și-l setează pe adevărat,
ce este trimis apoi în metoda de creare a relației tabel – obiect, escaladându-și astfel drepturile.
Pentru a nu fi vulnerabili, putem specifica doar variabilele ce pot fi atribuite „la grămadă” . Asta împiedică
atribuirea altor câmpuri existente, asupra modelului Eloquent. F uncționează incluzând următoarea linie:
protected $fillable = ['nume', 'elemente', 'tabel'];
32

Revenind la proiectul nostru, am mai definit o metodă numită getReadable , pentru a afla ce câmpuri sunt
obligatorii a fi completate, pentru a construi un nou model.
Următoarele modele au cod propriu interesant:
•Decision – Se folosește de o metodă „F actory” (ce produce obiecte gata pregătite) pentru a construi
obiecte din vânzări sau din elemente generice.
De asemenea se mai calculează prin intermediul metodelor „remaining” și„updateToPay” sumele rămase,
respectiv de plătit.
•Photo – Se folosește o metodă „F actory” preia extensia și construiește un șir aleator din 32 de caractere,
imposibil de ghicit.
După aceea se atribuie modelului categoria și cererea din care face parte.
În final, se încarcă pe S3 și se salvează în baza de date.
De asemenea, este extinsă metoda prin care se șterge modelul, asigurându-se ștergerea sa și de pe A WS
S3.
•Sale – În afară de metoda ce compune un nou generic sale, ce nu mai e folosită, acest model mai oferă și
două metode pentru calcularea prețului total al produselor și cantității lor.
De asemenea, mai oferă încă două metode pentru calcularea prețului total al asigurărilor și a cantităților
lor.
3.3.3 Views
Gândirea pe care am urmat-o dezvoltând aplicația de gestiune a cereri de despăgubiri, când vine vorba de
interfața grafică, a fost bazată pe module.
De menționat că multe directoare conțin un director numit „includes” . Acest director conține directive Blade
parțiale ce sunt utilizate pe parcursul afișării, modificării sau interacțiunii cu paginile principale.
Astfel, interfața e împărțită în mai multe directoare:
•vendor – elementele de paginație extrase din context, ce permit păstrarea parametrilor „GET” în momentul
folosirii paginației.
Am ales să fac modificarea implicită de a adăuga doar câmpurile folosite la momentul respectiv pentru că
era singurul scenariu în care se puteau pagina rezultatele.
•settings – elementele vizuale ce afișează setările și interfața de a salva datele aplicației.
•sales – elementele ce permit vizualizarea, crearea, modificarea și ștergea produselor și asigurărilor, în
cazul coruperii datelor.
•reports – elementele de paginație ce permit construirea rapoartelor.
Se folosesc de Laravel Elixir pentru a adăuga codul scris în fișierul JavaScript reports.js în pagină.
Astfel se asigură viteza optimă de distribuire a resurselor și funcționalitate cu tipurile de raport.
Integrarea cu Knockout se face implicit prin declararea includerea din componenta vizuală de șablon a
aplicației a fișierului app.js .
•newclaim – elementele de paginație ce sunt vizualizate prima oară de clienții aplicației.
Directorul includes conține împărțit pe componente toate marile arii acoperite de cererea de despăgubire,
printre care și un parțial inclus în mail-ul trimis mai departe. Acest parțial Blade se referă la actele necesare
a fi încărcate în a doua parte a aplicației. (partea de încărcare imagini)
•messages – elementele de paginație ce sunt incluse cu fiecare tranzacție, ce asigură un canal de comunicare
între client și operatorul aplicației.
•mail – Înăuntrul acestui director se află fișierul layout.blade.php , ce conține stilul general valabil tuturor
email-urilor trimise.
De asemenea include pentru fiecare tip de obiect o acțiune desăvârșită ca nume.
33

•layouts – conține singurul fișier app.blade.php , de care depinde toate celelalte View-uri.
În cazul în care utilizatorul nu este înregistrat, nu îi se arată bara de navigație în cadrul aplicației de
administrare.
De asemenea, conține referințe la Laravel Elixir, mai ales la stilul și codul precompilat și optimizat de
„ gulp” (pentru că până la urmă, gulp lucrează cel mai mult).
În afară de aceste mici modificări, împreună cu Google Analytics și metoda specială de a picura câte o
cerere de actualizare a sesiunii la câteva minute, tranformă această pagină a aplicației într-un adevărat
utilitar și arată funcționalitatea pe deplină a directivelor Blade.
•import – elementele de paginație ce sunt vizualizate de cei ce doresc să introducerii date în sistem.
Directorul steps conține împărțit pe componente toate rezultatele posibile introducerii standard de date,
dar și celor modificate.
Directorul types conține rezultatele introducerii datelor în sistem, în formatul standard de date.
•errors – elementele de paginație ce vor fi afișate în caz de erori cu numărul respectiv.
•decisions – elementele de paginație extrase pentru decizii.
Conține și o metodă eficientă și rapidă, folosind jQuery , de a sorta informațiile prin apăsarea butoanelor
colorate din capul tabelului.
•components – elementele de paginație extrase din context, ce-mi permite să scriu mai puțin cod pentru a
folosi panourile din Bootstrap.
•claims – elementele de paginație extrase pentru cereri.
Conține și o metodă eficientă și rapidă, folosind jQuery , de a sorta informațiile prin apăsarea butoanelor
colorate din capul tabelului.
Directorul includes conține componenta de căutare și componenta de modificare a cererii de despăguipre
dacă persoana era autorizată (înregistrată și cu o sesiune activă).
•auth – elementele originale de înregistrare, logare și resetare parolă.
•home.blade.php – Pagina de introducere când intri în sistem.
.
3.3.4 F uncții ajutătoare
F uncțiile ajutătoare sunt pentru a minimiza timpul dezvoltatorului de lucru. Fișierele astfel folositoare sunt:
1.FormHelper – Utilitar ce înregistrează o directivă Blade de compunere, ce sunt traduse în simple instruc-
țiuni de cod PHP . Am scris astfel propria directivă de a construi automat codul necesar afișării, folosind
HTML și librăria vizuală „Bootstrap”, a unui câmp dintr-un formular, cu nume, tip și validare proprie:
@input(['p_varsta', ['Varsta', true]])
// unde 'p_varsta' – id-ul câmpului.
// unde 'Varsta' – denumirea câmpului.
// unde 'true' – necesitatea completării câmpului.
2.Helpers – F uncțiile ce traduc o variabilă în ceva mai util, precum un șir ce poate fi citit mult mai ușor,
dar ce și traduc starea actuală a unei cereri sau decizii în clasa specială CSS.
3.TemporaryFiles – O clasă ce se ocupă de gestiunea fișierelor temporare.
Este necesară pentru împărțirea în mai multe fișiere a unor cereri mari de date, pentru a nu intra în
probleme de memorie.
34

3.3.4.1 Request-uri
O cerere, presupunând că a fost completată corect pe partea clientului, trebuie să fie verificată și pe partea
server-ului.
În loc să se verifice în fiecare metodă de fiecare dată validitatea cererii, se poate abstractiza și a se face
referire la o clasă de tipul Request din Laravel.
Următoarele clase de tip Request apar, nu sunt goale și sunt folosite în proiect:
1.ClaimRegisteredRequest – verificarea existenței unui IMEI înregistrat în ultimele 24 ore.
2.StoreClaim – asigură toate câmpurile unei cereri respectă anumite reguli, declarate folosind sintaxă spe-
cială Laravel.
3.3.4.2 Mediul de dezvoltare
Pentru a folosi o aplicație bazată pe Laravel, trebuie să ai configurate anumite servicii, precum tipul de
conexiune la o bază de date, ce sistem de mail folosești sau locație aplicației tale pe internet.
Mulțumită fișierului „.env” , nu mai trebuie a te complica cu setarea variabilelor globale sau a variabilelor
de mediu, acestea vor fi automat preluate în cazul în care nu există variabila de mediu, din acest fișier.
O importantă precizare este necesitatea unei chei din acest fișier, „APP_KEY” , ce trebuie să existe.
Această cheie este folosită într-un algoritm de încriptare pentru a face sesiunea utilizatorului cât mai sigură.
3.4 Excel
Pentru a asigura compatibilitatea cu sistemele folosite de personalul companiei, s-a dorit un ușor acces
pentru rapoartele extrase. S-a decis la începutul dezvoltării folosirii sistemului „.csv”, a valorilor delimitate de
virgulă. Mulțumită suportului nativ a PHP-ului pentru aceste valori, s-a construit rapid o clasă ajutătoare ce
prin intermediul platformei Laravel salvează rapoartele.
Mulțumită pachetului de dezvoltare phpoffice/phpexcel , am putut integra, la finalul construirii modulelor,
un sistem ce salvează direct în formatul Excel. Apăruse, folosind o implementare naivă a algoritmului de salvare
în Excel, o problemă de timp. Consuma din ce în ce mai multe resurse și eram în impas, având următoarele
opțiuni:
• Să-l las așa cum este, dar dacă numărul de linii o să crească, s-ar putea să rămână fără memorie sistemul.
• Să-l optimizez cât de bine pot și să adaug o interfață ce anunță utilizatorul într-un mod interactiv care-i
situația curentă.
Până la urmă am ales să optimizez cât de bine pot, pentru a reduce din complexitatea programului, făcând
următoarele modificări:
1. Majoritatea vectorilor în cadrul aplicației ce interacționează cu sistemele de raportare au fost înlocuite
cuSplFixedArray . Astfel se reduce memoria și se optimizează accesul la elementele vectorului, prin
declararea de la începutul construirii obiectului a dimensiunii vectorului.
2. S-a activa folosirea unei baze de date auxiliare pentru „PhpExcel”, pentru a reduce consumul memorie.
3. Atunci când se trimit informațiile către librăria de „PhpExcel”, se trimite tot vectorul deodată. Înainte,
se trimitea fiecare element, rând cu rând, coloană cu coloană.
4. Împărțirea memoriei ce trebuia gestionată prin apeluri secvențiale și la final concatenarea lor. Această
metodă a fost folosită des în sistemele distribuite – „Map-Reduce”:
(a) Se aplică metoda de calcul dorită informației împărțită în mod egal — „Map” .
(b) Se combină la final toate rezultatele parțiale în cel final — „Reduce” .
Soluția finală astfel se poate încadra în 256MB RAM, pentru un tabel Excel cu peste 33000 linii, iar pentru
sistemul găzduit pe xServers, ce are limita de memorie 128MB, se poate calcula un întreg an.
35

3.4.1 Implementarea platformei de rapoarte Excel
Pentru gestionarea platformei, am construit următoarele clase:
•Facade – Clasă ce conține doar metode statice, ce ajută introducerea unui raport în sistemul de gestiune
a cererilor și despăgubirilor. Se folosește de două „trait”-uri, AdaptorFacade șiOutputFacade , ce conțin
metodele statice pentru a scoate, respectiv a introduce rapoartele din sau în sistem.
De menționat ar fi că în funcție de șablonul dorit, clasa Facade se ocupă de construirea clasei respective,
prin următorul cod:
$adaptorName = 'App\\Excel\\Adaptors\\' . ucfirst(
camel_case($shorthand)
) . 'Adaptor';
return new $adaptorName;
•FileData – Clasă scrisă inițial ce traduce un vector de vectori, unde prima linie reprezintă capul de tabel,
într-un fișier „.csv” sau în ââcazul în care se dorește o reprezentare readable , într-un tabel format din
caractere ASCII.
•FileDataExcelAdaptor – Clasă ce primește ca un constructor o altă clasă FileData , ce traduce atunci
când este folosită ca un șir de date ce reprezintă echivalentul fișierului Excel formatat.
• Directorul Adaptors , ce conține următoarele adaptoare, în funcție de nevoia fișierului de importat
–DailyAdaptor – Importul datelor din fostul principal Excel SpreadSheet. S-a dovedit o provocare
construirea unui algoritm ce ține cont de toate posibilitățile câmpurilor, dar mulțumită clasei ajută-
toareExcelHelper , o dată ce am definitivat datele ce trebuiesc scoase din acest fișier cu operatorii
sistemului, am reușit să trec peste și acest obstacol.
Această clasă construiește și cereri și deciziile asociate cererilor. Se asigură astfel continuitatea
aplicației din punctul de vedere al rapoartelor și existența datelor în cazul în care va fi nevoie de o
căutare în anii anteriori.
–ExcelAdaptor – Interfață implementată de toate adaptoarele.
–ExcelHelper – clasă utilitară ce spune coloana unde se află un text, dat de prima linie a raportului de
introdus. Astfel se putea definitiva o structură aleatoare când vine vorba de organizarea coloanelor,
dar ce mereu va putea fi introdusă în sistem mulțumită căutării după text.
S-a aplicat o normalizare a valorilor numelor coloanelor primei linii a raportului, prin scoatere spațiilor
și a semnelor de punctuație des folosite, dar și transformarea șirului pentru a conține doar litere mari.
–AltexGalaxyAdaptor – Principalul import de rapoarte.
Acesta se folosește exhaustiv de clasa ajutătoare ExcelHelper pentru a asigura datele vitale sunt
introduse corect din raport în aplicație.
–SalesImportAdaptor – Clasă cu rol secundar, ce introduce datele din rapoartele existente până în
momentul actual a vânzărilor produselor.
–OldAdaptor – Clasă cu rol secundar, ce introduce doar IMEI-ul din vechile rapoarte trimise de soluția
anterioară în cadrul cererilor de despăgubire.
• Directorul Outputers , ce conține următoarele rapoarte:
–StatisticsOutputer – Pentru statistici rapide (câte cereri de despăgubire, decizii au fost create în
perioada respectivă de timp.)
–DecisionsOutputer – Pentru rapoartele cu toate deciziile plătite în perioada de timp specificată.
–ProductsOutputer – Pentru numărul de asigurări, grupate în funcție de tipul de asigurare și prețul
ei, în perioada respectivă.
–SalesOutputer – Pentru numărul vânzărilor asigurărilor grupate în funcție de magazinul ce a făcut
vânzarea.
Se mai adaugă și perioada când s-a vândut primul și ultimul produs.
–AbstractDateOutputer – Clasă abstractă ce toate rapoartele momentan „sub-clasează”, pentru că
toate rapoartele sunt delimitate de data de început și sfârșit a raportului.
–ExcelOutputer – Interfața implementată de toate clasele din acest director.
36

–YearlyOutputer , împreună cu clasa suport NegativeSale , scoate un raport detaliat despre produsele
ce încă sunt asigurate, împreună cu posibila cerere de despăgubire asociată.
Momentan trebuie să fie luate la rând toate asocierile rezultante, deoarece nu mai sunt corelate
vânzările de cererile de despăgubire și există un algoritm euristic în locul lui.
–MonthlyOutputer – Clasă ce adaugă raportului generat de
YearlyOutputer câmpul lunii.
37

Capitolul 4
Manual de utilizare
Se vor folosi următoarele denumiri și presupuneri:
1.Utilizatorul – Cel ce gestionează cererile de despăgubire și folosește interfața de administrare.
2.Clientul – Cel ce dorește înlocuirea sau repararea produsului.
3.Calea implicită a serverului -https://fandu.info
Orice cale scrisă nu va conține adresa, ci doar calea relativă.
Exemplu: calea pentru a accesa interfața de administrare, se găsește la:
/admin/
4. Orice câmp cu steluță și / sau roșu trebuie completat înainte de a se putea continua mai departe.
4.1 Înregistrarea unei cereri
Pentru a înregistra o cerere cât mai ușor și fără probleme, aplicația se împarte modular în mai multe categorii,
observabile în figurile 4.2(a) ,4.2(b) ,4.2(d) ,4.2(e) .
Cea mai mare categorie și cea mai importantă este despre informațiile generale legate de cererea de despă-
gubire, ce se poate observa în figura 4.1 .
După ce vor fi completate câmpurile obligatorii, înainte de a se trimite cererea, clientul este avertizat cu un
dialog:
Asigurați-vă că ați completat formularul corespuzător!
Următoarea solicitare pentru cererea curentă poate fi
înregistrată abia în următorul interval de 24 de ore.
După ce continuă utilizatorul, se va trimite un mail către client și utilizatorii sistemului, pentru a certifica
creării unei noi cereri de despăgubire în sistem, cu toate datele completate.
În figura 4.3 se poate observa structura mesajului.
În același timp, utilizatorul este redirecționat către pagina de încărcare poze, vizibilă în figura 4.4 .
4.2 Secțiunea de mesaje din cadrul cererilor de despăgubire
În caz de probleme sau nelămuriri, în cadrul link-ului primit pe mail, o dată ce se navighează la pagina
respectivă, se poate apăsa butonul „Messages” pentru a trimite într-un dialog mesaje de la client la utilizator,
cum se poate observa în figurile 4.5(a) ,4.5(b) ,4.5(c) .
De asemenea, același sistem poate fi folosit și de utilizator, pentru a trimite un mesaj clientului, fiecare fiind
anunțat pe mail în cazul unui nou mesaj.
38

Figura 4.1: Informații generale
39

(a) Informații despre cine a provocat avarierea produ-
sului
(b) Informații despre cererea de despăgubire
(c) Descrierea evenimentelor
(d) Problemele dispozitivului
(e) A vertizare încărcare poze
Figura 4.2: Câmpurile de completat în cererea de despăgubire
40

Figura 4.3: Mesajul trimis de sistem către client și utilizatorii sistemului
41

Figura 4.4: F ormularul de încărcare a pozelor
42

(a) Email trimis când clientul trimite un mesaj
(b) Email trimis când utilizatorul trimite un mesaj
(c) Interfața de messages, împreună cu istoricul mesajelor
Figura 4.5: Interacțiunea mesajelor de mesaje
43

Figura 4.6: Pagina de înregistrare pentru interfața de administrare
4.3 Interfața de administrare
Interfața de administrare nu poate fi accesată dacă nu se cunoaște ori calea, ori dacă nu se navighează din
cadrul vizualizării cererii (pentru client, acest pas reprezintă încărcarea pozelor) pe pagina principală.
Pagina principală a interfeței de administrare se găsește la:
/admin/
În momentul în care utilizatorul navighează la orice parte a aplicației de administrare și nu este înregistrat,
pagina apare ca în figura 4.6 .
După ce utilizatorul introduce email-ul și parola sa corect în sistem, sistemul va naviga la pagina ce utiliza-
torul încerca să acceseze.
Pagina principală a interfeței de administrare arată ca în figura 4.7 . În cazul oricărei probleme, sunt lăsate
datele mele de contact pentru a le remedia cât mai rapid. De aici, utilizatorul poate introduce rapid un număr
de cerere de despăgubire folosind câmpul din bara de navigație.
În pagina principală, se găsesc două grafice:
1. Primul se referă la cererile de despăgubire noi în această săptămână, raportat la numărul lor pe luna
respectivă.
2. Al doilea se referă la numărul total de decizii terminate, active și refuzate.
Numerele folosite în aceste grafice apar atunci când se navighează cu cursorul deasupra lor.
Bara de navigație conține toate modulele aplicației.
4.3.1 Modulul de administrare a cererilor de despăgubire
Pe pagina principală a modului se vizualizează ultimele 100 cereri de despăgubire în funcție data sosirii lor
în sistem. Fiecare cerere are patru butoane:
1.Decide – pentru a naviga rapid la decizia cererii de despăgubire. Se va crea o decizie în cazul în care nu
există. Dacă nu se poate construi automat decizia în funcție de numărul facturii, utilizatorul va fi rugat
de a lega manual decizia de o vânzare sau de a construi el manual vânzarea în cauza lipsei acesteia.
44

Figura 4.7: Pagina principală a interfeței de administrare
2.View – vizualizarea cererii de despăgubire scrise de client.
3.Edit – modificarea cererii de despăgubire
4.Delete – iconița de gunoi reprezintă ascunderea cererii din interfața principală.
Pentru a ajuta utilizatorul să identifice mai ușor starea cererilor, se reprezintă fiecare linie din tabel cu un
sistem de culori, regăsit deasupra capului de tabel. Dacă se apasă un element din acesta, se filtrează cererile de
pe pagina curentă după elementul respectiv.
Figura 4.8(a) reprezintă un exemplu a datelor din tabel, figura 4.8(b) reprezintă cererile filtrate după „Re-
pairment” (reparare), figura 4.8(c) arată sistemul de căutare în acțiune, iar figura 4.8(d) prezintă o cerere cu
informații adiționale.
4.3.1.1 Vizualizarea și modificarea cererilor
Pentru a modifica cererea, este obligatorie o decizie. Utilizatorul nu poate salva niciun câmp, după cum se
vede în figura 4.9(a) .
După ce se adaugă decizia respectivă, utilizatorul poate scrie un mic detaliu despre cerere, a-i modifica starea,
ce implicit modifică și starea deciziei (câmpul „Resolution”) și de a specifica când să-i aducă aminte aplicația
despre cerere – „Reminder” – pentru a putea fi actualizate. Se pot observa aceste câmpuri în figura 4.9(b) .
4.3.1.2 Aducerea aminte a cererilor
Pentru că clienții au o perioadă de grație pentru a încărca pozele și pentru că multă lume revine ulterior cu
ele, sistemul în meniul principal are două butoane:
1.Today – Cererile ce trebuiesc actualizate exclusiv azi.
2.Past Due – Cererile ce trebuiau actualizate, aranjate după când trebuiau actualizate.
Ambele secțiuni arată precum figura 4.10 . S-a adăugat și butonul de șterge automată a câmpului „Reminder” .
45

(a) Structura culorilor
(b) Filtrarea prin culori
(c) Căutarea cererilor
(d) O cerere cu informații adiționale
Figura 4.8: Interfața administrării cererilor
46

(a) Fără o decizie – imposibil de modificat
(b) Cu decizie – ușor de modificat
Figura 4.9: Modificarea unei cereri
Figura 4.10: Sistemul de aducere aminte a cererilor de despăgubire
47

(a) Sistemul de introducere a datelor
(b) Mesaj trimis utilizatori-
lor sistemului în momentul
adăugării datelor în sistem
Figura 4.11: Introducerea datelor
(a) Exemplu la introducerea cu succes a datelor
(b) Exemplu la încărcarea unui duplicat
Figura 4.12: Rezultate posibile la introducerea datelor în sistem
4.3.2 Modulul introducerii datelor în sistem
Introducerea datelor în sistem se face prin butonul „Import” din bara de meniu. Apar astfel două panouri,
conform figurii 4.11(a) :
1.Weekly sale import – Introducerea raportului principal aplicației. Se va trimite email de confirmare
utilizatorilor aplicației, precum cel din 4.11(b) .
2.Custom imports – Introducerea datelor dinaintea aplicării sistemului în funcțiune pentru compania de
asigurări.
Se vor dezvolta propriile șabloane, ajustate nevoilor fiecărei companii ce folosește acest sistem de gestiune.
După momentul încărcării, utilizatorul trebuie să aștepte finalizarea introducerii datelor.
Sistemul are grijă în cazul introducerii unui fișier duplicat, precum se vede în figura 4.12(b) , pentru că s-a
încercat re-introducerea, din greșeală, aceluiași raport introdus cu succes în figura 4.12(a) .
4.3.3 Sales
search coloane, access rapid buton de remove / remove all logic
4.3.3.1 View
poti sa adaugi product poti sa stergi product poti sa adaugi assurance poti sa stergi assurance
48

Figura 4.13: TEMP
4.3.4 Decisions
quick search detailed search de ce poti sa stergi – pentru ca daca nu ai asociat sale-ul corect, poti sa dai
undo fara sa sufere nimic baza de date.
4.3.4.1 View
claim / messages / add old decision edit claim in urma analytics campurile explicate calculatorul
4.3.5 Reports
type of export (deprecated csv / excel) date start / end progress bar metadata when loading – especially
yearly reports chunking
49

Figura 4.14: TEMP
Figura 4.15: TEMP
50

Figura 4.16: TEMP
51

Figura 4.17: TEMP
Figura 4.18: TEMP
52

Figura 4.19: TEMP
53

Figura 4.20: TEMP
54

Figura 4.21: TEMP
Figura 4.22: TEMP
Figura 4.23: TEMP
55

Figura 4.24: TEMP
Figura 4.25: TEMP
56

Figura 4.26: TEMP
Figura 4.27: TEMP
Figura 4.28: TEMP
57

Figura 4.29: TEMP
Figura 4.30: TEMP
58

Concluzie
Business Continuity Plan
T este automate
În lunile care vin, înainte de mă ocupa de sistemul modular de rapoarte, o să doresc să petrec o bună
perioadă scriind teste automate.
T estele automate, mai ales „testele unitare”, sunt o metodă de verificare a modulelor individuale, asocierilor
datelor, procedurilor de modificare a datelor. [ 42]
Acestea pornesc de la premiza că un modul detașat de modificările externe, odată testat, se va comporta
corect și atunci când va fi folosit în conjuncție cu alte module, ce la rândul lor vor fi testate. Astfel, de la cele
mai mici module, se asigură comportamentul corect al aplicației. De la nivelul microscopic de funcție, până la
nivelul macroscopic de funcționalitate.
Doresc să extind aplicația să se folosească de codul gata scris de cadrul Laravel și de a obliga aplicația
găzduită pe mediul de testare să se asigure că fiecare nouă linie de cod nu strică funcționalitatea deja existentă.
Acest principiu se mai numește și „integrare continuă”, propusă prima oară de Grady Booch în 1991 [ 43] și
folosită de majoritatea dezvoltatorilor moderni.
Modularizarea tabelelor
4.3.6 Modificări necesare asupra structurii bazei de date
Sistem modular de rapoarte
59

Bibliografie
[1] F andu Holdings Ltd. Fandu.UK . 2015. url :http://www.fandu.uk/claims (visited on 06/14/2017).
[2] W arranty Solutions. Raportul avariilor . 2015. url :http://wsgp.co.uk/claims/ (visited on 06/14/2017).
[3] Altex Romania S.R.L. Regulament Mobile Protect .url :https://mediagalaxy.ro/regulament-mobile-
protect (visited on 06/14/2017).
[4] S.C. Clax T elecom SRL. Hosting | Servere dedicate | VPS – xServers .url :https://www.xservers.ro/
(visited on 06/14/2017).
[5] Amazon. Amazon Web Services S3 .url :https://aws.amazon.com/s3/ (visited on 06/14/2017).
[6] IDRIX. VeraCrypt Free Open source disk encryption with strong security for the Paranoid .url :https:
//www.veracrypt.fr/en/Home.html (visited on 06/14/2017).
[7] T aylor Otwell. Laravel – The PHP Framework For Web Artisans .url :https://laravel.com/ (visited
on 06/14/2017).
[8] T aylor Otwell. Taylor Otwell on Twitter: ”Average cyclomatic complexity per method .url :https://
twitter.com/taylorotwell/status/817494232541839367 (visited on 01/07/2017).
[9] HotF rameworks. Web framework rankings .url :https://hotframeworks.com/ (visited on 06/14/2017).
[10] J. R. Okin. The Information Revolution . Ed. Ironbound Press, 2005. isbn : 0-9763857-4-0.
[11] Anne Nelson and William Nelson. Building Electronic Commerce with Web-Driven Databases with Cdrom .
1st. Boston, MA, USA: Addison-W esley Longman Publishing Co., Inc., 2001. isbn : 020174130X.
[12] Rasmus Lerdorf. Rasmus Lerdorf, Senior Technical Yahoo: PHP, Behind the Mic .url :https://web.
archive.org/web/20130728125152/http://itc.conversationsnetwork.org/shows/detail58.html
(visited on 11/19/2003).
[13] The PHP Group. PHP: Supported Versions .url :http://php.net/supported-versions.php .
[14] Martin Bean. Laravel 5 Essentials . books.google.com, 2015. isbn : 978-1785283017.
[15] F rank Buschmann. Pattern-Oriented Software Architecture . V olume 1. Wiley , 1996. isbn : 978-0471958697.
[16] Adam Engebretson. About The Collective .url :https://laravelcollective.com/about (visited on
06/14/2017).
[17] Laravel Collective. Forms & HTML .url :https://laravelcollective.com/docs/master/html (visited
on 06/14/2017).
[18] T orsten Stanienda and Douglas Barry . “Solving the Java Object Storage Problem” . In: Computer 31
(1998), pp. 33–40. issn : 0018-9162. doi :doi.ieeecomputersociety.org/10.1109/2.730734 .
[19] M. F owler. Patterns of Enterprise Application Architecture . A Martin F owler signature book. Addison-
W esley , 2003. isbn : 9780321127426. url :https://books.google.ro/books?id=FyWZt5DdvFkC .
[20] PHP F ramework Interop Group. PSR-1: Basic Coding Standard – PHP-FIG .url :http://www.php-
fig.org/psr/psr-1/ (visited on 06/14/2017).
[21] Michael Widenius and Davis Axmark. Mysql Reference Manual . Ed. by Paul DuBois. 1st. Sebastopol, CA,
USA: O’Reilly & Associates, Inc., 2002. isbn : 0596002653.
[22] Oracle. Oracle Announces the Acquisition of Open Source Software Company, Innobase . Oct. 7, 2005. url :
http://www.oracle.com/us/corporate/press/016679_EN (visited on 09/16/2012).
[23] Carlos Coronel and Steven Morris. Database Systems: Design, Implementation, & Management . 11th ed.
Course T echnology , F eb. 2014. isbn : 9781285196145.
[24] Marc Delisle. Mastering phpMyAdmin 3.4 for Effective MySQL Management . Packt Publishing, 2012.
isbn : 9781849517782.
[25] Bryan O’Sullivan. Mercurial:theDefinitiveGuide . Sebastopol: O’Reilly Media, Inc., 2009. isbn : 9780596555474.
60

[26] Kathryn D. Scopatz Anthony; Huff. Effective Computation in Physics . O’Reilly Media, Inc., 2015. isbn :
9781491901595.
[27] Alex William. GitHub Pours Energies into Enterprise. Raises $100 Million From Power VC Andreessen
Horowitz .url :http://techcrunch.com/2012/07/09/github-pours-energies-into-enterprise-
raises-100-million-from-power-vc-andreesen-horowitz/ (visited on 07/09/2012).
[28] Rolf Oppliger. SSL and Tls: Theory and Practice (Artech House Information Security and Privacy) .
Artech House, Aug. 2009. isbn : 9781596934474.
[29] Chromium. 685826 – Restrict the set of domains for WoSign/StartCom certificates . Jan. 26, 2017. url :
https://bugs.chromium.org/p/chromium/issues/detail?id=685826 (visited on 04/28/2017).
[30] Jon Duckett. JavaScript & jQuery : interactive front-end web development . Indianapolis, IN: Wiley , 2014.
isbn : 1118531647.
[31] Eric Sarrion. JQuery UI . Sebastopol, Calif: O’Reilly , 2012. isbn : 1449316999.
[32] 1000hz. Bootstrap Validator .url :http://1000hz.github.io/bootstrap-validator/ (visited on
06/14/2017).
[33] Timothy Moran. Mastering KnockoutJS : use and extend Knockout to deliver feature-rich, modern web
applications . Birmingham, UK: Packt Publishing, 2014. isbn : 1783981008.
[34] knockoutjs.com. Knockout .url :http://knockoutjs.com/ (visited on 06/14/2017).
[35] F eras Alhlou. Google analytics breakthrough : from zero to business impact . Hoboken, New Jersey: John
Wiley & Sons, Inc, 2016. isbn : 1119144019.
[36] Jordi Boggiano Nils Adermann and many community contributions. Composer .url :https://getcomposer.
org/ (visited on 06/14/2017).
[37] Isaac Z. Schlueter. Forget CommonJS. It’s dead. **We are server side JavaScript.** . Mar. 25, 2013. url :
https://github.com/joyent/node/issues/5132#issuecomment-15432598 (visited on 06/14/2017).
[38] Stefan Kottwitz. LaTeX beginner’s guide . Birmingham, UK: Packt, 2011. isbn : 1847199860.
[39] Robert Martin. Agile software development, principles, patterns, and practices . Harlow, Essex: Pearson,
2014. isbn : 1292025948.
[40] T aylor Otwell. Controllers – Laravel – The PHP Framework For Web Artisans .url :https://laravel.
com/docs/5.3/controllers (visited on 06/14/2017).
[41] T aylor Otwell. Eloquent: Relationships – Laravel – The PHP Framework For Web Artisans .url :https:
//laravel.com/docs/5.3/eloquent-relationships (visited on 06/14/2017).
[42] Dorota Huizinga. Automated defect prevention : best practices in software management . Hoboken, N.J:
Wiley-Interscience IEEE Computer Society , 2007. isbn : 0-470-04212-5.
[43] Grady Booch. Object oriented design with applications . Redwood City , Calif: Benjamin/Cummings Pub.
Co, 1991. isbn : 9780805300918.
61