PLATFORMĂ DE AUTOMATIZARE A PROCESULUI DE COMANDĂ A SERVICIILOR PRESTATE DE COMPANIILE DE CATERING [302221]

Universitatea Tehnică a Moldovei

PLATFORMĂ DE AUTOMATIZARE A PROCESULUI DE COMANDĂ A SERVICIILOR PRESTATE DE COMPANIILE DE CATERING

PLATFORM FOR AUTOMATING THE PROCESS OF ORDERING SERVICES PROVIDED BY CATERING COMPANIES

Student: [anonimizat]: dr.hab.,prof.univ.
Leahu Alexei

Chișinău 2018

[anonimizat] a Moldovei

Facultatea Calculatoare Informatică și Microelectronică

Departamentul Ingineria Software și Automatică

Admis la susținere

Șef de departament: dr. conf.univ. Ciorbă D.

„__”_____________ 2018

PLATFORMĂ DE AUTOMATIZARE A PROCESULUI DE COMANDĂ A SERVICIILOR PRESTATE DE COMPANIILE DE CATERING

Proiect de licență

Student: (O, Gaponcic )

Conducător: (A. Leahu )

Consultanți: (A.Dodu )

(S. Cojocaru )

Chișinău 2018

Universitatea Tehnică a [anonimizat].conf.univ. Dumitru Ciorbă

șef de departament

„__”_____________ 2017

CAIET DE SARCINI

pentru proiectul de licență al student: [anonimizat]

1. Tema proiectului de licență „Platformă de automatizare a procesului de comandă a serviciilor prestate de companiile de catering”

confirmată prin hotărârea Consiliului facultății de la „ 3” noiembrie 2017

2. Termenul limită de prezentare a proiectului 25.05.2018

3. Date inițiale pentru elaborarea proiectului Sarcina pentru elaborarea proiectului de diplomă.

4. Conținutul memoriului explicativ

Introducere

1 Analiza domeniului de studiu

2 Modelarea și proiectarea sistemului

3 Realizarea sistemului

4 Documentarea produsului realizat

5 Evaluarea economică a proiectului

Concluzii

5. Conținutul părții grafice a proiectului

Imaginea generală a sistemului, Interfața de bază a sistemului 6. Lista consultanților:

7. Data înmânării caietului de sarcini 01.09.2017

Conducător

semnătura

Sarcina a fost luată pentru a fi executată

de către student: [anonimizat] 01.09.2017

semnătura, data

PLAN CALENDARISTIC

Student: [anonimizat], [anonimizat], [anonimizat]. Declar că lucrarea nu a mai fost prezentată sub această formă la nici o instituție de învățământ superior în vederea obținerii unui grad sau titlu științific ori didactic.

Semnătura autorului

Semnatura conducătorului de licentă

Universitatea Tehnică a [anonimizat]: Platformă de automatizare a procesului de comandă a serviciilor prestate de companiile de catering

Student: [anonimizat](a) Gaponcic Oleg gr. TI-141

1. Actualitatea temei: [anonimizat] a dus la o mare cerere în elaborarea diferitor aplicații pentru utilizarea de zi cu zi pentru comoditatea si economia timpului utilizatorului. O astfel de aplicație este platforma de automatizare elaborată, care facilitează procesul de comandare si livrare a prânzului in companii.

2. Caracteristica tezei de licență: Platforma a fost creată ca un sistem pentru simplificarea și sistematizarea procesului de colectare a comenzilor și transformarea sa într-un proces interactiv.

3. Analiza aplicației: Platforma dată este formată pentru gestionarea resurselor companiilor de catering, afișarea ofertelor disponibile și o eventuală livrare de produse către clienți.

4. Estimarea rezultatelor obținute: Această platformă este creată pentru popularizarea companiilor mici de catering și familiarizarea persoanelor aflate in câmpul muncii cu posibilitățile acestora.

5. Corectitudinea materialului expus: Materialul expus este prezentat prin referințe ale unor surse ce au fost scrise de specialiști ce dețin experiența în domeniul Tehnologiilor Informaționale.

6. Calitatea materialului grafic: Proiectul este prezentat prin: diagrame, tabele, interfețe ale aplicației.

7. Valoarea practică a tezei: Platforma este destinată utilizatorilor ce dețin un device cu conectare la rețeaua globala.

8. Observații și recomandări: Cerințele față de teza de licență au fost îndeplinite în totalitate. Observații nu sunt..

9. Caracteristica studentului și titlul conferit : Studentul Gaponcic Oleg a dat dovadă de profesionalism în elaborarea lucrării, a respectat cerințele impuse și a manifestat exigență în elaborarea și calitatea tezei de licență. Din cele relatate, urmează că lucrarea de licență poate fi admisă spre susținere.

Din cele relatate, urmează că lucrarea de licență poate fi admisă spre susținere, cu nota _________

Conducătorul tezei de licență dr.hab., prof.univ. Leahu Alexei

Rezumat

Platforma de automatizare a procesului de comandă a serviciilor de catering se rezumă la adunarea tuturor întreprinderilor mici ce livrează business-lunch-uri într-o comunitate unică, accesibilă consumatorilor, care se remarcă prin promptitudine a deservirii, și implicit câștig de timp, ce merită utilizat pentru propria persoană. Conținutul lucrării expune detaliat procesul de dezvoltare a acestei platforme.

Primul capitol cuprinde prezentarea generală a proiectului, importanța și caracterul inovativ al platformei, prin comparație cu alte sisteme asemănotoare existente pe piață.

În al doilea capitol al tezei se abordează procesul de modelare a sistemului și cerințele funcționale, dar și non-funcționale ale acestuia. Fiecare subcapitol descrie câte o componentă a platformei, susținute de reprezentăti grafice care facilitează demonstrația, permite întelegerea procesulu igeneral și înfățișează corelația dintre componente.

Cel de-al treilea capitol este dedicat instrumentelor de dezvoltare folosite. Argumentararea limbajelor și platformelor denotă posibilitățile acestora, dar și contribuția în realizarea platformei.

Capitolul 4 urmărește prezentarea interfeței grafice, o interfață user-friendly explicită pentru fiecare parte: prestator de servicii și client. Prestatorii vor dispune de o interfață pentru operarea cu clienții și gestionarea serviciilor proprii, în timp ce clienții vor interacționa cu interfața destinată vizualizării ofertelor.

Capitolul 5 este centrat pe scopul economic al aplicației. În această secțiune este prezentat planul calendaristic al proiectului precum și analiza câștigurilor și riscurilor, care prezic, într-un mod sau altul succesul proiectului propus.

Ultimul capitol este dedicat concluziilor generale privind nivelul serviciilor de catering pe piața locală, posibilelor direcții de dezvoltare și concurenței stabilite în urma lansării platformei.

Anexele lucrării conțin secvențe de cod din programele utilizate în scopul dezvoltării sistemului și diverse url ce indică punctele de intrare în aplicație.

Abstract

The Platform for automating the process of ordering services provided by catering companies is about gathering all small companies delivering business-lunches in a single, consumer-friendly community that stands out for prompt service and, implicitly, gaining time worthwhile spent for your own person. The content of the paper details the development process of this platform.

The first chapter includes the general presentation of the project, the importance and innovative character of the platform, as compared to other similar systems available on the market.

In the second chapter of the thesis, the process of modeling the system and its both functional and non-functional requirements are addressed. Each subchapter describes a component part of the platform, supported by graphical representations that facilitate demonstration, allow accurate understanding of the process and show the correlation between components.

The third chapter is devoted to the development tools used. The argumentation of the languages and the platforms denotes their possibilities and their contribution to this platform.

Chapter 4 aims to present the graphical interface; a user-friendly and explicit interface for both service provider and client. The providers will interact with an interface for operating with customers and managing their own services, while customers will interact with the interface for business-lunch offers. Chapter 5 is centered on the application's economic purpose. In this chapter is presented the calendar of the project, as well as the analysis of gains and risks, which predict in one way or another the success of the proposed project.

The last chapter is devoted to general conclusions regarding the level of catering services on the local market, the possible directions of development and competition established following the launch of the platform. The annexes to the report contain code snippets from the programs used in order to develop the system, and various URLs indicating the entry points in the application.

Introducere

La etapa contemporană, progresul social-economic al oricărei țări din lume depinde direct de gradul de integrare a ei în diviziunea internațională a muncii, tehnologiile existente, volumul de capital, servicii etc. În acest sens, alături de schimbul simplu de mărfuri, o importanță deosebită în relațiile economice internaționale o are cooperarea tehnică și științifică, comercializarea realizărilor științifice și tehnice, acordarea diferitor servicii etc.

Revoluția digitală a devenit un factor primordial de creștere economică și schimbare socială. Astfel, la începutul mileniului trei vorbim despre societatea informațională ca despre un nou stadiu în dezvoltarea civilizației umane, ca despre o revoluție a tehnologiei informației și comunicațiilor și a naturii muncii. Sectorul TIC este printre sectoarele economice în plină ascensiune, înregistrând una din cele mai rapide dezvoltări și creșterii. Dezvoltarea economică durabilă a unei țări depinde în primul rând de capacitatea acesteia de a utiliza eficient tehnologiile informaționale și de comunicații care contribuie esențial la sporirea productivității forței de muncă.

Tehnologiile informaționale sunt percepute ca un catalizator al proceselor de restructurare a activităților comerciale precum și a strategiilor de dezvoltare a întreprinderilor. Internetul reprezintă noi oportunități pentru firmele tradiționale, inclusiv prin diversificarea serviciilor oferite și promovarea de servicii noi,

Explozia Internet-ului a permis dezvoltarea unei noi forme de comerț – comerțul electronic. Incontestabil, ne aflăm într-o perioadă în care timpul este cel mai valoros activ pe care îl deținem. Nu e de mirare că oamenii sunt tentați să recurgă la comerțul electronic. Acesta utilizează cu succes progresul informațional în scopuri proprii, astfel încât permite oamenilor schimburi de bunuri și servicii, depășind barierele de timp și spațiu.

