spyked bricks in the wall

o introducere ușor neobișnuită în domeniul arhitecturii software

Arhitectura, sau mai general proiectarea chestiilor este un subdomeniu al ingineriei ca oricare altul, care se ocupă, am putea spune lipsiți de rigoare, cu descrierea chestiilor în cauză. Bunăoară, dacă doresc, inginer fiind, să proiectez un ciocan spre a rezolva o problemă dată (de obicei bătutul cuielor), va trebui – dat fiind că-s om, iară nu orice om, ci inginer – să îmi formulez un set de cerințe și întrebări adiacente acesteia, legate printre altele de: părțile componente ale ciocanului, felul în care arată acestea, din ce sunt formate și cum se îmbină ele spre a forma mai mult decât suma părților lor.

Fundamentele acestei paradigme sunt aceleași în cazul sistemelor software, motiv pentru care și există în prezent acest domeniu oarecum bizar al ingineriei programelor pe calculator [i]. Diavolul se regăsește bineînțeles în detalii, acolo unde teoreticienii încearcă să prezică evoluția software-ului în timp. Dacă în cazul unui ciocan lucrurile stau destul de simplu – dai cu el până se strică -, software-ul evoluează destul de haotic în timp, degradându-se și pierzându-și din fiabilitate în moduri greu de prevăzut. Colac peste pupăză, inginerii noștri plini de creativitate gândesc modele și implementări care de care mai complexe, când rolul abstractizării e tocmai opusul, anume acela de a simplifica lucrurile. Deci aici zic că ar ajuta un pic să luăm lucrurile de la zero, deci să regândim problema.

În primul rând merită pe deplin subliniată importanța programării funcționale pentru actualii sau viitorii ingineri și oameni de știință ai calculatoarelor. Poate că programarea imperativă orientată pe obiecte – standardul de facto pentru inginerie software în zilele noastre; a se remarca de asemenea că obiectele sunt în sine doar un model de reprezentare a datelor, dezbateri de genul C vs C++ fiind irelevante în această discuție – nu e până la urmă atât de potrivită pe cât pare. Funcțiile împreună cu algebrele pot fi folosite la fel de eficient pentru a abstractiza concepte date, având în același timp avantajul formalizării imediate și deci a verificării mult mai facile a corectitudinii [ii]. Studiul calculului Lambda este prin urmare necesar, însă nu și suficient.

Pe lângă cele menționate mai sus, trebuie luat în calcul faptul că software-ul este o extensie naturală a hardware-ului. Sistemul de operare este prin definiție acest lucru, însă ce ne-ar opri să extindem (cu ajutorul tranzitivității) afirmația vizavi de orice alt program? Imediat peste nucleul sistemului de operare se găsesc utilitare de bază, care oferă funcționalitate pentru utilizator și/sau programator [iii]. Acestea la rândul lor pot fi folosite de către utilizator și/sau programator pentru a da naștere altor programe, care la rândul lor oferă funcționalitate, imbricarea putând merge la infinit – asemenea unui fractal.

Din fericire matematicianul are la dispoziție o unealtă cu aceste proprietăți; dânsa se numește teoria categoriilor și se află în relații de-a dreptul intime cu programarea funcțională printre altele. De exemplu categoriile pot fi folosite pentru a modela într-un mod cât se poate de natural concepte fundamentale din știința calculatoarelor, cum ar fi numerele, șirurile de simboluri, programele sau demonstrațiile de teoreme – tot aia [iv]. Tot prin extensie, nu văd de ce nu am putea folosi astfel teoria categoriilor pentru a modela sisteme software abstracte și interacțiuni între acestea. În ciuda, sau dimpotrivă, datorită faptului că se află sub restricțiile impuse de definiția categoriei, un program poate fi privit din punct de vedere arhitectural la diverse niveluri de abstractizare, această abordare sporind atât efortul de înțelegere al proiectantului cât și eficiența verificării formale [v].

