Șef lucr. dr. ing. Marius Muji Timar Radu [632012]

1

UNIVERSITATEA DE MEDICINĂ, FARMACIE ȘTIINȚE ȘI TEHNOLOGIE DIN TÎRGU –
MUREȘ
FACULTATEA DE INGINERIE
SPECIALIZAREA: AUTOMATICĂ ȘI INFORMATICĂ APLICATĂ

PROIECT DE DIPLOMĂ

Sistem informatic cu baze de date

Îndrumător științific: Absolvent: [anonimizat]

2019

2

Cuprins

3

CAPITOLUL 1. INTRODUCERE

1.1 Privire de ansamblu
Încă de la apariț ia internetului acesta a fost un fenomen care a schimbat lumea prin a creea un
confort în viaț a de zi cu zi ne mai fiind necesar ă deplasarea p entru a face o cerere, pentru a comanda
un produs la tine acasă, pentru a rezerva o loca ție de vacanță sau pur și simplu pentru a ț ine leg atura
cu persoanele apropiate. Încet, î ncet de -a lungul anilor tot mai multe companii și -au extins raza de
dezvoltare î n lumea int ernetului pentru simplul fapt că cererea de confort este foarte mare.
Deși a fost un proces lent, companiile, în mod gradual, și -au extins raza de dezvolare în lumea
internetului și au început să investească întrucât noul nivel de confort creea o cerere din ce in ce
mai mare, revolutionând astfel modul de funcționare a fiecărui do meniu economic.

1.2 Scopul lucră rii
Se propune r ealizarea unei platforme web avâ nd ca obiect promovarea/publicarea și rezervarea
spațiilor sportive . Utilizatorii site -ului vor fi în esență administratorii acestor spaț ii, respectiv
client ela (dornică să facă rezervă ri). Aplicația deține o interfață accesibilă oricărui ultilizator pentru
căutarea unui spaț iu, iar rezervarea acestuia se face pe baza unu i cont. Pentru a publica un spaț iu
este nevoie de un cont de administrator de spațiu iar apoi după completarea unui formular spațiul
se poate da î nspre reze rvare. Pentru realizarea aplicației au fost folosite cunoștinț e acumulate de -a
ungul an ilor de studiu, in special cunoș tinte d e baze de date, tehnologii web ș i prog ramare. Baza
de date este creată în sistemul relațional de baze de date MySQL, interfața este realizată î n HTML
cu ajutorul limbajului de scripting Javascript, iar comunicarea dintre interfață și baze de date,
precum ș i logica de calcul este realizată cu ajutorul limbajului de programare PHP.

4
1.3 Definiții
– Partea Frontend a aplicației este formată din limbajul HTML și Javascript și constituie
interfața platformei.
– Partea Backend a aplicației este formată din limbajul PHP și reprezintă comunicarea dintre
interfață și baza de date. Aceasta este în esență creierul aplicației pentru ca toată logica de
publicare și rezervare a unui spațiu se realizează in această parte pe baza unor date provenite
din frontend.

1.4 Structura lucrari
Conținutul lucrării este împărțit în 4 capitole, fiecare capitol fiind împ ărțit în mai multe
subcapitole :
– Primul capitol este format din introducere unde este prezentat scopul și structura lucrării
precum și niște definiții ale unor termeni cheie.
– Al doilea capitol reprezintă faza de analiză a cerințelor și reprezentarea cerințe lor prin
diagrame .
– Al treilea capitol cuprinde proiectarea aplicației utilizând diferite diagrame cu definiții și
explicația lor.
– În al patrulea capitol se trece la implementarea propriu -zisă a lucrării, fiind împarțită în
implementarea părții de frontend și a părții de backend.

5

CAPITOLUL 2. ANALIZA ȘI CERINȚELE SISTEMULUI