La momentul actual, tot mai multe companii ce desfășoară relații comerciale aleg comerțul electronic ca o soluție pentru eficientizarea activității, reducerea costurilor și reținerea clientilor. Totuși, este extrem de dificil să începi o afacere mică care ar rezista concurenței acerbe pe piață.

În conformitate cu art. 107 alin. 1 din Codul muncii al R.M., în cadrul programului zilnic de muncă, salariatului trebuie să i se acorde o pauză de masă de cel puțin 30 de minute și una din cele mai eficiente metode de satisfacere a nevoilor alimentare este utilizarea serviciilor de catering. Catering denumește activitatea de alimentație publică în toată complexitatea ei, livrarea și servirea de către unități specializate a preparatelor culinare în alte locuri decât restaurant (sedii de firme, instituții), la comanda unui client (persoană fizică sau juridică).

Platforma de automatizare a procesului de comandă a serviciilor de catering pe care o propun permite companiilor noi și necunoscute să își găsească mai ușor consumatorul. Clienții au posibilitatea de a vizualiza produsele și serviciile, a face comenzi online, a alege metoda de plată și a primi informații cu privire la starea comenzilor.

1 Analiza domeniului de studiu

Platforma propusă se încadrează în domeniul tehnologiilor informaționale. Proiectul se împarte, în general, în două diviziuni: partea client (front-end) și partea server (back-end), care comunică între ele prin rețea. Partea de back-end presupune un RESTful API, care aprovizionează pagina web cu date. Ulterior, api-ul respectiv poate servi în calitate de sursă de date și pentru aplicații mobile, precum Android și iOS. Principala aplicație a platfomei se va raporta la sfera serviciilor, reprezentând punctul de pornire pentru companiilor mici al căror domeniu de activitate implică servicii de catering, dar și un imbold pentru companiile deja stabilite pe piață care au o bază limitată de clienți.

1.1 Importanța temei

Comanda și livrarea business-lunch-urilor nu reprezintă o idee nouă de afaceri online, totuși, a evoluat odată cu intrarea în prim plan a tehnologiei. Analizând ofertele pe piața internă, am constatat ca majoritatea afacerilor online se bazează pe livrarea bucatelor din cele mai solicitate restaurante, fapt ce implică preț majorat, taxare pentru livrare, precum și timp îndelungat de livare.

Ideea platformei reiese din dorința de a aduna într-o comunitate unică toate întreprinderile mici ce nu dispun de resurse financiare pentru reclamă, fie implică un proces complicat de comandă, dar se remarcă prin preț convenabil, bucate delicioase și promptitudine a deservirii. Prin urmare, lipsa posibilității de a părăsi sediul firmei pe parcursul zilei de muncă, suprasolicitarea la serviciu sau lipsa de timp pentru prepararea de sine-stătătoare a meselor sunt principalele motive care m-au inspirat în crearea proiectului.

1.2 Sisteme similare cu proiectul realizat

Conceptul serviciilor catering nu este unul nou pentru Republica Moldova, așadar pe piața internă există deja o mulțime de companii ce prestează așa tip de servicii. Platforma pe care tind să o elaborez nu intenționează să concureze cu acestea, ci, mai degrabă, să creeze un teren comun pentru clienți si prestatori de servicii, care ar implica o comunicare avantajoasă pentru ambele parți implicate.

Reieșind din ideea de mai sus, după o analiză a pieței locale, lista de potențiali concurenți s-a redus până la 2 platforme:

Straus.md;

Foodhouse.md.

Straus.md (fig.1.1) reprezintă un serviciu de comandare și livrare a mâncării oriunde în Chișinău și în localitățile aflate în raza capitalei. Straus deține o interfața web care oferă acces la meniul a zeci de restaurante, împreună cu ofertele speciale existente și gradul lor de popularitate în comparație cu alte localuri de același tip. Deasemenea, compania are propria echipă de curieri instruiți, repartizați uniform în aria Chișinăului, ceea ce asigură livrarea rapidă a comenzii, indiferent de locația clientului. Straus.md are ca parteneri peste 100 de localuri din Chișinău: restaurante, cafenele, pizzerii, sushi-bar-uri și cîrciume. Acest fapt, îmbinat cu posibilitatea de a face comanda din mai multe localuri simultan, permite satifacerea oricăror pofte ale clientului [1].

O altă platformă similară este Foodhouse.md, companie de livrare la domiciliu a bucatelor preparate în restaurantele Chișinăului. Foodhouse este una din primele companii de așa tip pe piața internă, cu experiența de peste 3 ani. Platforma deasemenea dispune de o interfața web, care permite vizualizarea meniurilor a zeci de localuri din orașul Chișinău, ofertele disponibile, informație despre prețul și durata aproximativă a livrării [2].

Ambele platforme prezentate anterior au atît avantaje, cît și dezavantaje.

În calitate de puncte forte menționez:

un număr imens de companii partenere;

sisteme de clasificare a localurilor;

interfața simplă și accesibilă pentru utilizator;

accesibilitate în mai multe limbi.

Punctele slabe:

raza limitată de livrare;

livrarea contra plata;

lipsa aplicațiilor pentru paltformele mobile.

Comparativ cu sistemele expuse anterior, platforma propusă de mine e o soluție mai accesibilă și mai simplă. Ideea de bază este de a crea o punte virtuală între client și companii, fără a presta servicii de catering sau livrare propriu zisă. Este orientată spre piața internă, atât Chișinau, cât și restul țarii.

Platforma elaborată urmarește îmbunătățirea punctelor slabe menționate mai sus, astfel faza finală va implica atât o interfața web, precum și aplicații mobile pentru cele mai populare platforme. Mai mult de aîat, va fi posibilă abonarea pentru un anumit interval de timp la serviciile oferite, ceea ce ar putea soluționa problema livrărilor contra plata.

1.3 Scopul, obiectivele și cerințele sistemului

Platformă de centralizare a serviciilor de catering a fost implementată cu scopul de a simplifica procesul de comandă și primire a bucatelor pentru clienții aflați în criză de timp, dar și de a promova companiile mici care fac primii pași în sfera de livrare a produselor. Platforma va fi orientată doar pe livrarea de business lunch-uri, ceea ce va permite evitarea concurenței directe cu giganții deja menționați, care acordă atenție livrării bucatelor de orice tip, mai puțin prânzurilor la pachet. Urmărirea unei direcții unice de dezvoltare permite concentrarea resursele disponibile în scopul realizării calitative a unui singur obiectiv.

Platforma va reprezenta o interfața web, precum și aplicații mobile alimentate cu date de același API. Domeniul de bază – business lunch – va fi singurul domeniu la etapa inițială. Utilizatorii țintă pentru partea “clienți”, sunt angajații companiilor cu personal numeros, astfel încît cantitatea mare de comenzi să acopere cheltuielile pentru livrare. Partea „prestatori de servicii”, se așteaptă să fie completată de companiile mici, fară nume, specializate doar în producerea și livrarea prânzurilor, care nu dispun de resurse suficiente pentru crearea și menținerea unui web-site pentru promovarea proprie.

Platforma va fi gratuită doar pentru clienți, prestatorii de servicii vor fi nevoiți sa achite lunar o taxă, pentru o putea folosi toate posibilitațile sistemului.

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

Pornind de la cerințele utilizator discutate în urma negocierii contractului, am definit următoarele cerințe către partea client a sistemului: Cerințele funcționale ale unui Sistem Informațional sunt acele servicii pe care sistemul trebuie să le ofere viitorilor utilizatori. Ele indică modul în care SI va trebui să reacționeze la anumite momente în procesul de operare, precum și comportamentul în anumite situații particulare. În continuare vor fi specificate cerințele în baza cărora a fost proiectat și realizat sistemul dat:

crearea comenzilor și gestionarea lor;

înregistrarea utilizatorilor cu roluri diferite si drepturi de acces diferite

utilizatorii cu rol de Client pot crea comenzi, se pot înscrie la serviciile disponibile, pot vizualiza oferte speciale, reduceri, pot nota compania sau lăsa un comentariu;

utilizatorii cu rol de Prestator de servicii, au dreptul de adăuga, modifica, șterge produse din cadrul companiei înregistrată în platformă, răspunde la comentariile utilizatorilor, posta oferte, reduceri, noutăți pe pagina proprie, accepta sau refuza comenzile după criterii prestabilite;

gestionarea utilizatorilor înregistrați și a procesul de înregistrare;

depozitarea materialului încărcat

în baza de date pentru materialele de tip text;

în repozitorii speciale pentru materialele PDF, imagini.

Cerințele non-funcționale reprezintă totalitatea constrângerilor care nu au atribuție directă asupra modului de funcționare a sistemului, precum materialului publicat, regulile de formatare si prezentare a informației , cerințele din punct de vedere legislativ fața de conținutul publicat ș.a.

materialele încărcate nu trebuie sa încalce în nici un mod drepturile de autor;

dimensiunea imaginilor trebuie sa nu depășească mărimea de 10 MB;

compania trebuie să includă pe pagina de profil informații despre orele de lucru, costul livrării;

pagina de profil a companiei nu trebuie să conțină reclama, propagandă sau careva chemări la acțiuni ce nu au legătura cu sfera alimentară;

se interzice utilizarea limbajului necenzurat la lăsarea recenziilor.

2 Modelarea și proiectarea sistemul informatic

