Luca Dan Șerbănați la bacalaureat, 1961
Luca Dan Șerbănați în primii ani ’70
Luca Dan Șerbănați la ultimul curs, aprilie 1989

Luca Dan Șerbănați

Profesor emerit la Politehnica din București

Cercetare, învățământ, industrie și memorii

RO | EN | IT
Luca Dan Șerbănați la Veneția, 1990
Luca Dan Șerbănați la New York, 2005
Luca Dan Șerbănați

Locul acestei teme în preocupările mele de fundamente

Modelarea orientată pe concerns aparține unei direcții mai largi a preocupărilor mele pentru explicitarea sensului construcțiilor formale. Dacă în anii ’70 semantica programelor era legată de descrierea stărilor și transformărilor unei mașini abstracte, mai târziu aceeași problemă s-a deplasat spre semantica modelelor, a proceselor de proiectare și a structurilor conceptuale prin care un proiectant înțelege și construiește un sistem.

În această perspectivă, un concern nu este doar o „preocupare” formulată în limbaj natural. El devine un criteriu semantic de organizare a modelului: selectează anumite aspecte ale sistemului, le aduce în prim-plan, le leagă prin relații proprii și impune constrângeri asupra soluției de proiectare.

De la semantica execuției la semantica proiectării

Prima mea întâlnire sistematică cu semantica a fost legată de Metoda Viena și de descrierea execuției unui program ca transformare controlată a unei stări abstracte. Sensul unui program era dat de felul în care o construcție sintactică modifica un univers de valori, medii, memorii și structuri compuse.

În cercetările mele ulterioare despre proiectarea produselor-program, accentul s-a mutat de la execuția programului la activitatea proiectantului. Proiectarea nu mai putea fi redusă la o succesiune mecanică de pași, ci trebuia privită ca o activitate cognitivă, intențională, în care proiectantul lucrează cu modele, cu forme intermediare și cu reprezentări parțiale ale produsului.

Astfel, firul conceptual rămâne același: un obiect formal sau tehnic are sens numai dacă putem descrie structurile sale interne, stările relevante și transformările prin care trece. În cazul programelor, aceste transformări sunt tranziții de stare ale unei mașini abstracte; în cazul proiectării, ele sunt rafinări succesive ale modelelor mentale și documentare ale produsului.

Ce este un concern?

În contextul modelării orientate pe concern-e, un concern este o preocupare, nevoie, interes, dorință, constrângere sau îngrijorare a unui agent sau stakeholder în raport cu un produs, un serviciu sau un proces. El exprimă o nemulțumire față de o stare curentă sau o așteptare față de o stare viitoare.

Pentru proiectant, concern-ele stakeholderilor devin probleme de rezolvat. Ele sunt preluate, interpretate, mediate și transformate în obiective de proiectare. Uneori concern-ele sunt compatibile; alteori ele sunt divergente sau chiar contradictorii. Tocmai această tensiune explică de ce proiectarea nu poate fi complet algoritmizată: ea presupune decizii, compromisuri, justificări și reveniri.

Într-un sistem medical, de exemplu, medicul poate avea concern-e legate de eficacitatea tratamentului și de efectele adverse, pacientul poate avea concern-e economice sau de confort, iar organizațiile sanitare pot avea concern-e legate de costuri, reguli de prescriere și respectarea protocoalelor. Tratamentul concret rezultă din negocierea implicită a acestor perspective.

Separarea concern-elor ca modularizare semantică

Principiul separării concern-elor pornește de la o dificultate fundamentală: un sistem complex nu poate fi înțeles și proiectat dintr-o singură privire. El trebuie descompus în zone conceptuale relativ coerente, fiecare dominată de un anumit concern.

Această separare nu este doar o tehnică practică de împărțire a muncii. Ea este o formă de modularizare semantică. O componentă, o vedere sau o fațetă devine inteligibilă deoarece este organizată în jurul unui criteriu de sens: ce problemă rezolvă, ce proprietăți urmărește, ce comportamente trebuie să păstreze și ce constrângeri trebuie să respecte.