Analiza cerințelor reprezintă faza ciclului de viață al unei aplicații în care se determină cum
va funcționa sistemul.
Aplicația dezvoltată este o platformă de rezervări online de spații sportiv e. Platforma se va
ocupa de rezervarea acestor spații și de afișarea unor statistici pe baza rezervarilor deja
efectuate. Publicarea spațiilor se va face de către contul de administ rator de spații și se va realiza
în urma completării unui formular de publicare care v -a conține informații despre compania
care dorește sa ofere spre rezervare spațiul, detalii despre spațiu precum tipul de sport pentru
care acest spațiu este amenajat, ti pul de suprafață al terenului/sălii și detalii despre facilitățile
de care dispune această locație precum dușuri, echipament, etc.

2.1 DIAGRAMA CAZURILOR DE UTILIZARE (USE CASE DIAGRAM )

Diagrama use case reprezintă interacțiunile utilizatorilor cu un sistem. În această etapă nu
sunt luate în considerare detaliile tehnice prin care o să fie realizate aceste interacțiuni. O
diagramă de acest tip se mai ocupă și de identificarea diferitelor tipuri de utilizatori (actori)
dintr -un sistem. Deoarece acest ti p de diagramă are ca scop privirea de ansamblu a funcționării
aplicației, ea poate fi o metodă eficientă prin a comunica admnistratorilor felul în care va
funcționa aplicația.

Componentele diagramei

Actorul este persoana care va interacționa cu aplicația. În cadrul sistemului prezentat el
poate fi clientul, cel care are posibilitatea de a rezerva un spațiu, și administratorul, cel care
poate publica un spațiu. În standardul de modelare nu este permisă intera cțiunea între doi actori,
numai între actori și sistem. Pentru identificarea rolurilor diferite trebuie luat în considerare
cine va folosi sistemul, cine va administra sistemul și ce alte componente externe vor
interacționa cu sistemul.

6
Reprezentarea acto rilor

Diagramele Use case reprezintă descrierea unor serii de acțiuni benefice actorului. Actorul
este reprezentat grafic printr -o persoana (Fig. 2.1.).
În standardul de modelare UML este specificat că o acțiune trebuie sa fie finalizată pentru a fi
valid ă. Acțiunea este consideră finalizată atunci când intră într-o fază ce nu necesită
interacțiunea utilizatorului și se poate reîncepe acțiunea.

Figura 2.1. Reprezentarea grafică a actorilor

Reprezentarea cazului de utilizare

Se reprezintă grafic printr -o elipsă (Fig. 2.2). Fiecare acțiune are un nume care definește
acțiunea. Pentru identificarea unei acțiuni este necesară cunoașterea rolului utilizatorului căruia ii
atribuim acțiunea.
Pentru identificarea cazurilor de utilizare trebuie luate în considerare funcționalitățile care
trebuie accesate de acesta, dacă utilizatorul are nevoie sa introducă sau să modifica date și dacă
funcționalitatea va rezulta într -o experiență fluidă pentru acesta.
Înregistrare /
Logare

Figura 2.2 Reprezentarea grafică a cazului de utilizare

7
Tipuri de relații

Relațiile reprezintă modul de comunicare dintre componentele diagramei, pot exista 3
feluri : de asociere, de generalizare și de independență.

Relația de asociere

Relția de asociere definește interacțiunile dintre actori și cazuri de utilizare. Acest tip de relție
are niște constrângeri :
– Un actor trebuie să aibă măcar o asociere cu un caz de utilizare
– Un actor poate fi asociat cu mai multe cazuri de utilizare
– Pot exista mai mulți actori asociați cu un singur caz de utilizare

Înregistrare /
Logare

Figura 2.3. Reprezentarea grafică a relației de asociere

Relația de generalizare

Relația de generalizare se referă la o relație între actori. Un actor poate să moștenească rolul
altui actor.

Figura 2.4. Reprezentarea grafică a relației de generalizare

8
Detalierea diagramei cazurilor de utilizare
Figura 2.5 descrie cazurile de utilizare ale aplicației.