Modelarea și proiectarea sistemelor informatice reprezintă o etapă importantă în realizarea propriu-zisă a sistemelor. În cadrul acestor etape se construiește arhitectura sistemului și se proiectează logic și fizic componentele acestuia.
În vederea proiectării sistemelor s-au creat limbajele de modelare. Unul din aceste limbaje de modelare este limbajul de modelare unificat – UML (The Unified Modeling Language). UML nu este un simplu limbaj de modelare orientat pe obiecte, ci în prezent, este limbajul universal standard pentru dezvoltatorii software din toată lumea. UML deține o expresivitate, care ajută la rezolvarea problemelor de modelare pe care vechile limbaje nu o aveau. În prezent, UML oferă arhitecturi de sisteme ce funcționează pe analiza și proiectarea obiectelor cu un limbaj corespunzător pentru specificarea, vizualizarea, construirea și documentarea sistemelor sofware. UML este un limbaj de modelare care oferă o exprimare grafică a structurii și comportamentului software, înainte de a iniția proiectarea și dezvoltarea unui sistem.

Luând în considerație că procesul de modelare constă în combinarea notațiilor UML în elemente complexe, numite diagrame, definim nouă tipuri de astfel de diagrame: diagrama cazurilor de utilizare, diagrama de secvență, diagrama de colaborare, diagrama de clase, diagrama de componente, diagrama de stări, diagrama de construcție, diagrama de obiecte și diagrama de activități [3].

2.1 Descrierea comportamentală a sistemului

Descrierea comportamentală este prezentată de modul în care operează sistemul, precum și funcționalitățile oferite de acesta, fiind axată pe ansamblul de proceduri privind circulația datelor de intrare și ieșire. Descrierea compertamentală se bazează pe următoarele:

imaginea generală asupra sistemului, înfățișată, de regulă, de interacțiunea dintre un actor și un sistem și furnizează funcționalitățile, interfețele oferite de către acest sistem;

modelarea vizuală a fluxurilor ce reprezintă trecerea sistemului de la o activitate la alta în timpul interacțiunii cu utilizatorul;

stările și tranzacțiile sistemului descriu ciclul de viață a unui obiect, stările sale, dar și fluctuațiile de stare ce au loc pe parcursul ciclului de viață;

descrierea scenariilor de utilizare a sistemului sunt recomandate pentru prezentarea interacțiunilor dintre entități și ordinea de întreschimbare a mesajelor;

fluxurile de mesaje și legăturile dintre componentele sistemului ilustrează fluxurile de mesaje și legăturile dintre componentele sistemului

2.1.1 Imaginea generală asupra sistemului

O diagrama a cazurilor de utilizare (use case diagram) prezintă o colecție de cazuri de utilizare și actori care:

ofera o descriere generală a modului în care va fi utilizat sistemul;

furnizează o privire de ansamblu a functionalităților ce se doresc a fi oferite de sistem;

arată cum interacționeaza sistemul cu unul sau mai multi actori;

asigură faptul că sistemul va produce ceea ce s-a dorit.

Figura 2.1 prezintă acțiunile ce pot fi realizate de actorii/utilizatorii cu rol de ”Prestator servicii”:

plasare/redactare de oferte/noutăți;

adăugarea/editare produse/meniuri;

vizualizarea clienților abonați;

gestionarea comenzilor.

Figura. 2.1 – Diagrama cazurilor de utilizare corespunzătoare acțiunilor Prestatorului de servicii

Figura 2.2 reprezintă acțiunile posibile ce pot fi întreprinse de administrator:

operarea cu conținutul din baza de date;

modificarea funcțională și aspectului sistemului;

managementul utilizatorilor;

moderarea conținutului;

operarea cu baza de date;

gestionarea datelor despre utilizatori;

gestionarea noutăților, meniurilor, produselor, precum și conținutului paginii de profil;

gestionarea drepturilor de acces și limitarea funcționalului în conformitate cu rolul;

Figura. 2.2 – Diagrama cazurilor de utilizare corespunzătoare acțiunilor Administratorului

Figura 2.3 descrie posibilitățile utilizatorilor cu rol de Client în cadrul sistemului:

crearea unei comenzi;

vizualizarea istoricului de comenzi;

abonarea la servicii pentru o perioadă de timp;

comentarea și notarea prestatorului de servicii;

vizualizarea meniurilor disponibile.

Figura 2.3 – Diagrama cazurilor de utilizare corespunzătoare acțiunilor Clientului

2.1.2 Modelarea vizuală a fluxurilor

Activity Diagram reprezintă o modalitate de modelare vizuală a fluxurilor. Cu ajutorul activity diagram pot fi modelate foarte bine use case-urile, dar, în aceeași măsură, aceste diagrame pot fi folosite pentru modelarea proceselor de business (fără legătură cu sistemul informatic). Unul dintre elementele de bază al acestui tip de diagramă este punctul de decizie, care presupune un punct din fluxul de activități în care se face o anumită alegere între mai multe variante posibile [4].

Figura 2.4 indică modul în care se calculează costul livrării în dependență de mărimea comenzii. Astfel, în cazul când comanda este constituită din mai puțin de 5 unități (meniuri) de orice tip, livrarea va constitui 60 lei, dacă numărul de unități în comandă este cuprins între 5 și 10, livrarea va constitui 30 de lei. Pentru restul cazurilor rămase, livrarea va fi gratuită.

Figura 2.4 – Diagrama de activitate corespunzătoare calculării prețului de livrare

Figura 2.5 are ca scop prezentarea modului în care este procesată o comandă din momentul creării, până la momentul livrării acesteia clientului. Odată plasată, comanda urmează sa fie validată de către moderator atât ca conținut cât și ca achitare, ca mai apoi să fie livrată clientului.

Figura 2.5 – Diagrama de activitate corespunzătoare procesării unei comenzi

Figura 2.6 prezintă modul în care clientul/utilizatorul poate filtra conținutul paginilor cu oferte după unele criterii prestabilite. Utilizatorul face click pe un filtru propus, de exemplu: „Meniul zilei” , apoi sistemul verifică în baza de date dacă există un meniu marcat pentru ziua curentă. În caz de rezultat afirmativ, poate avea loc vizualizarea meniului și produselor, iar în cazul răspunsului negativ, utilizatorul poate încerca alt filtru din cele disponibile.

Figura 2.6 – Diagrama de activități corespunzătoare căutării meniului zilei

2.1.3 Stările de tranzacție a sistemului

Diagramele de tip statechart sunt utilizate pentru a specifica posibilele stări prin care poate trece un obiect și modul în care se poate trece de la o stare la alta (modelare work-flow-uri, modelare fluxuri de documente, diagrame de stări).
Trecerea de la o stare la alta este determinată de tranzacțiile intermediare – acestea corespund Acțiunilor pe care le-am întâlnit la Activity Diagram (până la urmă, Statechart Diagram reprezintă un alt mod de a vedea un flux ce poate fi modelat exclusiv prin Activity Diagram, inventată pentru a exprima mai elocvent trecerile de la o stare la alta).

Figura 2.7 exprimă starile în care se poate afla utiliztorul în sistemul dat. Astfel, imediat după înregistrare, utilizatorul va avea un cont neconfirmat, până la momentul când va accesa link-ul de confirmare trimis pe email-ul indicat la înregistrare. Deasemenea utilizatorul poate fi dezactivat de către administrator, în cazul nerespectării regulilor sistemului sau din motiv că a fost inactiv pentru o perioadă mai lungă de 6 luni.

Figura 2.7 – Diagrama de stare a utilizatorului

Figura 2.8 arată stările prin care trece o tranzacție de bani a utilizatorului, în momentul achitării comenzii. Inițial, tranzacția este marcată ca nouă. Odată cu validarea datelor bancare a utilizatorului, tranzacția este acceptată și finisată; în caz contrar – este respinsă.

Figura 2.9 sugerează starea oricărui meniu, creat in sistemul dat. Astfel, în momentul adaugării unui meniu de către moderator, acesta nu este vizibil utilizatorilor până când moderatorul îl publică. În cazul în care meniul numai este actual, dar poate prezenta interes mai târziu, el poate fi ascuns, fiind trecut de moderator în starea inițială de “nepublicat”.

Figura 2.9 – Diagrama de stare a unui meniu

Descrierea scenariilor de utilizare a aplicației

Diagramele de secvențe descriu interacțiunile dintre două sau mai multe entități și ordinea în care mesajele sunt schimbate între acestea. Sun folosite în special pentru a reprezenta interacțiunile dintre obiecte. Diagramele de secvențe sunt utilizate pentru:

descrierea scenariilor de utilizare a aplicației (pentru fiecare diagramă a cazurilor de utilizare definită în cadrul procesului de analiză se pot defini unul sau mai multe scenarii de utilizare prin care se evidențiază fluxurile de mesaje între sistem și utilizator sau între componentele sistemului);

descrierea logicii metodelor – diagramele de secvențe pot fi folosite pentru a descrie logica de funcționare a funcțiilor sau proceselor complexe;

descrierea logicii unui serviciu sau proces – pentru a implementa o funcție complexă la nivelul sistemului este nevoie ca două sau mai multe componente să interacționeze. Diagramele de secvențe permit reprezentarea fluxurilor de mesaje între componentele sistemului, evidențiind și constrângerile temporare (ordine de execuție, durate de execuție, termene limită).

Elementele asociate cu diagramele de secvențe sunt: liniile de viață, mesajele și fragmentele.

În figura 2.10 este reprezentată diagrama de secvență corespunzătoare procesului de înregistrare în sistem. Utilizatorul completează formularul de înregistrare. Datele din formular trec validarea după format, apoi sunt transmise către server. Serverul procesează datele primite, le transmite către baza de date pentru verificarea existenței unui asemenea utilizator; și, în cazul în care nu există, se efectuează înregistrarea.

Figura 2.10 – Diagrama de secvență corespunzătoare procesului de înregistrare în sistem

Utilizatorul completează formularul de adăugare a produselor, după care datele urmează a fi validate conform formatului. Validarea trecută cu succes este însoțită de transmitarea datelor către server, unde acestea sunt procesate și tipizate.

Ulterior, datele sunt înregistrate în baza de date, fiind transmis mesajul de adăugare cu succes către utilizator (fig 2.11).

