Proiectarea unei aplicații

Proiectarea unei aplicații începe cu o problemă clară, utilizatori și date. Pentru o aplicație care ține evidența cărților împrumutate, stabilim ce cărți și cititori memorăm, ce acțiuni sunt permise și ce rezultate trebuie afișate. Apoi împărțim aplicația în componente și definim cum comunică.

Proiectarea unei aplicații începe cu o problemă clară, cu utilizatori și cu date. Etapele sunt: cerința (ce trebuie să facă aplicația și pentru cine), modelul datelor (ce entități și ce legături se memorează), operațiile permise și regulile lor, împărțirea în componente (interfață, logică, date) și modul în care comunică, apoi testarea pe scenarii. Documentează datele de intrare, rezultatele și erorile așteptate. O implementare poate fi în consolă, grafică sau web; alegerea nu schimbă regulile aplicației. Regula de disponibilitate a unei cărți se păstrează în logica și în datele aplicației, nu doar în interfață, pentru că altfel altă cale de acces ar putea să o încalce.

Exemplul 1 — logica unui împrumut. Aplicația ține evidența cărților împrumutate. Regula: o carte poate fi împrumutată dacă este disponibilă. Un test concret: cartea A este liberă, Ana o împrumută, apoi Dan încearcă același lucru; al doilea împrumut trebuie respins, iar după returnare, Dan poate împrumuta cartea:

disponibile = {"A": True}
imprumuturi = []

def imprumuta(carte, cititor):
    if not disponibile.get(carte, False):
        return "Respins: cartea " + carte + " nu este disponibilă"
    disponibile[carte] = False
    imprumuturi.append((carte, cititor))
    return "Înregistrat: " + cititor + " are cartea " + carte

def returneaza(carte):
    disponibile[carte] = True

print(imprumuta("A", "Ana"))
print(imprumuta("A", "Dan"))
returneaza("A")
print(imprumuta("A", "Dan"))
print(len(imprumuturi))

Se afișează Înregistrat: Ana are cartea A, apoi Respins: cartea A nu este disponibilă, apoi Înregistrat: Dan are cartea A, iar ultima linie este 2: au fost înregistrate două împrumuturi, cel respins nu a modificat evidența. Funcția poate fi testată fără interfață, iar consola, o fereastră sau o pagină web o pot apela la fel.

Exemplul 2 — aceeași regulă în date. Modelul are tabelele carti, cititori și imprumuturi. Un index unic parțial garantează că, pentru fiecare carte, există cel mult un împrumut activ, adică nereturnat:

CREATE TABLE carti (id text PRIMARY KEY, titlu text NOT NULL);
CREATE TABLE cititori (id integer PRIMARY KEY, nume text NOT NULL);
CREATE TABLE imprumuturi (id integer PRIMARY KEY,
                          carte_id text NOT NULL REFERENCES carti(id),
                          cititor_id integer NOT NULL REFERENCES cititori(id),
                          returnat boolean NOT NULL DEFAULT false);
CREATE UNIQUE INDEX un_imprumut_activ ON imprumuturi (carte_id) WHERE NOT returnat;
INSERT INTO carti VALUES ('A', 'Enigma Otiliei');
INSERT INTO cititori VALUES (1, 'Ana'), (2, 'Dan');
INSERT INTO imprumuturi (id, carte_id, cititor_id) VALUES (1, 'A', 1);
INSERT INTO imprumuturi (id, carte_id, cititor_id) VALUES (2, 'A', 2);
UPDATE imprumuturi SET returnat = true WHERE id = 1;
INSERT INTO imprumuturi (id, carte_id, cititor_id) VALUES (2, 'A', 2);
SELECT COUNT(*) FROM imprumuturi;

Primul împrumut al cărții A reușește. Al doilea, pentru Dan, este respins de indexul unic, cât timp împrumutul Anei nu este returnat. După UPDATE, împrumutul Anei nu mai este activ, deci același INSERT pentru Dan reușește. Ultima interogare întoarce 2. Regula este acum protejată și în baza de date, nu doar în cod.

Prezentarea proiectului. Se arată un flux complet și limitele lui: se selectează cartea A, se înregistrează împrumutul Anei, se încearcă împrumutul lui Dan și se explică mesajul primit. Prezentarea demonstrează cerința rezolvată și testul relevant, nu doar ecranele aplicației.

Exemplul 3 — scenarii de testare. Pentru aplicația de împrumuturi, cerința „o carte se împrumută doar dacă este disponibilă” se transformă în scenarii cu rezultat așteptat, scris înainte de rulare:

1. Cartea A este liberă, iar Ana o împrumută: rezultat Înregistrat: Ana are cartea A, iar len(imprumuturi) este 1.
2. Ana nu a returnat cartea, iar Dan cere cartea A: rezultat Respins, iar len(imprumuturi) rămâne 1.
3. Ana returnează cartea, apoi Dan o cere: rezultat Înregistrat, iar lungimea devine 2.
4. Se cere o carte care nu există în evidență, de pildă "Z": funcția întoarce tot Respins, pentru că disponibile.get("Z", False) dă fals. Mesajul este însă înșelător, deoarece spune că cartea nu este disponibilă, nu că nu există. Aplicația bună distinge cele două cazuri printr-un mesaj separat.

Un scenariu are trei părți: starea de la care se pornește, acțiunea și rezultatul așteptat.

Greșeli frecvente

• Greșit: proiectarea începe doar cu culorile interfeței.
  Corect: începe cu cerințe, date și operații.
• Greșit: un test pe un singur împrumut dovedește că nu apar conflicte.
  Corect: testează și încercări concurente sau repetate.
• Greșit: interfața este singurul loc unde se verifică disponibilitatea.
  Corect: regula trebuie păstrată în logica și datele aplicației.

Înainte și după