Înregistrare /
Logare
Navigare folosind
motorul de
căutare
Rezervarea unui spațiu
Client
Administrator
Acceptarea /Refuzarea
unei rezervări
Publicarea unui spațiu
Acces la statistici
privind rezervările finalizate
Vizualizare status
rezervare

Figura 2.5. Diagrama cazurilor de iutilizare (Use case diagram)

Actorii prezenți în diagramă sunt clientul sau cel care vizitează platforma în căutarea unui spațiu
sportiv de închiriat și administratorul de spațiu, cel care dorește să publice spațiul spo rtiv cu ajutorul
platformei. Interacțiunea cu platforma se face în felul următor :
– Clientul și administratorul au posibilitatea de a se înregistra si loga pe platformă .
– Clientul și administratorul au posibilitatea de a naviga printre produsele existente în
platformă folosind motorul de căutare.
– Clientul are posibilitatea plasării unei rezervări completând un formular care mai apoi
așteaptă confirmarea de către administratorul spațiului.
– Clientul poate urmări statusul rezervării.
– Administratorul are posibilitatea de a publica un spațiu în cadrul platformei.
– Administratorul are dreptul și posibilitatea de a accepta sau refuza o rezervare.
– Admininistratorul are access la date și statistici privind rezervările finalizate.

9
2.2 DIAGRAMA FLUXULUI DE DATE ( DATA FLOW DIAGRAM )

O diagram ă de flux de date descrie fluxul informațiilor dintr -un sistem pentru anumite
procese. Diagramele de flux de date pot simple sau pe mai multe nivele, depinde de nivelul de
complexitate.

Componentele diagramei

Entitatea extern ă reprezintă un sistem extern care comunică cu sistemul descris în
diagramă. Deobicei se plasează la marginea diagramei și reprezintă sursa și destinația informației

Client

Figura 2.6. Reprezentarea grafică a entității externe

Procesul este o acțiune ce se exectută asupra unui set de date. Acesta prelucrează datele prin diverse
metode și poate trimite mai departe datele prelucrate. Procesele se numerotează pentru a fi mai ușor sugerată
ordine de execuție a acestora.

1.0
Cautare și vizualizare spații
publicate

Figura 2.7. Reprezentarea grafică a procesului

10
Stocarea Datelor se reprezintă prin blocul din figura 2.8. și reprezintă stocarea într -o bază de date
sau a unui fișier.

D1: Spații publicate

Figura 2.8. Reprezentarea grafică a stocării de date

Detalierea Diagramei de flux de date

Client
Administrator1.0
Cautare și vizualizare spații
publicate
2.0
Procesare rezervareCăutare
Listare
Cerere rezervareDate rezervareD1: Spații publicate Query produs
Query rezultat
D2: RezervareQuery rezervare
Query rezultat
3.0
Proces de acceptare /refuzare
rezervare Query rezervare
Query raspunsQuery cerere

Figura 2.9. Diagrama de flux de date

În cazul diagramei prezente în figura 2.9 entitățile externe sunt aceeași ca și actorii de la
diagrama Use Case și anume Clientul și Administratorul. Acțiunea începe cu clientul care, folosind
motorul de căutare, îș i caută spațiul dorit în procesul 1 primind înapoi o listă de spații disponibile
în funcție de criteriile de căutare alese din baza de date, care este reprezentată cu D1. Mai apoi

11
acesta face o cerere de rezervare în procesul 2 care stochează detaliile rezervării în D2 ca mai apoi
acestea să fie acceptate sau refuzate de către administrator prin procesul 3.
Procesul 1 este prima interacțiune a clientului cu produsul (spațiu l sportiv). În cadrul acestui
proces, clientul alege din cele 3 seturi de parametrii de căutare ( oraș, sport și suprafață ) și atunci
începe procesul de căutare a tuturor spațiilor care îndeplinesc parametrii de căutare. Această căutare
returnează o listă din care clientul poate alege una pentru a continua cu procesul 2.
Procesul 2 r eprezintă procesul de rezervare care consta in completarea unui formular de
către utilizatorul client care mai apoi, la finalizare, va fi trimis către frontend, procesat și sto cat în
baza de date in tabela de rezervări .
Procesul 3 începe după ce se face o rezervare de către client. Spre deosebire de primele
două procese, care aveau interacțiune cu clientul, acesta are interacțiune cu administratorul de
spații. Acest proces decide dacă rezervarea creată de către client este în regulă pentru administrator
și acesta are posibilitatea de a o accepta sau refuza.