Fluxurile de mesaje și legăturile dintre componentele sistemului

Diagramele de colaborare (cunoscute și sub numele de diagramele de comunicare) ilustrează fluxurile de mesaje și legăturile dintre componentele sistemului. Sunt similare cu diagramele de secvențe, dar spre deosebire de acestea timpul nu este reprezentat ca o dimensiune separată. Diagramele de colaborare sunt utilizate pentru:

a descrie diverse scenarii de funcționare a aplicației prin reprezentarea fluxurilor de mesaje dintre obiecte;

a prezenta organizarea spațială a obiectelor și legăturile dintre acestea.

În figura 2.12 poate fi observat procedeul de adăugare al unui utilizator cu rol de moderator. Inițial, moderatorul se înregistrează în sistem la fel ca un utilizator de tip client, după care acesta poate solicita drepturile corespunzătoare de la administrator. Ulterior administratorul este notificat despre solicitarea de drepturi, iar odată cu acordarea lor, utilizatorul este înștiințat de schimbarea statutului său.

Figura 2.12 – Diagrama de colaborare pentru adăugarea unui moderator

2.2 Descrierea structurală a sistemului

Descrierea structurală exprimă modul în care entitățile, componentele logice ce alcătuesc sistemul sunt interconectate în vederea comportamentului dorit.

Descrierea structurală a sistemului include în sine :

descrierea structurii statice;

relațiile de dependență între componentele sistemului;

modelarea echipamentelor mediului de implementare.

În compartimentul relațiile de dependență între componentele sistemului se vor include diagramele de componente ce descriu relațiile structurale între componentele sistemului.

2.2.1 Descrierea structurii statice a sistemului

Descrierea structurii statice a sistemului prezintă clasele sistemului, interdependeța lor (moștenirea, agregarea, compoziția), analizează cerințele sub forma unui model conceptual, descrie proiectarea detaliată a aplicației, utlizând principiile programării orientate pe obiect. Structura statică, deci, implicit entitățile/ clasele existente într-un sistem sunt descrise prin intermediul diagramelor, numite Class Diagram. Acest tip de diagramă este utilizat cel mai adesea de către dezvoltatori pentru specificarea claselor, dar poate fi foarte util și pentru specificarea structurii unor sisteme sau subsistem dintr-un business real.
Astfel, figura 2.13 intenționează să explice componența unui meniu prin interacțiunea modelelor care îl formează. Din entitățile obligatorii, putem evidenția următoarele: produsele care se includ in meniu și ziua în care meniul este publicat. Deasemenea observăm ca pentru adăugarea unui produs avem nevoie să descriem cel puțin un tip de produs.

Figura 2.13 – Diagrama de clasă pentru gestionarea unui meniu

În figura 2.14 poate fi observat că fiecare comandă plasată în sistem este păstrată într-o istorie comună, împreună cu data când a fost creată. Informația colectată ne va permite în viitor să avem o imagine statistică despre comenzi. Deasemenea fieacare comandă este alcătuită dintr-o serie de clase dependente precum conținutul coșului(meniurile), livrarea(costul), starea comenzii, utilizatorul care a plasat-o.

Figura 2.14 – Diagrama de clasă pentru gestionarea unei comenzi

Iar figura 2.15 transmite că modelul utilizatorului din sistem nu este cel obișnuit framework-ului Django, însă moștenește câteva interfețe predefinite pentru a păstra funcționalul inițial. Deasemenea observăm că indiferent de rol, utilizatorul are un profil în care își poate expune datele personale publice precum: o descriere succintă, genul, poza, numărul de telefon, etc… și un model de tranzacții pentru manipularea lui (confimare email, schimbare de parolă).

Figura 2.15 – Diagrama de clasă pentru administrarea utiliziatorilor

Din figurile de mai sus putem observa că fiecare clasă a sistemului se moștenește de la clasa BaseModel, ceea ce le conferă câmpuri pentru identificator unic(uuid), data creării și data actualizării.

2.2.2 Relațiile de dependență între componentele sistemului

Diagramele de componente redau relațiile de dependență între diferite componente ale unui sistem. Acestea sunt importante prin faptul că:

modelează sistemul software real în mediul de implementare;

evidențiază problemele de configurare prin relațiile de dependență;

reprezintă o imagine a sistemului existent, înainte de a fi modificat;

pot evidentia probleme de implementare fără a fi necesar să se citească tot codul sursă.

În figura 2.16 este reprezentată diagrama de componente a sistemului nostru, unde pot fi vizualizate componentele principale, mai exact interfața grafică, serverul backend și baza de date.

Figura 2.16 – Diagrama de componente a sistemului

Interfața grafică răspunde de interacțiunea sistemului cu utilizatorii, colectarea datelor și formatarea lor. Serverul de backend procesează datele primite din interfața grafica și le transmite către baza de date, unde acestea se păstrează repartizate conform tipului lor.

2.2.3 Modelarea echipamentelor mediului de implementare

Echipamentele mediului de implementare sunt modelate de către diagramele de distribuție. Fiecare nod dintr-o diagramă de distribuție reprezintă un tip de echipament: un PC client, un server, o unitate de disc, un procesor. Un nod poate să reprezinte, de asemenea, o ființă umană sau o organizație, mai exact funcția pe care o persoană sau organizația o poate executa. Nodurile sunt abstracții ale echipamentelor, așa cum clasele sunt abstracții ale obiectelor. Fiecare nod reprezintă un tip de echipament, nu un echipament particular. Un nod se reprezinta printr-un cub în care este înscris numele său. Nodurile pot fi organizate specificând relații de dependență sș asociere ( inclusiv agregare) între ele.
Prin urmare, în figura 2.17 calculatorul clientului și serverul platformei sunt noduri.

Figura 2.17 – Diagrama deployment a sistemului

3 Realizarea sistemului

Realizarea sistemelor informatice reprezintă o acțiune complexă, care îmbină un număr mare de activități: analiză, proiectare, implementare, exploatare. În plus, reclamă resurse umane, materiale și financiare însemnate, pe o perioadă considerabilă de timp. Folosirea eficientă a acestor resurse, în scopul obținerii unui sistem informatic performant a impus ordonarea acestui proces complex, într-o succesiune bine stabilită de etape și subetape și utilizarea unor metode și tehnici adecvate. Acest lucru a dus deci, la conturarea unor metodologii de realizare a sistemelor informatice. Între diversele etape de realizare a sistemelor informatice există o legătură indestructibilă, legătură reflectată și de faptul că în mod logic și practic calitatea realizării unor activități din etapele și fazele precedente influențează în mod decisiv calitatea activităților din etapa ce îi urmează [5].

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

PyCharm;

Django Framework;

Nginx;

PostgreSql;

Valentina Studio;

Git.

PyCharm este un produs al companiei JetBrains, care oferă un set de funcțional pentru dezvoltarea si generarea proiectelor bazate pe ecosistemul limbajului de programare python. PyCharm oferă un set larg de funcțional, cum ar fi:

analiza statica a codului și evidența de sintaxă și erori;

navigare avansată prin structura proiectului;

refractoring avansat;

instrumente integrate pentru debuging-ul aplicaților pe Django, Flask, Python etc;

rularea și monitorizarea testelor unitare;

integrarea cu sistemele de control de versiune ca Git, Mercurial, Subversion etc [6]

