Diagrame de analiză

Diagramele de mai jos descriu Taraba din unghiurile pe care le folosește un analist de business: ce limite are sistemul, cine îl folosește și pentru ce, cum circulă datele, ce concepte există și cum se desfășoară pașii. Fiecare respectă convențiile notației ei și are o legendă proprie în colț.

Cum le folosești. Un clic (sau Enter) pe orice diagramă din documentație o deschide într-o fereastră cu zoom (rotița mouse-ului, butoanele sau + / −), deplasare prin tragere, încadrare automată (0) și ecran complet (F). ▶ Redă construiește diagrama pas cu pas, în ordinea fluxului. Descarcă oferă SVG (vectorial), PNG sau JPG (imagine la rezoluție dublă) și GIF animat, potrivit pentru prezentări.

Ce diagramă răspunde la ce întrebare

Diagramă	Întrebarea	Pentru cine
Context	Unde se termină Taraba și cu ce comunică?	toată lumea, la începutul oricărei discuții
Cazuri de utilizare	Cine folosește aplicația și ce obiective are?	business, testare, specificații
DFD	Ce date intră, unde se păstrează, unde ies?	business, securitate, GDPR
ERD conceptual	Ce concepte există și cum se leagă?	business și echipa tehnică, vocabular comun
Activitate	Care sunt pașii unei funcționalități, cu ramificații și paralelism?	analiză, dezvoltare, testare
BPMN	Cum curge un proces de business între departamente?	management, operațiuni
Secvență	În ce ordine comunică părțile sistemului?	echipa tehnică, arhitectură

---

Diagrama de context a sistemului

Ce arată. Taraba ca o singură cutie, în centru: sus, cei patru utilizatori (persoane); în jur, sistemele externe cu care comunică. Fiecare linie spune ce schimbă și prin ce (protocolul, între paranteze drepte).

Cum o citești. Notația C4, nivelul 1: persoanele au forma unui om, sistemul descris e colorat, sistemele externe sunt gri. Liniile punctate marchează integrările simulate azi (plăți, curieri, SMS și push), planificate pentru lansare.

Ce reiese.

• Scope-ul proiectului: tot ce e în interiorul cutiei centrale se construiește aici; tot ce e în afară se integrează.
• Trei integrări critice lipsesc încă în formă reală și sunt cele mai mari riscuri de lansare: procesatorul de plăți, curierii și furnizorul de SMS.
• Verificarea firmelor la ONRC / ANAF e manuală, făcută de echipă, nu o integrare.

Diagrame de cazuri de utilizare

Site-ul public

Cum o citești. Actorii (omuleți) stau în afara chenarului sistemului; elipsele sunt obiectivele lor. O linie simplă: actorul participă la caz. Săgeata cu triunghi gol înseamnă moștenire: Cumpărătorul poate tot ce poate un Vizitator, iar Vânzătorul firmă poate tot ce poate un Vânzător. «include» marchează un pas obligatoriu, refolosit: atât cumpărarea, cât și promovarea includ plata.

Ce reiese. Cumpărătorul are cele mai multe obiective (zece), deci acolo se concentrează testarea. Firmele au două obiective în plus față de persoanele fizice: datele firmei și confirmarea retururilor, adică dreptul de retragere.

Backoffice

Ce reiese. Moderatorul și suportul împart verificarea identității și a firmelor (liniile se intersectează exact acolo). Financiarul are un perimetru mic și clar (plăți, rapoarte), iar administratorul are, în plus, configurarea platformei; detaliile pe permisiuni sunt în matricea rolurilor.

CRM

Ce reiese. Marketingul pregătește; timpul (planificatorul) trimite. Atât campaniile, cât și automatizările includ aceleași reguli de acord, plafoane și ore de liniște: nicio cale de trimitere nu le ocolește. Clientul apare ca actor pentru că dezabonarea e un drept al lui, nu o setare internă.

Diagrame ale fluxurilor de date (DFD)

Nivelul 0: contextul datelor

Cum o citești. Notația Gane–Sarson: dreptunghiurile cu umbră sunt entități externe (de unde vin și unde pleacă datele), dreptunghiul rotunjit numerotat e un proces, iar fiecare săgeată e etichetată cu datele care circulă (nu cu acțiuni). Perechile de săgeți paralele arată ce intră și ce iese pentru același participant.