12
CAPITOLUL 3. PROIECTAREA APLICAȚIEI

În această etapă se realizează prezentarea aplicație. În etapa anterioară au fost identificate,
analizate și structurate cerințele sistemului, în această fază se pune accentul pe a legerea arhitecturii
sistemului . Capitolul este împărțit în două părți: proiectarea bazei de date și proiectarea aplicației
propriu zise .
O bază de date este o colecție de date care permite operații de inserare, modificare,
interogare și ștergere a datelor.

3.1 PROIECTAREA BAZEI DE DATE

Reprezintă organizarea datelor după un model de bază de date. Cel ce proiectează baza de
date decide ce informații vor fi stocate în baza de date, decide forma în care acestea vor fi stocate
și decide relațiile dintre aceste tabele. Pentru aceasta aplicație am ales modelul de baze de date
relațional care permite comunicarea între entități.

3.1.1 Identificarea entităților și a atributelor
Enitățile reprezintă obiecte reale reprezentate în baza de date. Există două tipuri de entități :
slabe și puternice. Cele puternice pot exista fără dependențe iar cele slabe depind de o altă entitate.
Entitățile sunt reprezentate în formă de dreptiunghi și denumirea lor este un substantiv.

13

Products
product _id PK
name
description
surface _id FK
user _id FK
city_id FK
3.1 Reprezentarea grafică a unei entități

Entitățile pot avea un identificator unic. Acesta poate fi o cheie primară sau cheie primară
compusă. Denumirea unei chei primare simple este deobicei “Id”, iar cheia compus ă este formată
din mai multe câmpuri care determină unicitatea entității. Cheia pri mară se notează cu „PK ” și vine
din engleză de la denumirea de “Primary Key” .
Pe lângă cheia primară, entitatea poat e avea alte două chei :
– Chei străine ( FK = Foreign Key) . Aceste chei sunt cheile primare ale altor entități care cu
ajutor unei relații fac legătura dintre cele două entități. De exemplu entitatea produsului
reprezentată în figura 3.1 are ca și chei străine surface_id, user_id și ciy_id ceea ce înseamnă
ca are o legătură relațională cu tabelele „Surfaces ”, “Users” și „Cities”.
– Chei alternative (AK = Alternative Key). Aceste chei, la fel ca si cheile primare, definesc
unicitatea unei entități dar apar în același timp cu cheile primare.

14
3.1.2 Identificarea relațiilor dintre entități

Entitățile pot avea relații între ele. După deciderea elementelor care vor fi entități se decid
relațiile dintre acestea. Înțelegerea elementelor care vor fi entități și identificarea relațiilor dintre
acestea duce la implementarea fizică a bazei de date. Pentru implementarea relațiilor s e folosesc
cheile străine, acestea făcând legătura dintre două entități.
Cardinaliatea relațiilor reprezintă numărul minim, respectiv maxim al instanțelor entităților
care participă la o relație (gradul de relație). Conform Database Modeling and Design1, gradul de
relație reprezintă ”numărul de entități asociate într -o relație”. De regulă sunt numerotate cu numere
egale sau mai mari ca 0. Pentru reprezentarea unor cardinalități maxime variabile, de regulă se
folosesc literele N și M. Un alt tip de a reprez enta cardinalitatea relațiilor sunt niște simboluri
speciale.
Tipuri de relații

One-to-one ( 1 :1 ) în acest caz pentru o entitate există un singur alt tip de entitate.
Product Product details
product _id FK PK product _id FK PK