Separarea concern-elor are însă nevoie de o operație complementară: recompoziția. Dacă fiecare concern produce o vedere parțială asupra sistemului, produsul final trebuie să reunească aceste perspective într-o structură coerentă. Altfel, analiza devine fragmentare, iar proiectarea pierde unitatea sistemului.

Vederi, fațete și interforme

Pentru a descrie această activitate de proiectare, am folosit conceptele de vedere, fațetă și interformă.

O vedere grupează informațiile despre produs dintr-o anumită perspectivă: informațională, funcțională, socială, tehnologică, organizațională sau materială. În interiorul unei vederi, o fațetă reunește proprietățile și comportamentele produsului care sunt relevante pentru un anumit concern.

Interforma generalizează această idee. Ea este o formă intermediară a produsului în mintea proiectantului și în documentația proiectului: o structură care conține atribute, fațete, relații și cunoștințe încă incomplete, dar suficient de organizate pentru a permite continuarea proiectării.

Pe măsură ce proiectantul rezolvă concern-e, interforma se modifică: apar fațete noi, se completează fațete existente, se verifică predicate de consistență, se introduc variante sau versiuni. Proiectarea poate fi astfel descrisă ca o succesiune de interforme legate prin relații de rafinare.

Modelarea proiectării ca activitate intențională

Modelarea orientată pe concern-e se sprijină pe o interpretare praxeologică a proiectării. Un agent acționează deoarece urmărește un obiectiv; obiectivul exprimă o stare dorită; intenția activează un plan; iar planul organizează acțiunile și resursele necesare pentru atingerea obiectivului.

În proiectare, această schemă capătă o formă specifică: proiectantul pornește de la cerințe, le interpretează prin propriile cunoștințe și prin modelele pe care le are la dispoziție, identifică concern-ele nerezolvate și produce o nouă formă intermediară a produsului. Fiecare pas este o încercare de a reduce distanța dintre modelul curent și produsul dorit.

Din acest punct de vedere, concern-ul joacă un rol asemănător unei diferențe semantice detectate între ceea ce este modelul în prezent și ceea ce ar trebui să devină. Rezolvarea lui este o transformare controlată a modelului.

Exemplul medical: de la tratament la model de acțiune

În articolul din 2008 am folosit un scenariu medical pentru a ilustra această problematică. O vizită la medic, un episod clinic sau prescrierea unui tratament pot fi privite ca procese orientate spre obiective, desfășurate în timp și dependente de mai mulți stakeholderi.

Medicul, pacientul, policlinica, casa de asigurări și sistemul sanitar nu privesc tratamentul din aceeași perspectivă. Fiecare introduce propriile concern-e: vindecare, cost, risc, conformitate cu ghidurile, disponibilitate a resurselor, continuitate a îngrijirii. Modelarea tratamentului trebuie să facă vizibile aceste perspective, altfel deciziile medicale și informatice rămân insuficient explicate.

De aici se deschide legătura cu informatica medicală: protocoalele clinice, criteriile de selecție pentru studii clinice, dosarul medical electronic și ecosistemele digitale de sănătate au nevoie de modele capabile să separe, dar și să integreze, concern-ele clinice, organizaționale, economice și informaționale.

Continuități conceptuale

Această temă se află la intersecția mai multor direcții ale activității mele: semantica limbajelor, metodele de proiectare, ingineria software, ontologiile și informatica medicală. Ea marchează trecerea de la semantica execuției la semantica modelării și a deciziei de proiectare.

Lucrări asociate

Legăturile PDF pot fi adăugate după stabilirea numelor definitive ale fișierelor în directorul /pdf/ sau în paginile individuale ale articolelor.

În rezumat

Modelarea orientată pe concern-e poate fi citită ca o etapă în evoluția unei idei mai vechi: sensul unui artefact informatic nu se află numai în forma sa finală, ci în structurile intermediare, în transformările și în deciziile care îl fac inteligibil. De la mașina abstractă a semanticii operaționale la interforma proiectării, rămâne aceeași întrebare: cum putem descrie riguros ceea ce, în mintea proiectantului, dă sens construcției unui sistem?