Ce reiese. Datele cele mai sensibile care intră sunt datele cardului (doar în tranzit, nu se salvează) și datele firmelor; cele care ies spre exterior sunt mesajele (e-mail, SMS, push) și cererile către procesatorul de plăți.

Nivelul 1: piața

Cum o citești. Procesele 1.0–6.0 descompun platforma; depozitele de date (dreptunghiurile deschise D1–D4) arată unde se păstrează datele între procese. Un proces nu comunică direct cu un depozit al altui proces fără o săgeată explicită. Vânzătorul apare de două ori (al doilea are o linie în colț, semnul de duplicat), ca diagrama să rămână lizibilă.

Ce reiese.

• Moderarea (2.0) e singura cale prin care un anunț ajunge „activ” în D1; căutarea (3.0) citește doar anunțurile active.
• Banii vânzătorului (6.0) depind de comanda finalizată (5.0) și de IBAN-ul din D4: fără IBAN, plata nu pleacă.
• Pentru GDPR: datele personale stau în D4 (utilizatori) și D2 (adresa de livrare din comenzi); exportul și ștergerea contului le acoperă pe amândouă.

Diagrama conceptuală a datelor

Cum o citești. Fiecare cutie e un concept de business (nu un tabel); fiecare linie se citește ca o propoziție, cu verbul pe ea. Simbolurile de la capete („crow's foot”) dau cardinalitatea la capătul fiecărui concept:

Simbol	Înseamnă
două liniuțe	exact unu
cerc și liniuță	zero sau unu
liniuță și „furculiță”	unu sau mai mulți
cerc și „furculiță”	zero sau mai mulți

Exemple: un Utilizator publică zero sau mai multe Anunțuri; un Anunț are una până la zece Fotografii; un Anunț se vinde prin zero sau o Comandă; o Comandă poate avea zero sau o Dispută.

Ce reiese. Anunțul și comanda sunt cele două centre ale modelului. Comanda e strict „una pe anunț” (produsele second-hand sunt unicat), ceea ce face posibilă blocarea împotriva vânzării duble. Modelul tehnic complet, cu toate tabelele și coloanele, e în modelul de date.

Diagrame de activitate

Checkout și plata

Cum o citești. Coloanele (partițiile) arată cine face fiecare pas. Cercul plin e începutul, cercul dublu e sfârșitul, iar cercul cu X oprește doar ramura respectivă. Romburile sunt decizii, cu condițiile între paranteze drepte; barele groase marchează pași care se fac în paralel (ramificare), respectiv așteptarea tuturor (sincronizare). Formele cu vârf sunt notificări trimise.

Ce reiese. Cele două notificări (cumpărător și vânzător) pleacă în paralel, după ce comanda e salvată. O plată refuzată oprește doar ramura cumpărătorului: anunțul nu rămâne blocat.

Publicarea unui anunț

Ce reiese. Datele invalide se întorc la vânzător înainte de orice moderare (bucla „[nu]”), deci moderatorii nu primesc anunțuri incomplete. Decizia moderatorului are trei ieșiri, fiecare cu efect diferit: publicare pe 30 de zile, cerere de modificări (runda se încheie, editarea pornește una nouă) sau respingere motivată.

Dreptul de retragere

Ce reiese. Prima decizie filtrează tot: doar comenzile de la firme, în 14 zile de la primire. Apoi trimiterea produsului și notificarea vânzătorului se întâmplă în paralel, iar rambursarea vine după confirmarea vânzătorului, de aceea plata vânzătorului stă suspendată până atunci.

Celelalte diagrame

• BPMN (17 procese de business, cu benzi pe departamente și calculul complexității): Procese.
• Secvență (6 fluxuri tehnice în notația UML, cu apeluri sincrone, răspunsuri și bare de activare): Fluxuri tehnice.
• Stări (anunț și comandă): Fluxuri tehnice.
• Arhitectură și containere: Arhitectura.

Toate diagramele sunt generate din cod (docs/tools/), din aceeași sursă ca textul, deci rămân sincronizate cu aplicația: pnpm docs:generate.