Figura 3.2 Relația One -to-one

1 T. Teorey, S. Lightstone, T. Nadeau, H.V. Jagadish, ”Database Model and Design (5th Edition)”, 2011 – pagina 30

15

One-to-many ( 1:n ) o entitate poate avea mai multe instanțe ale altei entități.
Products Price Options
product _id PK
name
description
surface _id FK
user _id FK
city_id FKprice _option _id PK
name
product _id FK AK
start _time AK
end_time
value

Figura 3.3 Relația One -to-many

3.1.3 Diagrama de entități relații

După identificarea entităților și a relațiilor dintre acestea se trece la implementarea
diagramei de entități relații. În următoarea etapă se va prezenta diagrama de entități relații ale
aplicației după care entitățile ș i relațiile dintre ele vor fi descrise în detaliu.
Entitatea principală este Products care reprezintă spațiul sportiv. Acesta are o cheie primară
“product_id”, un nume, o descriere și trei chei străine care fac legătura cu tabelele “Surfaces”,
“Users”, r espectiv “Cities”.

16

Products
product _id PK
name
description
surface _id FK
user _id FK
city_id FK
Figura 3.4 Entitatea Products

Aceaste 3 chei străine fac legătura cu următoarele 3 entități :
– Surfaces . Este entitatea care definește tipul materialului din care este făcut spațiul sporti,
de exemplu gazon, zgură etc. Relația dintre aceste 2 entități este o rela ție one-to-many
pentr u că un spațiu sportiv poate avea doar un singur tip de suprafață dar o suprafață poate
să se regăsească la mai multe spații.

17

Surfaces
surface _id PK
name
Figura 3.5 Entitatea Surfaces

– Users . Este entitatea care definește utilizatorul platformei. Acesta are ca și cheie alternativă
email -ul deoarece acest email trebuie sa decidă unicitatea unui utilizator întrucât acesta nu
are voie să se înregistreze pe platformă cu același email mai mult de o singură dată. Pe
lângă cheia alternativă acesta mai are și o cheie străină și anume role_id care face legătura
cu entitatea Roles și definește natura contului de utilizator : client sau administrator.
Relația dintre entitatea Users și Products este de tipul one-to-many, adică un User poate
avea mai multe produse/spații sportive care pot fi publicate dar un spațiu poate fi deținut de un
singur utilizator .
Relația dintre entitatea Users și entitatea Roles este tot de tipul one -to-many, adică un user
poate avea un singur rol dar un rol poate exista la mai mulți utilizatori.

18

Users
Rolesuser _id PK
first_name
last_name
password
email AK
role_id FKrole_id PK
descriptionrole_name AK
Figura 3.6 Entitatea Users și entitatea Roles în legătură one -to-many

– Cities. Este entitatea ce definește locația produsului. Acesta este într -o relație one-to-many
cu entitatea Products, adică un produs poate avea o singură locație dar o locație poate fi
atribuită la mai multe locații.

Pe langă aceste entități, o altă entitate principală este Bookings. Aceasta se referă la rezervările
care un utilizator client le face pe un anumit produs. Pe langă entitățile prezentate se mai regăsesc
câteva entități secundare precum Reviews, care stochează feedbackul pe care un client are dreptul
de a-l returna în urma finalizării unei rezervări, și Favourites care stoch ează toate produsele marcate
de către un utilizator ca fiind favorite.

19

Favourites Products
Reviews
Price Options
Users
RolesCities
Sports
Facilities
Surfaces
Bookings
StatusesProducts Sports
Products Facilitiesproduct _id FK PK
user _id FK PKproduct _id PK
name
description
surface _id FK
user _id FK
city_id FKproduct _id FK PK
title
descriptionuser _id FK PK
created _at PK
star_ratingproduct _id FK PK
start _time PK
end_time
value
user _id PK
first_name
last_name
password
email AK
role_id FKrole_id PK
descriptionrole_name AKcity_id PK
name
sport _id PK
name
facility _id PK
name
surface _id PK
name
booking _id PK
product _id FK AK
user _id FK
end_timestart _time AK
status _id FK
status _id PK
status _name AKsport _id PK
product _id PK
facility _id PK
name

