Programare orientată spre funcții - Feature-oriented programming

În programarea computerizată , programarea orientată pe caracteristici ( FOP ) sau dezvoltarea de software orientată pe caracteristici ( FOSD ) este o paradigmă de programare pentru generarea de programe în linii de produse software (SPL) și pentru dezvoltarea incrementală a programelor.

Istorie

Conexiune între stive de straturi și compoziții de transformare

FOSD a apărut din concepții bazate pe straturi și niveluri de abstractizare în protocoalele de rețea și sistemele de baze de date extensibile la sfârșitul anilor '80. Un program era un teanc de straturi. Fiecare strat a adăugat funcționalitate straturilor compuse anterior și diferite compoziții de straturi au produs diferite programe. Nu este surprinzător că era nevoie de un limbaj compact pentru a exprima astfel de modele. Algebra elementară se potrivește facturii: fiecare strat a fost o funcție (o transformare a programului ) care a adăugat un nou cod la un program existent pentru a produce un nou program, iar designul unui program a fost modelat printr-o expresie, adică o compoziție de transformări (straturi). Figura din stânga ilustrează stivuirea straturilor i, j și h (unde h este în partea de jos și i este în partea de sus). Notațiile algebrice i (j (h)), i • j • h și i + j + h au fost utilizate pentru a exprima aceste modele.

De-a lungul timpului, straturile au fost echivalate cu caracteristici, unde o caracteristică este o creștere a funcționalității programului. Paradigma pentru proiectarea și generarea de programe a fost recunoscută ca fiind o creștere a optimizării interacțiunii relaționale, unde programele de evaluare a interogărilor au fost definite ca expresii de algebră relațională, iar optimizarea interogărilor a fost optimizarea expresiei. O linie de produse software este o familie de programe în care fiecare program este definit de o compoziție unică de caracteristici. FOSD a evoluat de atunci în studiul modularității caracteristicilor, instrumentelor, analizelor și tehnicilor de proiectare pentru a sprijini generarea de programe bazate pe caracteristici.

A doua generație de cercetare FOSD a fost pe interacțiunile de caracteristici, care au provenit din telecomunicații. Mai târziu, termenul de programare orientată pe caracteristici a fost inventat; această lucrare a expus interacțiunile dintre straturi. Interacțiunile necesită adaptarea caracteristicilor atunci când sunt compuse cu alte caracteristici.

O a treia generație de cercetare s-a concentrat pe faptul că fiecare program are reprezentări multiple (de exemplu, sursă, fișiere, documente etc.) și adăugarea unei caracteristici unui program ar trebui să elaboreze fiecare dintre reprezentările sale, astfel încât toate să fie coerente. În plus, unele dintre reprezentări ar putea fi generate (sau derivate) de la altele. În secțiunile de mai jos, sunt descrise matematica celor mai recente trei generații de FOSD, și anume GenVoca , AHEAD și FOMDD , și sunt furnizate linkuri către liniile de produse care au fost dezvoltate folosind instrumente FOSD. De asemenea, patru rezultate suplimentare care se aplică tuturor generațiilor de FOSD sunt: metamodelelor FOSD , cuburi de program FOSD și interacțiunile caracteristica FOSD.

GenVoca

GenVoca (un portmanteau al denumirilor Genesis și Avoca) este o paradigmă compozițională pentru definirea programelor de linii de produse. Programele de bază sunt funcții 0 transformări sau transformări numite valori :

  f      -- base program with feature f
  h      -- base program with feature h

și caracteristicile sunt funcții / transformări unare care elaborează (modifică, extind, rafinează) un program:

  i + x  -- adds feature i to program x
  j + x  -- adds feature j to program x

unde + denotă compoziția funcției. Proiectarea unui program este o expresie pe nume, de exemplu:

  p1 = j + f       -- program p1 has features j and f
  p2 = j + h       -- program p2 has features j and h
  p3 = i + j + h   -- program p3 has features i, j, and h

Un model GenVoca al unui domeniu sau linie de produse software este o colecție de programe și caracteristici de bază (consultați MetaModele și Cuburi de program ). Programele (expresiile) care pot fi create definesc o linie de produse. Optimizarea expresiei este optimizarea proiectării programului , iar evaluarea expresiei este generarea de programe .

Notă: GenVoca se bazează pe dezvoltarea treptată a programelor: un proces care subliniază simplitatea și înțelegerea proiectării, care sunt cheia pentru înțelegerea programului și construirea automată a programului. Luați în considerare programul p _{3 de} mai sus: începe cu programul de bază h, apoi se adaugă caracteristica j (citiți: funcționalitatea caracteristicii j este adăugată la baza de cod a h) și, în cele din urmă, caracteristica i este adăugată (citiți: funcționalitatea caracteristicii i este adăugat la baza de cod a j • h).

Notă: nu toate combinațiile de caracteristici sunt semnificative. Modelele de caracteristici (care pot fi traduse în formule propoziționale) sunt reprezentări grafice care definesc combinații juridice de caracteristici.