Formalizând ideile de mai sus, un proiect software poate fi, să zicem, reprezentat printr-o categorie ale cărei obiecte le vom nota cu și ale cărei săgeți le vom nota cu , unde . De asemenea două săgeți trebuie să poată fi compuse printr-o operație , care-i asociativă pentru toate săgețile și are ca element neutru săgeata identitate. Translatând în limbaj ingineresc, obiectele pot fi de exemplu componente ale proiectului iar săgețile relații între acestea, compoziția punând astfel în evidență graful de dependențe între module și asigurând tranzitivitatea funcționalității.

Un exemplu de arhitectură care mi se pare foarte la îndemână este cea a unui sistem peer-to-peer oarecare, format din noduri organizate într-o topologie de tip „plasă” – de exemplu o rețea de senzori wireless. Pentru simplificare, toate nodurile sunt identice și pot comunica la o distanță dată fixă, fiecare nod având deci o mulțime de vecini. Vorbim de un sistem distribuit, deci suntem interesați mai mult de aspectele software, astfel că putem considera un program dat de pe unul din noduri ca fiind un obiect în categoria . Săgețile reprezintă capacitatea de a transmite informație între două noduri, idempotența având în acest caz rol de redundanță („nodul deține datele ”). Între două noduri vecine vor exista astfel săgeți în ambele sensuri, în plus propagarea informației în sistem fiind modelată prin compoziție. Treburile devin interesante când definim un functor care să mapeze sistemul pe un alt model, putând astfel distinge nodurile centrale de nodurile de pe frontieră etc. Consider demonstrația că e categorie a fi evidentă și o las ca exercițiu pentru mintea ageră a cititorului.

Propun astfel deschiderea unei discuții pe marginea acestei paradigme de construire a descrierilor de proiecte software. Subiectul este atât de lung pe cât este și lat, putând porni sub forma unor critici ale ideilor de mai sus și continua cu o formalizare mai riguroasă a modelului general, luând în calcul și alte elemente categoriale precum functorii, morfismele functoriale, categorii consacrate (de unde ar putea rezulta unele proprietăți interesante ale programelor) și așa mai departe. E foarte posibil de asemenea să existe deja material pe Internet legat exact de subiectul tratat aici, fapt ce ne-ar putea conduce la un studiu mai aprofundat pe temă dacă există interesul.

1. Da, dragi cititori, ingineria software e un ceva anume extrem de bizar prin felul ei de a fi. Aceasta ba apare în, ba dispare din mintea inginerului programator, existând și în același timp încetând să existe pentru acesta la un moment dat. Fenomenul se datorează nu numai faptului că lumea ideilor e volatilă în cadrul unui singur individ, ci și aceluia că oameni diferiți pot privi o singură problemă în moduri complet disjuncte, ajungând astfel să petreacă o perioadă considerabilă de timp stabilindu-și un limbaj comun. Astfel au apărut hack-uri imense dezvoltate de oameni cu interese profund diferite, cum e nucleul Linux, și astfel au luat viață inclusiv unele produse ale consumului de LSD, cum e Unix. [↩]
2. Faptul în sine e discutabil dacă stăm să ne gândim că formalismele pot fi folosite cu ușurință pentru a da naștere unor nonsensuri. Țin să menționez că apelul meu nu îndeamnă la renunțarea folosirii paradigmei imperative, ba dimpotrivă. Să se studieze în aceeași măsură – și nu mai mult – și aceasta și în plus studenții să fie încurajați spre a persista în studiul matematicilor, care oferă la fiecare pas lecții legate printre altele de unealta abstractizării. [↩]
3. Singurul motiv pentru care se face distincția asta e legat de apariția pe piață a software-ului de consum, accesibil, „idiot-proof”. Oricine comunică cu calculatorul este însă într-un anumit sens un programator. Că unii programatori sunt mai tembeli decât alții, asta-i o cu totul altă problemă; e așa, ca-n viață. [↩]
4. A se consulta izomorfismul Curry-Howard. [↩]
5. Cu mențiunea că acest așa-zis spor devine evident abia după ce inginerul s-a obișnuit a abstractiza într-o manieră categorială: obiectele unei categorii date pot astfel fi ele însele categorii sau săgeți cu varii proprietăți, limitele fiind impuse doar de rigorile ramurii matematicii în cauză. [↩]