Figura 3. 7 Diagrama relational ă cu entități a bazei de date

20

3.2 PROIECTAREA APLICAȚIEI
După proiectarea bazei de date se poate trece la proiectarea aplicației. În faza aceasta se
descrie comportamenul aplicației și comportamentul entităților prin diagramele de modelare UML.
Unified modeling language (UML) este un limbaj standardizat de mod elare vizuală pentru
a proiecta și analiza sisteme informatice.

3.2.1 Diagrama de activitate

Este o diagramă importantă în UML pentru a descrie aspectele dinamice ale unui sistem.
Această diagramă reprezintă fluxul de activitate din aplicație.
Componen tele diagramei de activitate sunt :
– Starea inițială reprezentată de un cerc albastru , semnifică începutul procesului.
Accesare website

Figura 3. 8 Reprezentarea grafică a stării inițiale
– Starea finală reprezentată printr -un cerc gri înconjurat de un cerc alb.

Figura 3. 9 Reprezentarea grafică a stării finale
– Acțiune, reprezintă o operațiune a sistemului. Acțiunile sunt reprezentate prin
dreptunghiuri și poarte o denumire.
Editare produs

Figura 3.1 0 Reprezentarea grafică a unei acțiuni

21
– Deciziile sunt reprezentate prin romburi.
Date de acces corecte

Figura 3.1 1 Reprezentarea grafică a unei decizii

– Bara de ramificație reprezintă ramificarea acțiunilor .

Figura 3.1 2 Reprezentarea grafică a unei bare de ramificație

În figura 3. 13 este prezentată diagrama de activitate a unui client pentru rezervarea unui
spațiu. Starea de început este reprezentată de accesarea platformei de către utlizator. Acesta
apoi con tinuă prin a căuta produsul cu ajutorul motorului de căutare. Această acțiune este
reprezentată de dreptunghiul “C ăutare produse ”. În momentul în care un produs a fost găsit se
trece la următoarea verificare, dacă nu s -a găsit atunci se continuă căutarea. La următoarea
verificare se observă dacă utlizatorul este logat cu contul de client. Dacă nu este logat atunci el
este trimis către acțiunea de logare și apoi din nou la verificare, dacă acesta este logat cu contul
de client atunci acesta poate începe acți unea de a introduce detaliile pentru a rezerva spațiul.
Dacă datele sunt corecte atunci activitatea se încheie, altfel utilizatorul este întors pentru a
corecta greșelile.

22

Accesare website
Căutare produse
Produs găsitNUDA
Introducere detalii
rezervare produs
Detalii rezervare valideNU
DA
Cerere rezervare finalizatăLogare utilizator
Utilizatorul este logat
cu cont de clientNU
DA
Figura 3. 13 Diagrama de activitate a clientului

23
În figura 3.1 4 este prezentată diagrama de activitate a utilizatorului de tip
administrator. Starea inițială este la fel ca și la client, accesarea platformei însă pentru a
începe activitatea, utilizatorul de tip administrator trebuie sa logheze în cont prima dată.
Aceasta reprezintă prima activitate urmată de o verificare dacă datele acestuia sunt corecte.
După aceea acesta are opțiunea de a adauga un produs, a edita un produs, a șterge un produs
sau a accepta sau refuza o rezervare. În cazul adaugării ș i editării unui spațiu nou acesta
prima dată trebuie să introducă detalii valide și abia apoi activitatea se incheie. În cazul
ștergerii și a acceptării sau refuzării unei rezervări acestea încheie activitatea utilizatorului
fără nici un alt bloc de decizi e.
Accesare website
Logare cu cont
administrator
Date de acces corecteNU
DA
Adaugare produs Editare produs Stergere Produs
Detalii produs corecteDA
Detalii produs corecte
DANU NUAcceptare /Refuzare
Rezervare
Parasire platformaDANU