Django este un framework open source pentru crearea aplicațiile web bazate pe limbajul de programare Python. Django folosește unul din cele mai populare modele de arhitecturale MVC. Django are o mentenanța continua oferita de compania "Django Software Foundation". Scopul principal al acestui soft cadru pentru dezvoltarea aplicațiilor web este de a facilita crearea de website-uri complexe, fundate pe baze de date. Django pune accent pe reutilizarea codului, pe modularitate, dezvoltare rapidă a site-urilor web, ghidându-se după principiul "nu te repeta" (en. Don't repeat yourself – DRY). Django este codat de la un capăt la altul în Python, chiar și fișierele de configurare și modelele de date sunt implementate în acest limbaj de programare. Django oferă și un panou administrativ, care, deși vine preinstalat, este opțional, prin intermediul acestuia se pot crea, citi, actualiza și șterge cu ușurință informații din baza de date. Acest panou de administrare este generat dinamic prin introspecție (prin analizarea tabelelor din baza de date) și poate fi ușor configurat prin modelele administrative de date [7].
Model-view-controller (MVC) este un model arhitectural utilizat în ingineria software. Succesul modelului se datorează izolării logicii de business față de considerentele interfeței cu utilizatorul, rezultând o aplicație unde aspectul vizual sau/și nivelele inferioare ale regulilor de business sunt mai ușor de modificat, fără a afecta alte nivele.
Nginx este un web server cu un mail proxy server, care rulează pe sistemele de operare din familia Unix.
PostgreSQL reprezintă un sistem de baze de date obiect-relaționale. Caracteristica de bază a sistemeleor de tipul dat este suportul obiectelor personalizate și comportamentul lor, inclusiv tipurile de date, funcții, operatiuni, domenii, indexi. Este disponibil gratuit sub o licență open source de tip BSD. PostgreSQL nu este controlat de nici o companie, își bazează dezvoltarea pe o comunitate răspândită la nivel global, precum și câteva companii dezvoltatoare [8].
Git este un sistem de version control care rulează pe majoritatea platformelor, inclusiv Linux, POSIX, Windows și OS X. La fel ca și Mercurial, Git este un sistem distribuit și nu întreține o bază de date comună. Este folosit în echipe de dezvoltare mari, în care membrii echipei acționează oarecum independent și sunt răspândiți pe o arie geografică mare.

3.1 Descrierea la nivel de cod pe module

Cum a fost menționat mai sus platforma a fost realizată folosind framework-ul Django, utilizând un set de instrumente, numit Django REST framework, ceea ce a permis creare la unui Restful Web API .
Primul pas este crearea unui set de Modele care vor fi folosite pentru maparea către tabelele din baza de date. Pentru crearea modelelor este nevoie de a seta conexiunea cu baza de date. Pentru crearea conexiunii, este nevoie de a fi setat driver-ul pentru PostreSQL, care e nativ suportat de către Django ORM (figura 3.1).

Figura 3.1 – Configurările conexiunii cu baza de date

Datele sensibile sunt preluate dintr-un fișier din mapa proiectului, fișier de mediu care nu este urmărit de GIT (figura 3.2).

Figura 3.2 – Fișierul .env

În calitate de actor principal al platformei este numit utilizatorul. Framework-ul Django oferă, implicit, un Model de utilizator, care are strict necesarul, însa platforma are nevoie de un model de utilizator mai avansat, astfel a fost creat un alt model de utilizator care poate fi modificat după necesități (figura 3.3).

Figura 3.3 – Modelul utilizatorului

Pentru stocarea informației suplimentare depre utilizator, a fost creat incă un model, numit profil (figura 3.4).

Profilul este compus din următoarele câmpuri:

numele;

prenumele;

număr de telefon;

gen;

descriere;

imagine de profil.

Există și date care sunt dependente de alte entități (relații):

utilizator, legătura 1 la 1 cu utilizator;

Figura 3.4 – Modelul profilului

Pentru stocarea informației despre local, a fost creat modelul corespunzător (figura 3.5)., alcătuit din următoarele câmpuri:

numele localului;

adresa;

imagine(logo);

descriere;

date de contact;

email.

Dintre datele dependente de alte modele face parte doar câmpul proprietar, care este ăn relație de 1 la 1 cu modelul utilizatorului.

Figura 3.5 – Modelul localului

Deasemenea, entitățile de bază a proiectului include modele pentru produs (figura 3.6), meniu (figura 3.7), comandă (figura 3.8) și obiect din coș (figura 3.9).

Figura 3.6 – Modelul produsului

Înafară de datele simple aflate în modele, de menționat este faptul că meniul este în relație de mulți la mulți cu modelul produsului, ceea ce permite reutilizarea aceluiași produs în diferite meniuri.

Figura 3.7 – Modelul meniului

Pentru a păstra în coș mai multe meniuri de același tip, a fost creat un model suplimentar , care păstrează id-ul meniului și cantitatea acestuia în comanda realizată.

Figura 3.8 –Modelul unei entități din coș

Un alt actor principal este modelul pentru comandă. Comanda este o entitate cu numeroase câmpuri, printre care se numără:

Figura 3.9 – Modelul comenzii

client (id valid al unui utilizator);

adresă;

descriere;

număr de telefon;

starea comenzii;

suma comenzii;

costul livrării;

entități din coș (relație mulți la mulți).

3.2 Descrierea proceselor de bază

În scopul utilizării platformei este necesară parcurgerea a doi pași:

înregistrarea unui cont nou cu rol de client ori proprietar de local;

autentificarea cu datele personale;

Înregistrarea constă în completarea unei forme, procesarea datelor și crearea unui cont nou. Autentificarea (figura 3.10), constă și ea dintr-o forma în interfață web, care transmite o cerere spre api, după care, în caz de succes după validarea datelor introduse, utilizatorul va primi ca răspuns un token JWT care va reprezenta starea de utilizator logat (pâna la expirarea token-ului).

Figura 3.10 – Serializatorul de autentificare JWT

Adăugarea unei comenzi (figura 3.11) are loc doar pentru utilizatorii autentificați în rol de client. Comanda constă în adăugarea în coș a meniurilor dorite (în interfața web), după care datele sunt trimise la api pentru a fi validate; dacă datele sunt valide, comanda va fi creată și atașată automat utilizatorului. Odată cu crearea comenzii, se crează automat și itemii comenzii, fiecare item reprezentând identificatorul unic al unui meniu și cantitatea lor în comandă.

Figura 3.11 – Adăugarea unei comenzi

4 Documentarea produsului realizat

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

prezentarea generală;

platforma de automatizare este un sistem complex, bazat pe tehnologii web ca Django.

Sistemul este format din 4 părți:

partea de administrare;

partea de gestionare a meniurilor și a produselor;

partea de gestionare a comenzilor;

partea de gestionare a noutăților și feedback-ului.

Toate 4 module enumerate mai sus, sunt bazate pe tehnologiile web. Această suită de module împreună oferă o funcționalitate complexă de distribuire și consum al tutoror oportunităților prestate companiile de catering la dispoziția oricărui client înregistrat într-un mod user friendly. Funcționalitățile de bază ale sistemului sunt:

înregistrarea utilizatorilor și asigurarea autorizării acestora;

înregistrarea deținătorului de local;

asignarea rolului de administrator a localului;

adăugarea informației despre local;

adăugarea unei noutăți;

adăugarea unui produs;

adăugarea meniurilor

adăugarea descrierii text;

atașarea de produse;

atașarea unei imagini;

afișarea tuturor meniurilor disponibile/ meniul zilei;

afișarea tuturor noutăților/ofertelor;

plasare de recenzii (note, comentarii);

panelul de administrare pentru gestionarea tuturor datelor aflate în baza de date.

4.1 Prezentarea platformei

Platforma de automatizare a procesului de comandă a serviciilor prestate de companiile de catering, în continuare prezentată sub numele „Easy Lunch”, reprezintă în sine un web site cu o interfața user-friendly. La prima accesare, utilizatorul vede pagina „Home” care constă dintr-o bară de elemente, fundal și o listă de meniuri disponibile.

Figura 4.1 – Pagina Home

Bara de top este alcătuită din următoarele elemente:

butonul – acasa (realizat sub logotipul site-ului);

vizualizarea tutoror meniurilor disponibile în mod detaliat;

coșul comenzilor;

butonul înregistare / logare.

4.2 Primii pași

Utilizarea platformei „Easy Lunch” necesită înregistrare. La înregistrare, utilizatorului îi sunt solicitate următoarele date:

numele utilizatorului *;

adresa email *;

parola (8 caractere alfanumerice) *;

numele;

prenumele;

genul (sexul);

numărul de telefon;

poză de profil;

* – câmpuri obligatorii

Forma de înregistrare arată în felul următor(fig.4.2):

Figura 4.2 – Forma de înregistrare

În cazul în care utilizatorul are deja un cont creat, acesta se poate autentifica, introducând credențialele sale introduse la înregistrare.

Figura 4.2 – Forma de autentificare

4.3 Interfața moderatorului localului

După logarea cu rol de moderator, utilizatorul va vizualiza interfața de administrare unde se vor expune la folosire următorul set de funcționalități (figura 4.3):

crearea și gestionarea produselor;

crearea și gestionarea meniurilor;

crearea și gestionarea a tipurilor de livrare;

gestionarea comenzilor.

Figura 4.3 – Interfața de administrare pentru moderator

4.3.1 Adăugarea unui meniu/produs

La adăugarea unui meniu (figura 4.3), moderatorul va fi nevoit sa introducă următoarele date:

titlu;

fotografie;

descriere;

preț;

produse.

Deasemenea, moderatorul poate atașa meniul unei zile specifice sau îl poate publica clienților cu ajutorul bifei „vizibil” (fig.4.4):

Figura 4.4 – Interfața de gestionare a meniului

De menționat faptul că pentru a crea un meniu, este nevoie de a avea produsele decrise anterior. Astfel, pentru a adaugă produsele necesare, moderatorul poate folosi interfața de gestionare a acestora. (figura 4.5) Fiecare produs are:

nume;

descriere;

tip;

cantitare (gr., buc., etc).

Figura 4.5 – Interfața de gestionare a produsului

4.4 Interfața clientului

După acesarea paginii de start a platformei, utilizatorului îi este expusă o listă de meniuri disponibile (fig.4.6). Așadar, putem observa că vizualizarea ofertelor nu necesită autentificare, însă crearea unei comenzi este realizată doar de către un utilizator logat în sistem.

Figura 4.6 – Lista meniurilor disponibile clientului

4.4.1 Plasarea unei comenzi

Odată logat, utilizatorul este în stare de a crea o comandă, prin adăugare de meniuri în coș (figura 4.8). Pentru a efectua această acțiune, în interfață este preconizat butonul „Adaugă in coș”, accesibil atât din lista de meniuri, cât și din fereastra modală a unui singur meniu (figura 4.7).

Figura 4.7 – Fereastra modală a unui meniu selectat

Figura 4.8 – Coșul utilizatorului

4.5 Interfața de administrare

Administratorul este utilizatorul cu cele mai multe privilegii în sistem și este creat la prima inițializare a platformei ca proprietar al localului. Acesta deține toate posibilitățile de gestionare pe care le are moderatorul, mai mult ca atât numai administratorul poate:

modifica rolul utilizatorilor în sistem;

edita, crea, deactiva și șterge utilizatori (figura 4.10);

gestiona profilele utilizatorilor (figura 4.11);

edita descrierea localului (figura 4.12);

crea și gestiona meniurile, produsele;

descrie zilele săptămânii (pentru opțiunea – meniul zilei);

descrie tipurile de produse;

crea și gestiona noutăți;

gestiona comenzi;

adăuga și modifica tipurile de livrare;

descrie și modifica starile în care se poate afla o comandă;

Figura 4.9 – Interfața de administrare

Figura 4.10 – Interfața de editare a unui utilizator

Figura 4.11 – Interfața de editare a profilului unui utilizator

Figura 4.12 – Interfața de editare a informației despre local

5 Evaluarea economică a proiectului

Această platformă de automatizare oferă posibilitate utilizatorilor informația într-un mod mai interactiv simplu si comod. Datorită acestei platforme clienții vor avea posibilitatea să micșoreze efortul și timpul utilizat pentru comandarea prânzului, astfel încât resursele economisite sa fie utilizate cu alt scop sau pentru a extinde timpul de odihnă pe parcursul pauzei de masă.

5.1 Scopul realizării proiectului din punct de vedere economic. Cercetările de marketing

Scopul economic al acestei aplicații constă în atragerea unui număr cât mai mare de utilizatori, atât clienți, cât și prestatori de servicii de catering. În acest mod, vor fi posibile câștigurile pe baza contractelor individuale sau suporturi. Din cauza faptului că nu există și alte platforme similare pe teritoriul R.M., lansarea aplicației va întâlni mai puține dificultăți, însă scopul aplicației (de a găsi un număr cât mai mare de potențiali cumpărători) va implica investiții de timp. Cea mai eficientă publicitate la moment o constituie mediul virtual, astfel că, pentru început, rețelele de socializare vor fi de mare ajutor. Principalul venit v-a fi axat pe venitul din vinderea aplicației, suport și dezvoltare.
Punctul forte al acestei aplicații constă în simplitate, atât pentru prestator cât și pentru client. Simplitatea se manifestă printr-o interfață intuitivă și prietenoasă pentru ambele parți, ceea ce permite o interacțiune vînzător-cumpărător mai plăcută și rapidă în procesul de comandă a prânzului.
Utilizatorul principal poate fi orice persoană ce deține un calculator, telefon etc , cu posibilitatea de conectare la internet. În vedetea exploatării acestei platfome, sunt necesare doar cunoștințele de bază în utilizarea calculatorului și internetului.

5.2 Planul calendaristic

Planul calendaristic al proiectului reprezintă aranjarea planificarea în timp a procesului de elaborare și repartizarea sarcinilor și resurselor. În dependență de durata proiectului, planul poate fi divizat în luni, săptămâni, zile, ore.

Etapele de planificare a timpului recomandate pentru proiect sunt cele din figura 5.1.

Figura 5.1 – Planificarea timpului

Obiectivele principale ale acestei aplicații sunt ca utilizatorul să lucreze cât de eficient posibil nu numai în cadrul orelor pentru ca mai apoi procesul ce învățământ să fie mai simplu și mai accesibil chiar și de la distanță.

Viteza funcționării acestei platforme este dependentă de canalul de conexiune, cu cât canalul este mai performat cu atît mai comod va fi livrat contentul de pe platforma.

Evaluarea volumului de lucru este reprezentată sub formă de tabelă în tabelul 5.1 cu rezervă de 10 zile.

Tabelul 5.1 – Evaluarea volumului de lucru

Durata acțiunii = data începerii – data finisării + rezerva de timp (zile)

Durata acțiunii = 08.03.18 – 25.05.18 = 69 zile

În tabelul 5.2 este prezentat planul calendaristic de activități pentru elaborarea aplicației, în care se specifică un șir de factori cum ar fi : Denumirea/Durata acțiunilor, executant, resursele necesare etc.

Tabelul 5.2 – Planul calendaristic pentru elaborarea proiectului de diplomă

5.3 Analiza SWOT

Analiza SWOT, presupune evaluarea punctelor forte și punctelor slabe ale proiectului. Acestea ne vor ajuta să identificăm raționalitatea proiectului, valorile economice și prezicerea succesului sau eșecului proiectului. Rezultatele analizei SWOT sunt reprezentate în tabelul 5.3.

Tabelul 5.3 – Rezultatele analizei SWOT

5.4 Cheltuieli materiale și nemateriale directe

În tabelul 5.4 și tabelul 5.5, sunt reprezentate cheltuielile materiale și nemateriale ce se referă la perioada de producere a aplicației.

Tabelul 5.4 – Active materiale pe termen lung

Tabelul 5.5 – Continuare la tabelul Active nemateriale pe termen lung

5.5 Consumuri directe

Tabelul 5.6 reprezintă toate materialele suplimentare ce au fost folosite adițional la crearea proiectului și au participat nemijlocit la dezvoltarea sa.

Consumuri directe de materiale – reprezintă valoarea materialelor, utilizate în procesul de producție incluse în costul produselor finite: elemente cu caracter material, utilizarea cărora este necesară în proiect.

Tabelul 5.6 – Consumuri directe de materiale

5.6 Cheltuieli directe privind retribuirea muncii

În cadrul acestui proiect au participat următorii actori: Programator.

Programatorul se va ocupa nemijlocit cu dezvoltarea și testarea produsului final. Acesta va fi nevoit să cunoască principiile programării orientate pe obiecte deoarece aplicația data va fi nevoită să se modifice sub cerințele utilizatorilor, și aceste principii ne permit încadrarea noilor funcționalități fără de a afecta codul vechi și funcționalul inițial. La fel programatorul va fi nevoit să cunoască principiile Testări Black și White Box. Programatorul a activat în acest proiect 3 luni a câte 8 ore lucrătoare pe zi. Conducătorul de proiect a activat 4 zile a câte 4 ore lucrătoare pe zi.

În tabelul 5.7 sunt reprezentate consumurile directe privind retribuirea muncii

Tabelul 5.7 – Consumurile directe privind retribuirea muncii

Fondul social= 39 600 x 23% = 9 108 lei

Conform „Legii bugetului asigurărilor sociale de stat pe anul 2018” nr. 129 din  23.12.2009 contribuția la bugetul asigurărilor sociale de stat obligatorii, suportată de angajator, constituie 23% din fondul de remunerare a muncii după formula 5.1:

AM = Frm x Cam(%) , (5.1)

Asigurarea medicală= 39 600 x 4,5% = 1 782 lei

unde: Cam – Cota primei de asigurare obligatorie de asistență medicală, se aprobă fiecare an prin Legea Republicii Moldova „Privind fondurile asigurării obligatorii de asistență medicală”

Conform „Legii privind fondurile asigurării obligatorii de asistență medicală pe anul 2018” nr. 128-XVIII din  23.12.2009, cota primei de asigurare obligatorie de asistență medicală suportată de angajator constituie 4,5% din fondul de salarizare. Suma Consumuri directe privind retribuirea muncii după formula 5.2:

FRMT = Frm + FS + AM (5.2)

FRMTotal= 39 600 + 1 782 + 9 108 = 50 490 lei

Se admit anumite premii si adaosuri la FSB.
În acest Compartiment se va calcula venitul net anual și suma impozitului pe venit anual a unuia din angajați care este implicat.
Pentru anul 2018 sunt planificate următoarele taxe și scutiri la venituri persoane fizice.
Impozit pe venit:

pentru venituri anuale de până la 33 000 lei se aplică cota de impozitare 7%;

pentru venituri mai mari de 33 000 lei se aplică cota de impozitare 18%;

fondul de pensionare 6 % din venit;

fondul de Asigurare Medicală 4.5 % din venit.

Suma scutirii personale 11 280 lei.
Suma pentru persoana întreținută 2520 lei.
Suma scutirii personale majore 16 800 lei.

Se vor efectua calculele pentru salariul primit de către Programator în cadrul proiectului prezentat. Pe parcursul proiectului care a durat 3 luni programatorul a beneficiat de un salariu de 39 600 lei, lunar salariul a constituit 13 200 lei.

Salariul anual = 13 200 x 12 = 158 400 lei

Se admite că salariul brut al Programatorului este de 158 400 lei. Astfel utilizăm cotele de impozitare actuale pe 2018 v-om calcula venitul net anual și respectiv suma impozitului pe venit transferat la bugetul de stat.
Calculăm reținerile în fondul social FS și contribuții asigurări medicale (FAM):

FP=6% x 158 400 = 9 504 lei;

FAM=4.5% x 158 400 = 7 128 lei.

Urmează calculul venitului impozabil dupa formula 5.3:

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

Unde: VI – venitul impozabil, VB – venitul brut, FP – fondul de pensionare (asigurări sociale), FAM – fondul de Asigurare Medicală, SP – scutirea personală, SiP – scutirea pentru persoană întreținută, SM – scutirea personală majoră.

VI = 158 400 – 9 504 – 7 128 – 11 280 = 130 488 lei

Se calculează suma venitului net aplicând cotele de impozitare după formula 5.4:

VN=VB-IV-FP-FAM (5.4)

Unde: IV – impozit pe venit.

IV=VI-I=33 000 x 7%+(130 488 – 33 000) x 18% = 19 858 lei

Pentru venituri anuale de pînă la 33 000 lei – se aplică cota de impozitare 7%.

Pentru venituri mai mari de 33 000 lei – se aplică cota de impozitare 18%.

VN=158 400 – 9 504 – 7 128 – 19 858 = 121 910 lei

5.7 Cheltuieli indirecte de producție

Cheltuielile indirecte de producție reprezentate în tabelul 5.8 presupun cheltuielile ce au fost incluse în costul aplicației soft, se referă cheltuielile pentru electricitatea care a fost consumată de calculator sau altor servicii în timpul elaborării aplicației.

Tabelul 5.8 – Consumuri indirecte

Calculul pentru consum-ul de energie electrică:

S-au folosit 2 becuri cu puterea de 75 Wt fiecare și 1 calculator cu puterea de 100 Wt. 2 x 75 + 100 = 150 + 100 =0.250 kW/ora;

durata proiectului: 69 zile x 8 ore = 552 ore;

costul energiei electrice consumate în lei: 552 ore x 0.250 kW/ora x 1,92 lei (Tariful pentru 1 kW/ora) = 480 lei.

Calculul pentru consumul serviciilor Internet:

Internet = 135 Lei/lună x 3 luni = 405 Lei.

Calculul servicii Transport:

Transport public 70 Lei Abonament x 3 Luni = 210 Lei

Fondul de amortizare. Pe parcursul modelării și dezvoltării aplicației sa folosit calculator, timpul de amortizare a calculatorului este de 3 ani. Calculul amortizării a fost efectuat utilizînd metoda liniară 5.5:

FAcalc = V: T x T1 (5.5)

Unde: V – suma care trebuie sa fie amortizată, T1 – durata proiectului, T – durata utilizării activului.

FAcalc = 7000 : 60luni(5ani) x 3 luni = 350 lei

Norma de amortizare a calculatorului pe parcursul elaborării este de 350 Lei.

FA Total = 350 lei

Costul de Producție. În tabelul 5.9 se prezintă cheltuielile care au fost efectuate pentru producerea produsului final de către agentul economic ce se ocupă de dezvoltarea aplicației.

Tabelul 5.9 – Costul de producție

5.8 Rezultatele financiare

Preț de realizare. Având la dispoziție prețul de cost al unei copii de produs se poate de determinat prețul de realizare pe piață a programului elaborat metoda „bottom-up”.

Metoda „bottom-up” (formula 5.6) conform metodei: presupunem că se așteaptă la un profit de 10%

Preț brut = Preț de cost + Profit (5.6)

Preț brut = 52 023 + 52 023 x 10% = 57 225 lei

Preț de realizare = Preț brut + TVA

Preț de realizare = 57225 + 11445 = 68 670 lei

Rentabilitatea = 57 225 / 52 023 x 100% = 110 %

5.9 Caracteristica generală a sistemului de planificare a platformei de automatizare

Proiect – un proces unic, constând într-o mulțime de activități coordonate și controlate, cu termene de începere și de terminare, care garantează realizarea unui obiectiv conform cerințelor specificate incluzând restricții de timp, cost, resurse.

Toate proiectele implică patru faze:

concepția;

planificarea;

realizarea;

încheierea.

Faza de concepție – această fază este crucială, scopul ei fiind definirea elementelor caracteristice ale proiectului, necesare pentru ca forul decizional al firmei, eventual și finanatorul, să poată lua o decizie privind implicarea în acest proiect. Dacă decizia este pozitivă, începe a doua fază, cea de planificare detaliată. Dacă nu, proiectul se termină înainte de a implica firma în cheltuieli inutile. În studiul care se realizează trebuie să fie pusă în evidență următorii factori:

capacitatea firmei de a realiza proiectul în timpul cerut;

costul final al proiectului;

cheltuielile implicate;

bugetul cerut pentru proiect;

specificaiile proiectului.

În concluzie, în faza de concepție a unui proiect sunt definii parametrii proiectului în termeni clari i neambigui iar proiectul trebuie să fie acceptat de beneficiar.

Faza de planificare:

După aprobarea derulării proiectului începe a doua fază – planificarea detaliată a acestuia, definindu-se abordarea informațională a proiectului, sarcinile proiectului precum și organizarea resurselor și proceselor. Prin planificare se vor stabili etapele de execuție și momentul execuției acestora, resursele necesare și momentele la care trebuie să fie disponibile, pe ce buget se mizează. O bună planificare va necesita timp și resurse, dar va salva firma de la cheltuielii inutile și vor fi evitate multe erori în momentul realizării proiectului.

Faza de realizare:

În această fază activitățile cheie pentru managerul de proiect sunt monitorizarea permanentă a activităților și a costurilor, evaluarea periodică a progresului realizat în desfășurarea proiectului și introducerea unor acțiuni de corectare atunci când este cazul. Un proiect nu se realizează exact conform planificării, dar nerespectarea planificării va conduce la evoluții necontrolate ale proiectului. Controlul realizării proiectului este extrem de important. În primul rând se realizează un control al timpului. Acesta indică:

dacă sunt respectate sau nu termenele pentru activități;

dacă sunt multe sarcini prioritare pe listă;

dacă sunt necesare resurse suplimentare pentru a sprijini sectoare critice.

Faza de terminare (de încheiere):

În această fază sunt apreciate informațiile utile privind evaluarea proiectului. Aceste informații includ:

dacă metoda utilizată a avut succes;

performanțele echipei de lucru și “a fost sau nu acest proiect un succes?”.

Un proiect are succes dacă este realizat în timpul prevăzut, cu resursele alocate și la nivelul de performanță dorit.

Concluzii

Planul de dezvoltare al platformei a fost inițiat print-un studiu orientat spre nivelul serviciilor de catering și a comerțului electronic din Republica Moldova. Menționez că am analizat piața actuală în vederea identificării potențialilor concurenți, lucru ce mi-a permis să stabilesc obiectivele de bază ale proiectului, dar și direcția optimă de dezvoltare, care ar asigura un succes pe termen lung.

Din experiența proprie în calitate de utilizator a serviciilor de catering, mi-am propus să evidențiez atât punctele forte, cât și punctele slabe ale platformelor existente pe piață, pentru a deduce “pilonii” principali care vor susține proiectul la etapa de lansare, dar și pentru a sublinia greșelile comune ce trebuie omise. Prin urmare, am constatat că deși platformele existente dispun de un număr imens de companii partenere și clasificări după tipul de mâncare, livrarea business-lunch-urilor ar fi dificilă din cauza timpului îndelungat de livrare, nemaivorbind de taxa exagerată de livrare. Deci scopul proiectului nu implică concurența cu acestea, ci, mai degrabă, crearea un teren comun pentru clienți si prestatori de servicii, care ar asigura o comunicare avantajoasă pentru ambele parți.

Realizarea platformei a fost posibilă datorită utilizării intrumentelor, cum ar fi: PyCharm, Django Framework, Nginx, PostgreSql, Valentina Studio, Git etc.; instrumente ce au permis proiectarea componentei funcționale responsabile de creare și rularea proiectul, versionarea lui, proiectarea și gestionarea bazei de date etc.

Paralel, am acordat o atenție deosebită și interfeței grafice, axată pe un mod de interacțiune simplu și placut cu utilizatorul. Caracterul prietenos și intuitiv al interfeței grafice este corelat cu creșterea numărului de vizitatori/utilizatori, respectiv fidelizarea clientelei.

Anexa A

Lista de dependențe

Django==2.0.5

django-cors-headers==2.2.0

django-environ==0.4.4

django-filter==1.1.0

django-modeltranslation==0.13b1

django-upload-validator==1.0

djangorestframework==3.8.2

djangorestframework-jwt==1.11.0

argon2-cffi==18.1.0

coreapi==2.3.3

Markdown==2.6.11

Pillow==5.1.0

pytz==2018.4

*django-debug-toolbar==1.9.1

*django-extensions==2.0.7

*ipython==6.3.1

python_version = "3.6"

* dependențe necesare doar în procesul de dezvoltare a sistemului.

Anexa B

Lista de url patters

Rutele aplicației de bază:

from django.conf import settings

from django.conf.urls import include, url

from django.contrib import admin

from django.urls import path

urlpatterns = [

path(settings.ADMIN_URL, admin.site.urls),

path('v1/', include('apps.users.urls')),

path('v1/', include('apps.places.urls')),

path('v1/', include('apps.orders.urls')),

path('v1/', include('apps.news.urls')),

]

Rutele adiționale folosite doar în procesul de dezvoltare a aplicației:

if settings.DEBUG:

urlpatterns += [

url(r'^400/$', default_views.bad_request, kwargs={'exception': Exception('Bad Request!')}),

url(r'^403/$', default_views.permission_denied, kwargs={'exception': Exception('Permission Denied')}),

url(r'^404/$', default_views.page_not_found, kwargs={'exception': Exception('Page not Found')}),

url(r'^500/$', default_views.server_error),

]

if 'debug_toolbar' in settings.INSTALLED_APPS:

import debug_toolbar

urlpatterns = [url(r'^__debug__/', include(debug_toolbar.urls))] + urlpatterns

Rutele aplicației utilizatorilor:

from django.urls import include, path

from rest_framework.routers import SimpleRouter

from rest_framework_jwt.views import refresh_jwt_token, verify_jwt_token

from . import views

router = SimpleRouter(trailing_slash=False)

router.register('admin/users', views.UserViewSet)

urlpatterns = [

path('users/login', views.ObtainJSONWebToken.as_view(), name='jwt-login'),

path("users/me", views.UserProfileView.as_view(), name="client-profile"),

path('users/register', views.UserRegistrationView.as_view(), name='user-registration'),

path('users/password/reset', views.UserResetPasswordView.as_view(), name='user-password-reset'),

path('users/password/modify', views.UserModifyPasswordView.as_view(), name='user-password-modify'),

path('users/transaction/<uuid:pk>/apply', views.UserTransactionApplyView.as_view(), name='user-transaction-apply'),

path('users/token/verify', verify_jwt_token),

path('users/token/refresh', refresh_jwt_token),

path("", include(router.urls)),

]

Rutele aplicației noutăților:

from django.urls import path

from . import views

urlpatterns = [

path('news', views.NewsListView.as_view()),

path('news/<uuid:pk>', views.NewsRetrieveView.as_view())

]

Rutele aplicației comenzilor:

from django.urls import include, path

from rest_framework import routers

from . import views

router = routers.DefaultRouter(trailing_slash=False)

router.register('admin/orders/deliveries', views.DeliveryViewSet)

router.register('admin/orders/statuses', views.OrderStatusViewSet)

router.register('admin/orders', views.OrderViewSet)

urlpatterns = [

path('', include(router.urls)),

path('orders', views.OrderListCreateView.as_view()),

path('orders/deliveries', views.DeliveryListView.as_view())

]

Rutele aplicației localului:

from django.urls import include, path

from rest_framework import routers

from . import views

router = routers.DefaultRouter(trailing_slash=False)

router.register('admin/place/days', views.DayViewSet)

router.register('admin/place/product/types', views.ProductTypeViewSet)

router.register('admin/place/products', views.ProductViewSet)

router.register('admin/place/menus', views.MenuViewSet)

urlpatterns = [

path('', include(router.urls)),

path('place', views.PlaceListView.as_view()),

path('place/menus', views.MenuListView.as_view()),

path('admin/place', views.PlaceOwnerView.as_view()),

]

Anexa C

Lista de funcții și clase pentru gestionarea utilizatorilor

Fișerul views.py:

from django.contrib.auth import get_user_model

from django.utils.translation import ugettext_lazy as _

from rest_framework import generics, mixins, permissions, status, viewsets

from rest_framework.response import Response

from rest_framework_jwt.views import JSONWebTokenAPIView

from . import models, serializers

class UserViewSet(mixins.ListModelMixin,

mixins.RetrieveModelMixin,

mixins.UpdateModelMixin,

viewsets.GenericViewSet):

"""

API View set for admin user to manage all users info

"""

queryset = get_user_model().objects.all()

serializer_class = serializers.AdminUserSerializer

permission_classes = (permissions.IsAuthenticated, permissions.IsAdminUser)

class ObtainJSONWebToken(JSONWebTokenAPIView):

"""

API View that receives a POST with a user's username and password.

Returns a JSON Web Token that can be used for authenticated requests.

"""

serializer_class = serializers.CustomJSONWebTokenSerializer

class UserRegistrationView(generics.CreateAPIView):

queryset = get_user_model().objects

serializer_class = serializers.UserRegisterSerializer

class UserTransactionApplyView(generics.GenericAPIView):

""" View for applying transactions for users"""

queryset = models.Transaction.objects

serializer_class = serializers.UserRegisterSerializer

def get(self, request, *args, **kwargs):

transaction = self.get_object()

try:

transaction.apply()

except transaction.ExpiredTransaction:

msg = _("This transaction was expired")

return Response({"detail": msg}, status=status.HTTP_400_BAD_REQUEST)

return Response(status=status.HTTP_200_OK)

def post(self, request, *args, **kwargs):

transaction = self.get_object()

try:

transaction.apply(*args, request=request, **kwargs)

except transaction.ExpiredTransaction:

msg = _("This transaction was expired")

return Response({"detail": msg}, status=status.HTTP_400_BAD_REQUEST)

return Response(status=status.HTTP_200_OK)

class UserResetPasswordView(generics.GenericAPIView):

""" Init user password reset procedure"""

serializer_class = serializers.ResetPasswordInitSerializer

def post(self, request, *args, **kwargs):

serializer = self.get_serializer(data=request.data)

serializer.is_valid(raise_exception=True)

serializer.save()

return Response(status=status.HTTP_200_OK)

class UserModifyPasswordView(generics.GenericAPIView):

""" Modify Password for authenticated user"""

serializer_class = serializers.UserModifyPasswordSerializer

permission_classes = (permissions.IsAuthenticated,)

def post(self, request, *args, **kwargs):

serializer = self.get_serializer(data=request.data)

serializer.is_valid(raise_exception=True)

serializer.save()

return Response(status=status.HTTP_200_OK)

class UserProfileView(generics.RetrieveUpdateAPIView):

"""Retrieve and Update user profile """

serializer_class = serializers.UserProfileSerializer

permission_classes = (permissions.IsAuthenticated,)

def get_object(self):

return self.request.user

Fișerul serializers.py:

from django.contrib.auth import authenticate, get_user_model, password_validation

from django.utils.translation import ugettext as _

from rest_framework import exceptions, serializers

from rest_framework.generics import get_object_or_404

from rest_framework_jwt.serializers import JSONWebTokenSerializer

from rest_framework_jwt.settings import api_settings

from . import models

class CustomJSONWebTokenSerializer(JSONWebTokenSerializer):

""" Serializer is modified for handling is_confirmed on user model """

def validate(self, attrs):

jwt_payload_handler = api_settings.JWT_PAYLOAD_HANDLER

jwt_encode_handler = api_settings.JWT_ENCODE_HANDLER

credentials = {

self.username_field: attrs.get(self.username_field),

'password' : attrs.get('password')

}

if all(credentials.values()):

user = authenticate(**credentials)

if user:

if not user.is_active:

msg = {"detail": _('User account is disabled.')}

raise serializers.ValidationError(msg)

if not user.is_confirmed:

msg = {"detail": _('User account is not confirmed.')}

raise serializers.ValidationError(msg)

payload = jwt_payload_handler(user)

return {

'token': jwt_encode_handler(payload),

'user' : user

}

else:

msg = _('Unable to log in with provided credentials.')

raise serializers.ValidationError(msg)

else:

msg = _('Must include "{username_field}" and "password".')

msg = msg.format(username_field=self.username_field)

raise serializers.ValidationError(msg)

class UserRegisterSerializer(serializers.ModelSerializer):

""" Serializer is user for user registration """

password = serializers.CharField(style={'input_type': 'password'}, write_only=True)

class Meta:

model = get_user_model()

fields = ("username", "email", "password")

extra_kwargs = {

"email": {"required": True}

}

def validate_password(self, value):

password_validation.validate_password(value, self.instance)

return value

def create(self, validated_data):

user_model = self.Meta.model

user = user_model.objects.create_user(**validated_data)

user.create_transaction("PostRegistrationConfirmAction")

return user

class ResetPasswordInitSerializer(serializers.Serializer):

""" Serializer is user for user reset password process """

email = serializers.EmailField()

def update(self, instance, validated_data):

pass

def create(self, validated_data):

email = validated_data.get('email')

user = get_object_or_404(get_user_model(), email=email)

user.create_transaction('ResetPasswordAction')

return email

class ResetUserPasswordSerializer(serializers.Serializer):

password = serializers.CharField(style={'input_type': 'password'}, write_only=True)

def update(self, instance, validated_data):

pass

def create(self, validated_data):

pass

def validate_password(self, value):

password_validation.validate_password(value, self.instance)

return value

class UserModifyPasswordSerializer(serializers.Serializer):

""" This serializer is used for modifying user password """

old_password = serializers.CharField(style={'input_type': 'password'}, write_only=True)

new_password = serializers.CharField(style={'input_type': 'password'}, write_only=True)

def validate_new_password(self, value):

password_validation.validate_password(value, self.instance)

return value

def create(self, validated_data):

user = self.context['request'].user

old_password, new_password = validated_data.values()

if user.check_password(old_password):

user.set_password(new_password)

user.save(update_fields=['password'])

else:

msg = {'detail': _('Wrong Input data')}

raise exceptions.ValidationError(msg)

return user

def update(self, instance, validated_data):

pass

class ProfileSerializer(serializers.ModelSerializer):

""" Serializer is used for Retrieving user's profile """

class Meta:

model = models.Profile

exclude = ('id', 'user', 'created_at', 'updated_at')

extra_kwargs = {

"first_name": {"required": True},

"last_name" : {"required": True}

}

class UserProfileSerializer(serializers.ModelSerializer):

""" Serializer is used for Retrieving and Updating user info and profile """

profile = ProfileSerializer()

class Meta:

model = models.User

fields = ("username", "email", 'profile')

extra_kwargs = {

"username": {"read_only": True},

"email" : {"required": True}

}

def update(self, instance, validated_data):

email = validated_data.get('email')

profile = validated_data.get('profile')

if email:

instance.email = email

instance.save()

if profile:

instance.profile.populate_profile(profile)

instance.profile.save()

return instance

class AdminUserSerializer(serializers.ModelSerializer):

""" Serializer is used for listing general info about user"""

profile = ProfileSerializer(read_only=True)

class Meta:

model = models.User

fields = ("id", "username", "email", "profile", "is_active", "is_confirmed")

extra_kwargs = {

"username" : {"read_only": True},

"email" : {"read_only": True},

"is_active" : {"required": True},

"is_confirmed": {"required": True},

}

Fișerul actions.py:

from django.core.mail import send_mail

from apps.users import serializers

from . import utils

class PostRegistrationConfirmAction(utils.GenericAction):

name = 'Post Registration Confirm email Action'

description = 'Action for sending confirmation email after user register and confirm after access'

def apply(self):

user = self.get_object()

user.is_confirmed = True

user.save(update_fields=['is_confirmed'])

def post_create(self):

send_mail(

subject="Confirmation Email",

message=f'{self.obj.id}',

from_email='support@easylunch.com',

recipient_list=[f'{self.obj.user.email}']

)

class ResetPasswordAction(utils.GenericAction):

name = 'User reset password'

description = 'Action for resenting user password'

serializer_class = serializers.ResetUserPasswordSerializer

def apply(self):

# Extract data

user = self.get_object()

request = self.settings.get('request')

# Validate input data

serializer = self.get_serializer(data=request.data)

serializer.is_valid(raise_exception=True)

password = serializer.validated_data.get('password')

# Set data

user.set_password(password)

user.save(update_fields=['password'])

def post_create(self):

send_mail(

subject="Confirmation Email",

message=f'{self.obj.id}',

from_email='support@bookmarks.com',

recipient_list=[f'{self.obj.user.email}']

)

def get_serializer(self, *args, **kwargs):

"""

Return the serializer instance that should be used for validating and

deserialized input, and for serializing output.

"""

serializer_class = self.serializer_class

return serializer_class(*args, **kwargs)

Fișerul utils.py:

class ExpiredTransaction(Exception):

""" Exception for showing expired or non valid transaction"""

pass

def camel_case_split(identifier):

import re

matches = re.finditer('.+?(?:(?<=[a-z])(?=[A-Z])|(?<=[A-Z])(?=[A-Z][a-z])|$)', identifier)

return [m.group(0) for m in matches]

class GenericAction:

name = ''

description = ''

def __init__(self, obj, *args, **kwargs) -> None:

self.obj = obj

self.settings = {

"arguments": [*args],

}

self.settings.update(kwargs)

def apply(self):

raise NotImplementedError

def execute(self):

self.pre_execute()

self.apply()

self.post_execute()

self.log_action()

def pre_execute(self):

pass

def post_create(self):

"""Method that is ex after transaction created"""

pass

def post_execute(self):

pass

def log_action(self):

pass

def get_object(self):

"""Return a target object from transaction"""

return self.obj.user

def __str__(self) -> str:

if not self.name:

self.name = " ".join(camel_case_split(self.__class__.__name__)[:-1]) # if not name put class name s

return f"{self.name}: {self.description}"