Notă: O formulare mai recentă a GenVoca este simetrică : există un singur program de bază, 0 (programul gol) și toate caracteristicile sunt funcții unare. Aceasta sugerează interpretarea conform căreia GenVoca compune structuri de programe prin suprapunere , ideea că structurile complexe sunt compuse prin suprapunerea structurilor mai simple. O altă reformulare a GenVoca este ca un monoid : un model GenVoca este un set de caracteristici cu o operație de compoziție (•); compoziția este asociativă și există un element de identitate (și anume 1, funcția de identitate). Deși toate compozițiile sunt posibile, nu toate sunt semnificative. Acesta este motivul pentru modelele de caracteristici .

Caracteristicile GenVoca au fost inițial implementate folosind #ifdef feature ... #endiftehnici de preprocesare C ( ). O tehnică mai avansată, numită straturi mixin , a arătat legătura dintre caracteristici și design-uri bazate pe colaborare orientate pe obiecte.

ÎNAINTE

Ecuațiile ierarhice algebrice pentru proiectarea aplicațiilor ( AHEAD ) au generalizat GenVoca în două moduri. Mai întâi a dezvăluit structura internă a valorilor GenVoca ca tupluri. Fiecare program are reprezentări multiple, cum ar fi sursă, documentație, cod de byt și fișiere. O valoare GenVoca este un tuplu de reprezentări ale programului. Într-o linie de produse de analizori, de exemplu, un analizor de bază f este definit de gramatica sa g _f , sursa Java s _f și documentația d _f . Analizatorul f este modelat de tuplul f = [g _f , s _f , d _f ]. Fiecare reprezentare a programului poate avea subreprezentări, iar ele pot avea și subreprezentări, recursiv. În general, o valoare GenVoca este un tuplu de tupluri imbricate care definesc o ierarhie de reprezentări pentru un anumit program.

Relații ierarhice între artefacte ale programului

Exemplu. Să presupunem că reprezentările terminalelor sunt fișiere. În AHEAD, gramatica g _f corespunde unui singur fișier BNF, sursa s _f corespunde unui tupl de fișiere Java [c ₁ … c _n ], iar documentația d _f este un tuplu de fișiere HTML [h ₁ ... h _k ]. O valoare GenVoca (tupluri imbricate) poate fi descrisă ca un grafic direcționat: graficul pentru analizorul f este prezentat în figura din dreapta. Săgețile denotă proiecții, adică mapări de la un tuplu la una dintre componentele sale. AHEAD implementează tupluri ca directoare de fișiere, deci f este un director care conține fișierul g _f și subdirectoarele s _f și d _f . În mod similar, directorul s _f conține fișiere c ₁ ... c _n , iar directorul df conține fișiere h ₁ ... h _k .

Notă: Fișierele pot fi descompuse ierarhic în continuare. Fiecare clasă Java poate fi descompusă într-un tuplu de membri și alte declarații de clasă (de exemplu, blocuri de inițializare etc.). Ideea importantă aici este că matematica AHEAD este recursivă.

În al doilea rând, AHEAD exprimă caracteristici ca niște tupluri imbricate de funcții unare numite delte . Deltele pot fi rafinamente ale programului (transformări care păstrează semantica), extensii (transformări care extind semantica) sau interacțiuni (transformări care modifică semantica). Folosim termenul neutru „delta” pentru a reprezenta toate aceste posibilități, deoarece fiecare apare în FOSD.