Figura 3.1 4 Diagrama de activitate a administratorului

24
3.2.2 Diagrama de secvență

Diagramele de secv ență detaliează interacțiunile mai multor obiecte dintr -un sistem.
Interacțiunile sunt reprezentate secvențial în timp. Sunt reprezentate obiectele, clasele și mesajele
schimbate dintre aceste entități pentru a îndeplini o anumită funcționalitate. Ordinea mesajele
denotă cronologia în care se execută acțiunile. Diagramele de secvență mai poartă denumirea de
diagramă de evenimente sau diagramă de scenariu.

Componentele diagramei sunt :
– Obiectele . Acestea sunt entitățile care interacționează între ele prin trimiterea mesajelor.
– Liniile de viață reprezintă axa de timp pentru diagramă. Sunt reprezentate prin linii
verticale punctate în cazul in care instanța obiectului nu a fost inițializată încă sau dacă
durata de viață a obiectului s -a terminat. Pentru instanțele obiectelor care sunt în viață
reprezentarea se face printr -o linie continua îngroșată.
Product

Figura 3.1 5 Reprezentarea grafică a unui obiect cu linia de viață

– Mesajele sunt interacțiunile dintre obiecte și sunt reprezentate prin niște săgeți orizontale.

25

În figura 3.17 se detaliază procesul care se execută pentru crearea unei rezervări. Procesul
începe după completarea formularului de rezervare de către client și primul mesaj este cel de
creare a unei rezervări. După lansarea mesajului de creare de rezerva re, se verifică în tabela
bookings dacă este disponibil spațiul pentru a fi rezervat și se returnează mesajul de confirmare
a disponibilității. Apoi se trimite o cerere către administrator si apoi o confirmare ca s -a trimis
o cerere de acceptare a rezervăr ii. După ce administratorul acceptă sau refuză rezervarea un
mesaj de răspuns se transmite înapoi către utilizatorul cu rolul de client.

User (role: client ) Product Booking
1. Creare rezervareUser (role: administrator )
2. Verificare disponibilitate
3. Confirmare disponibilitate
4. Cerere acceptare rezervare
6. Confirmare depunere
cerere rezervare
7. Raspuns acceptare /refuzare comanda5. Cerere acceptare rezervare
8. Raspuns comanda
9. Raspuns comanda

Figura 3.1 6 Diagrama de secvență

26

CAPITOLUL 4. IMPLEMENTAREA APLICAȚIEI

Capitolul acesta v -a acoperi implementarea aplicației. Implementarea ei presupune
transpunerea analizei și proiectării din faza anterioară în limbaje de programare. Înainte de a începe
trebuie alese limbajele, librăriile și arhitectura care urmează a fi fo losite în dezvoltarea aplicației.

4.1 Alegerea limbajelor de programare și a librăriilor

4.1.1 Limbajul de programare PHP

PHP-ul este un limbaj de scripting cu codul sursă deschis ( open source ) utilizat în special
pentru aplicațiile web. Acest limbaj a apărut prima dată sub de numirea de PHP/FI în anul 1994 și
a fost creat de către Rasmus Lerdorf și a apărut din dorința acestuia de a urmări numărul de
vizua lizări ale CV -ului său. De -a lungul timpului a rescris o mare parte din uneltele acestuia și l -a
numit simplu, PHP iar în iunie 1995 l -a publica ca sursă deschisă lucru care a ajutat enorm la
dezvoltarea acestuia .
În aplicația noastră el v -a funcționa drep t “creierul” platformei, mai exact acesta se v -a fi
intermediarul dintre interfa ță și baze de date cu ajutorul Frameworkului Laravel.

4.1.2 Laravel

Laravel este un framework de tip model -view -controler (MVC). În figura 4.1 se poate
observa că există cele 3 element e ( Model, View, Controller ) care interacționează între ele în felul
următor :
– Din view ( interfață ) cu ajutorul interacțiunii userului se trimite o acțiune către controller.
– Acest controller procesează informația și o transmite mai departe către model care nu este
altceva decât mulțimea entităților din baza de date.
– Modelul se ocupă de actualizarea datelor în baza de date și trimite înapoi către controller
un răspuns.

27
– Controllerul apoi trimite o confirmare înapoi către utilizator pentru ca ciclul să înceapă din
nou.

Figura 4.1 diagrama MVC a Frameworkului Laravel

Ca și cu majoritatea softurilor , există și alte moduri în care se pot implementa lucruri le.
Pentru arhitectură, există multe altele pe care dezvoltatorii le pot utiliza atunci când își construiesc
aplicațiile. Aici sunt câteva dintre e le:
– Client -Server Architecture – Acesta constă în două părți, sisteme client și server care
comunică printr -o rețea de calculatoare. Clienții face cereri serverului și serverul așteaptă
cereri.
– Layered Architecture – componentele sunt organizate în straturi, fiecare strat având un rol
specific în cadrul aplicației. Straturile pot varia în funcție de dimensiunea aplicației
– Peer-to-Peer Architecture – sarcinile sunt împărțite între diferiți peer și sunt frecvent
utilizate cu serviciile de partajare de fișiere

4.1.3 Web API

Cu ajutorul Frameworkului Laravel v -om crea un Web API (Application Programming
Interface) care nu este altceva decât un protocol de comunicare precum http/https cu care v -om
comunica cu PHP -ul, mai exact cu controller -ul aplicației. Acesta reprezintă săgeata “user actions ”
precum și “updates” prezente în figura 4.1 . Folosim această modalitate de comunicare deoarece
pe parte de interfață folosim limbajul de scripting Javascript .

28

4.1.4 Javascript

Javascript este un limbaj de scripting utilizat cel mai des în aplicațiile web pentru că acesta
conferă posibilitatea interacțiunii cu elementele HTML după încărcarea paginii. Acesta este un
limbaj de programare bazat pe evenimente și funcții dar oferă și posibilitatea utilizării protocoalelor
de comunicare cu serverul ( http, https etc.). Sintaxa se aseamănă destul de mult cu a limbajului de
programare Java însă diferă destul de mult în ceea ce privește design -ul.

4.1.5 VueJS

VueJS este un framework open -source de javascript pentru construcția de interfețe web în
structura Single Page Aplication (SPA) . Acesta folosește o structură unică care mai apoi este
compilată în limbaj javascript. Structura Single Page Aplication face par te din tehnologiile
moderne deoarece ofera posibilitatea unei aplicații fără nevoia reîmprospătării paginii acesta
folosindu -se de limbajul javascript pentru a reîncărca sau modifica conținutul.

4.2 Implementarea arhitecturii

După alegerea tehnologiilor se face trecerea la alegerea arhitecturilor folosite. Această
arhitectură este importantă pentru a fi ușor de menținut și modificat, iar procesul de implementare
va fi simplificat.

4.2.1 Arhitectura server

Pentru impleme ntarea aplicației de tip server, c are în cazul aplicației noastre este partea
frameworkului Laravel, am ales să folosesc arhitectura REST (Representational State Transfer).
Arhitectura a fost definită în anul 1999 de Roy Fielding.
O astfel de arhitectură are o structură care permite modifi care și extinderea sistemului cu
ușurință . Această arhitectură permite chiar și comunicarea unei aplicații de mobil sau desktop dacă
se dorește extinderea proiectului înspre acea zonă.

29
Pentru accesarea și manipularea resurselor de pe server se folosesc o s erie de operațiuni
uniformizate precum GET ; POST; PUT; DELETE;
Deși frameworkul Laravel se folosește de modelul MVC, am ales să combin aceste două
arhitecturi pentru a imbunătății experiența utilizatorului și din motive de performanță.