Pentru a ilustra, să presupunem că caracteristica j extinde o gramatică cu g _j (se adaugă noi reguli și jetoane), extinde codul sursă cu s _j (se adaugă noi clase și membri și se modifică metodele existente) și extinde documentația cu d _j . Tuple de delte pentru caracteristica j este modelat de j = [ g _j , s _j , d _j ], pe care îl numim un tuple delta . Elementele tuplurilor delta pot fi ele însele tuple delta. Exemplu: s _j reprezintă modificările aduse fiecărei clase din s _f de caracteristica j, adică s _j = [ c ₁ ... c _n ]. Reprezentările unui program sunt calculate recursiv prin adăugare de vector imbricat. Reprezentările pentru analizorul p ₂ (a căror expresie GenVoca este j + f) sunt: ${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$

  p2 = j + f                              -- GenVoca expression
     = [${\displaystyle \Delta }$gj, ${\displaystyle \Delta }$sj, ${\displaystyle \Delta }$dj] + [gf, sf, df]   -- substitution
     = [${\displaystyle \Delta }$gj+gf, ${\displaystyle \Delta }$sj+sf, ${\displaystyle \Delta }$dj+df]         -- compose tuples element-wise

Adică, gramatica lui p ₂ este gramatica de bază compusă cu extensia sa ( g _j + g _f ), sursa lui p ₂ este sursa de bază compusă cu extensia sa ( s _j + s _f ) și așa mai departe. Deoarece elementele tuplelor delta pot fi ele însele tuple delta, compoziția se repetă, de exemplu, s _j + s _f = [ c ₁ … c _n ] + [c ₁ … c _n ] = [ c ₁ + c ₁ … c _n + c _n ]. Rezumând, valorile GenVoca sunt tupluri imbricate de artefacte ale programului, iar caracteristicile sunt tupluri delta imbricate, unde + le compune recursiv prin adăugare de vectori. Aceasta este esența AHEAD. ${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$${\ displaystyle \ Delta}$

Ideile prezentate mai sus expun concret două principii FOSD. Principiul unicității prevede că toate artefactele de program sunt tratate și modificate în același mod. (Acest lucru este demonstrat de delte pentru diferite tipuri de artefacte de mai sus). Principiul Scalabilitate prevede toate nivelurile de abstractizari sunt tratate în mod uniform. (Acest lucru dă naștere la cuibărirea ierarhică a tuplurilor de mai sus).

Implementarea originală a programului AHEAD este AHEAD Tool Suite și limbajul Jak, care prezintă atât principiile uniformității, cât și scalabilitatea. Instrumentele de generație următoare includ CIDE și FeatureHouse.

FOMDD

Relații derivative și de rafinament între artefacte ale programului

Proiectarea orientată pe caracteristici ( FOMDD ) combină ideile AHEAD cu Design-ul condus de model ( MDD ) (alias Arhitectură bazată pe model ( MDA )). Funcțiile AHEAD captează actualizarea blocată a artefactelor programului atunci când o caracteristică este adăugată la un program. Dar există alte relații funcționale între artefactele programului care exprimă derivări. De exemplu, relația dintre o gramatică g _f și sursa sa de analizor s _f este definită de un instrument compilator-compilator, de exemplu, javacc. În mod similar, relația dintre sursa Java s _f și codul său de octet b _f este definită de compilatorul javac. O diagramă de navetă exprimă aceste relații. Obiectele sunt reprezentări ale programului, săgețile în jos sunt derivări, iar săgețile orizontale sunt delte. Figura din dreapta arată schema de navetă pentru programul p ₃ = i + j + h = [g ₃ , s ₃ , b ₃ ].

O proprietate fundamentală a unei diagrame de navetă este că toate căile dintre două obiecte sunt echivalente. De exemplu, o modalitate de a deriva codul de octet b ₃ al parserului p ₃ (obiectul din dreapta jos din figura din dreapta) din gramatica g _h a parserului h (obiectul din stânga sus) este derivarea codului de octet b _h și rafinarea la b ₃ , în timp ce un alt mod rafinează g _h la g ₃ , și apoi derivă b ₃ , unde + reprezintă compoziția delta și () este funcția sau aplicația instrumentului:

  b3 = ${\displaystyle \Delta }$bj + ${\displaystyle \Delta }$bi + javacc( javac( gh ) ) = javac( javacc( ${\displaystyle \Delta }$gi + ${\displaystyle \Delta }$gj + gh ) )

Există posibile căi pentru a obține codul de octet b ₃ al analizatorului p ₃ din gramatica g _h a analizatorului h. Fiecare cale reprezintă o metaprogramă a cărei execuție generează obiectul țintă (b ₃ ) de la obiectul de pornire (g _f ). Există o potențială optimizare: parcurgerea fiecărei săgeți a unei diagrame de navetă are un cost. Cea mai ieftină cale (adică cea mai scurtă) dintre două obiecte dintr-o diagramă de navetă este o geodezică , care reprezintă cea mai eficientă metaprogramă care produce obiectul țintă dintr-un obiect dat. ${\ displaystyle {\ tbinom {4} {2}}}$

Notă: o „valoare a costului” nu trebuie să fie o valoare monetară; costul poate fi măsurat în timp de producție, cerințele de vârf sau de memorie totală, consumul de energie sau unele metrici informale, cum ar fi „ușurința explicării”, sau o combinație a celor de mai sus (de exemplu, optimizare multi-obiectiv ). Ideea unei geodezii este generală și ar trebui înțeleasă și apreciată din acest context mai general.

Notă: Este posibil să existe m obiecte de pornire și n obiecte de finalizare într-o geodezie; când m = 1 și n> 1, aceasta este problema arborelui Steiner direcționat , care este NP-hard.

Diagramele de navetă sunt importante din cel puțin două motive: (1) există posibilitatea de a optimiza generarea de artefacte (de exemplu, geodezice) și (2) specifică moduri diferite de a construi un obiect țintă dintr-un obiect de pornire. O cale printr-o diagramă corespunde unui lanț de instrumente: pentru ca un model FOMDD să fie consecvent, ar trebui să se dovedească (sau să se demonstreze prin testare) că toate lanțurile de instrumente care mapează un obiect la altul de fapt dau rezultate echivalente. Dacă acest lucru nu este cazul, atunci fie există o eroare într-unul sau mai multe dintre instrumente, fie modelul FOMDD este greșit.

Notă: ideile de mai sus au fost inspirate din teoria categoriilor .

Aplicații

• Protocoale de rețea
• Sisteme de baze de date extensibile
• Structuri de date
• Simulator de asistență de incendiu distribuit
• Compilator sistem de producție
• Linia de produse Graph
• Preprocesoare Java extensibile
• Portleturi web
• Aplicații SVG

Vezi si

• MetaModele FOSD — linii de produse din linii de produse
• Origami FOSD
• Cuburi de program FOSD — linii de produse multidimensionale

• Limbaj de programare foarte înalt

Referințe