Odlika-orijentisanog programiranja

Odlika-orijentisanog programiranja (OOP) ili funkcija orijentisanog softverskog razvoja (FOSR) je opšta paradigma za sintezu programa u liniji softverskih proizvoda.

Veza između Layer Stacks i transformacija kompozicija

FOSD je proistekao iz sloja na bazi dizajna i nivoa apstrakcije u mrežnim protokolima i proširivim bazama podataka u kasnim 1980-im.^[1] Program je gomila slojeva. Svaki sloj dodaje funkcionalnost prethodno sastavljenih slojeva i različitih kompozicija slojeva i proizvodi različite programe. Nije iznenađujuća potreba za kompaktnim jezikom za izražavanje takvih projekata. Osnovni algebarski odgovor račun: svaki sloj je funkcija (programa transformacije) koji je dodao novi kod postojećem programu da se izradi novi program, i dizajn programa je bio modeliran izraz, odnosno, u sastavu transformacija (slojeva). Slika u nastavku ilustruje slaganje slojeva h, j, i i (gde je h na dnu i i na vrhu). Algebarske oznake i(j(h)) i i•j•h su izrazi tih projekata.

Vremenom, ideja slojeva je generalizovana na funkcije, gde je osobina porast u razvoju programa ili funkcionalnosti. Paradigma za izradu programa i sinteza je priznala da je generalizacija relacijske optimizacije upita, gde su definisani programi upita evaluacije kao relacioni algebarski izrazi, i optimizacija upita je procena izraza.^[2] Linija softverskih proizvoda (LSP) je porodica programa, gde je svaki program koji je definisan jedinstvenog sastava funkcija, i ne postoje dva programa koji imaju istu kombinaciju. FOSD je od tada evoluirao u studiju igrane modularnosti, alate, analize, tehnike i dizajn za podršku sintezi programa funkcija na bazi.

Druga tema istraživanja sa vođstvom koje poseduje orijentisano programiranje je koncept igranih interakcija, koja je nastala u telekomunikacijama. Zatim, termin funkcija orijentisanog programiranja je nastao u.^[3] Ovaj rad fokusiran je na interakciji između ovih slojeva, koje treba rešiti u slučaju kompozicije. Zbog takvih igranih interakcija, karakteristike treba prilagoditi kada se sastaju sa ostalim funkcijama.

Dalji napredak u FOSD-u nastao je iz prepoznavanja sledećih činjenica: Svaki program ima više delova (npr izvor, napravljen fajl, dokumentaciju, itd) i dodavanjem funkcija u programu treba razraditi svaki od njegovih delova, tako da su sve reprezentacije dosledne. Pored toga, neko od ovih delova može biti generisano (ili izveden) od drugih delova. U ovom članku, matematika tri poslednje generacije FOSD-a, naime GenVoca,^[1] AHEAD,^[4] i FOMDD^[5]^[6] su opisani, i linkove ka linijama proizvoda koji su razvijeni korišćenjem alata FOSD-a su obezbeđeni. Takođe, četiri dodatna rezultata koji se odnose na sve generacije FOSD-a su izneta na drugom mestu: metamodeli, program kocke, odlika algebre, i igrane interakcije.

GenVoca[uredi | uredi izvor]

GenVoca (pomešana imena Genesis i Avoca)^[1] je sastavna paradigma za definisanje programa proizvodne linije. Osnovni programi su 0-ari funkcije ili transformacija tzv vrednosti:

  f      -- база програма са функцијом f
  h      -- база програма са функцијом h

i karakteristike su unarne funkcije/transformacije elaborata (menja, proširuje, detaljnije) programa:

  i • x  -- додаје функцију i програму x
  j • x  -- додаје функцију j програму x

gde • označava funkciju sastava. Dizajn programa je nazvan kao izraz, npr:

  p₁ = j • f       -- програм p₁ има карактеристике j и f
  p₂ = j • h       -- програм p₂ има карактеристике j и h
  p₃ = i • j • h   -- програм p₃ има карактеристике i, j, и h

A GenVoca model domena linije softverskih proizvoda je skup osnovnih programa i funkcija (vidi metamodeli i program kocke). Programi (izrazi) koji mogu da se stvore definišu liniju proizvoda. Izraz optimizacija je program dizajna optimizacije, i evaluacija izraza je sinteza programa.

Napomena: GenVoca se bazira na razvoja programa korak po korak: procesi koji ističu dizajn jednostavnost i razumljivost, koji su ključ za razumevanje programiranja i automatizovanu izgradnju programa. Razmislite program p3 gore: počinje sa osnovnim programom h, zatim je funkcija j dodata (čitaj: funkcionalnost • funkcije j se dodaje u codebase-u od funkcije h), i konačno funkcija i je dodata (čitaj: Funkcionalnost • funkcije i se dodaje u codebase-u od funkcija j•h).

Napomena: nemaju sve kombinacije funkcija smisla. Funkcije modela (što se može prevesti u propozicijsku formulu) su grafički prikazi koji definišu pravne kombinacije karakteristika.^[7]

Napomena: Novija formulacija GenVoca je simetrična: postoji samo jedna baza programa, 0 (prazan program), a sve karakteristike su unarne funkcije. Ovo ukazuje na tumačenje da GenVoca obuhvata programske strukture od superpozicije, ideju da su složene strukture sastavljene od stavljanja jednostavnijih struktura.^[8]^[9] Još jedna reformulacija GenVoca je kao monoid: GenVoca model je skup karakteristika sa operacijom sastava (•); Kompozicija je asocijativna i postoji jedan identitet elementa (tj 1, funkcija identiteta). Iako su sve kompozicije moguće, nisu sve smislene ranije pomenute.

GenVoca karakteristike su prvobitno realizovane pomoću C predprocesora (#ifdef feature ... #endif) tehnike. Naprednija tehnika, nazvana mixin slojevi, pokazala je povezanost objekt-orijentisane funkcije za saradnju na bazi dizajna.

AHEAD[uredi | uredi izvor]

Algebarske hijerarhijske jednačine za aplikacije dizajna (AHEAD) ^[4] generalizovao je GenVoca na dva načina. Prvo je otkrio unutrašnju strukturu GenVoca vrednosti kao torke. Svaki program ima više delova, kao što su izvor, dokumentacija, bytecode, i napravljen fajl. GenVoca vrednost je torka programskih reprezentacija. U proizvodnoj liniji parsers-a, na primer, baza analizatora f definisala je gramatiku gf, Java izvor sf, dokumentacije df. Program f se modelira po torci f=[gf, sf, df]. Svaka prezentacija programa može imati pod delove, i oni mogu imati pod delove, rekurzivno. U principu, GenVoca vrednost je torka ugnežđenih torki koji definišu hijerarhiju delova za određeni program.

Primer. Pretpostavimo da suterminal delova fajlovi. U AHEAD-u, gramatika gf odgovara jednoj datoteci BNF-a, izvor sf odgovara torci Java fajlova [c1…cn], i dokumentacija df je torka od HTML datoteke [h1…hk]. GenVoca vrednost (ugnježdena torka) može se opisati kao reditelj grafikona: Grafikon za program f je prikazan na slici sa desne strane. Strelice označavaju projekcije, odnosno, mapiranja iz torke jedne od njegovih komponenti. AHEAD sprovodi zapise, kao datoteka direktorijuma, tako da je f direktorijum koji sadrži datoteke gf i pod delove sf i df. Slično tome, direktorijum sf sadrži datoteke c1…cn, i direktorijum df sadrži datoteke h1…hk.

Napomena: Fajlovi mogu biti hijerarhijski dekomponovane dopune. Svaka Java klasa može se rastaviti u torku članova i druge klase deklaracija (na primer, inicijalizacija blokova, itd).

Drugo, AHEAD izražava karakteristike kao ugnježdene torke od unarnih funkcija pod nazivom deltas. Deltas može biti program poboljšanja (semantika očuvanja transformacije), ekstenzija (semantika produžava transformacije), ili interakcija (semantika za promenu transformacije). Mi koristimo neutralan izraz "Deltas" koji predstavlja sve ove mogućnosti, jer se sve javljaju u FOSD-u.

Za ilustraciju, pretpostavimo da se funkcija j prostire na gramatiku od $\Delta$ g_j (dodaju nova pravila i tokene), prostire se izvorni kod od $\Delta$ s_j (nove klase i članovi se dodaju i postojeće metode su modifikovane), i proširenu dokumentaciju od $\Delta$ d_j. Torka na deltas za dugometražno j se modeluje j=[ $\Delta$ g_j, $\Delta$ s_j, $\Delta$ d_j], koju zovemo delta torka.. Kao primer, $\Delta$ s_j predstavlja promene koje su učinjene u svakom razredu u sf od funkcija j, i.e., $\Delta$ s_j=[ $\Delta$ c₁… $\Delta$ c_n]. Delovi programa su rekurzivno izračunati sastavljanjem elemenata torke-mudar. Delovi za analizator p (čiji GenVoca izraz je j•f) su:

  p₂ = j • f                            -- GenVoca експресија
     = [ $\Delta$ g_j,  $\Delta$ s_j,  $\Delta$ d_j] • [g_f, s_f, d_f]   -- замена
     = [ $\Delta$ g_j•g_f,  $\Delta$ s_j•s_f,  $\Delta$ d_j•d_f]         -- саставити торке елемент-мудар

To jest, gramatika p je osnovna gramatika sastavljena sa ekstenzijom ( $\Delta$ g_j•g_f), izvor p je osnova izvora sastavljena sa njegovog produženja ( $\Delta$ s_j•s_f),i tako dalje. Kao elementi delta torke mogu same biti delta torke, sastav recurses, npr, $\Delta$ s_j•s_f= [ $\Delta$ c₁… $\Delta$ c_n]•[c₁…c_n]=[ $\Delta$ c₁•c₁… $\Delta$ c_n•c_n]. Sumirajući, GenVoca vrednosti su ugnježđene torke programskih artefakata, a karakteristike su ugnježđene delta torke, gde ih • rekurzivno komponuje. To je suština AHEAD-a.

Ideje predstavljene iznad konkretno predstavljaju dva FOSD principa. Princip uniformnosti navodi da su svi programski artefakti tretirani i rafinirani na isti način. (Ovo je dokazano od deltas-a za različite tipove artefakta gore). Princip prilagodljivosti navodi na sve nivoe apstrakcija ravnomernu tretiraju. (To dovodi do hijerarhijskoj gnježđenje na torku gore).

Originalna implementacija AHEAD je AHEAD alatka Suite and Jak jezik, što pokazuje i princip uniformnosti i skalabilnosti. Sledeća generacija alata uključuje CIDE^[10] i Funkciju Kuća.^[11]

FOMDD[uredi | uredi izvor]

Derivacionost i prefinjenost odnosa između program artefakta

Funkcija orijentisanosti model pokretnog dizajna (FOMPD)^[5]^[6] kombinuje ideje AHEAD sa modelom pokretnog dizajna (MPD) (model-pokretna arhitektura (MPA)). AHEAD funkcije hvatanja pratile su cenu ažuriranja programskih artefakata kada se funkcija dodaje u program. Ali postoje i drugi funkcionalni odnosi između programskih artefakata koje izražavaju izvođenja. Na primer, odnos između gramatike gf i njenog analizatora izvora sf je definisan kao kompajler-kompajler alat, npr javacc. Slično tome, odnos između Java izvora sf i njenog bytecode bf je definisan javac kompajler. Putujući dijagram izražava te odnose. Objekti su programski delovi, nadole strele su derivati i horizontalne strele su deltas. Figura sa desne strane pokazuje putujući dijagram za program p3 = i•j•h = [g3,s3,b3].

Osnovno svojstvo putujućeg dijagrama je da svi putevi između dva objekta su ekvivalentni. Na primer, jedan od načina da izvedemo bajtkod b3 na anlizator p3 (donji desni objekat u gornjoj slici) iz gramatike gf od analizatora f (gornji levi objekat) je za izvođenje bajtkoda bf i prerade u b3, dok je drugi način oplemenjivanje gf u g3, a zatim izvesti b3:

   $\Delta$ b_i •  $\Delta$ b_j • javac • javacc = javac • javacc •  $\Delta$ g_i •  $\Delta$ g_j

Postoje ${\tbinom {4}{2}}$ mogući putevi da izvedemo bajtkod b3 naanalizator p3 iz gramatike gf u anlizator f. Svaki put predstavlja metaprogram čije izvršenje sintetiše ciljni objekat (b3) od početnog objekta (gf). Postoji potencijal optimizacije: prelaženje svake strele nekog dnevnog putujućeg dijagrama ima cenu. Najjeftiniji (tj najkraći) put između dva objekta u dnevnom putujućem dijagramu je geodetski, koji predstavlja najefikasniji meta program koji proizvodi ciljni objekat iz datog predmeta.

Napomena: "metrička cena" ne treba biti monetarna vrednost; cena se može meriti u vreme proizvodnje, vrhom ili ukupnom potrebnom memorijom, neformalna metrika poput "lakšeg objašnjenja", ili kombinacijom gore (npr, višekriterijumska optimizacija). Ideja o geodeziji je prilično uopštena, i treba da se shvati i ceni ovog opštijeg konteksta.

Napomena: Moguće je da postoji m startni objekat i n završni objekat u geodeziji; kada je m = 1 i n> 1, to je problem Štajnerovog drva, što je NP-teško.

Putujući dijagrami su važni za najmanje dva razloga: (1) postoji mogućnost optimizacije sinteze artefakata (na primer, geodezija) i (2) da odredite različite načine izgradnje ciljnog objekta od početnog objekta.^[5]^[12] Putanja kroz dijagram odgovara lancu alata: za FOMDD model da bude dosledan, to treba dokazati (ili pokazati kroz testiranje) da svi lanci alata tu mapiraju jedan objekat na drugi, u stvari prinose iste rezultate. (Ako različiti putevi/alati lanca daju različite rezultate, onda ili postoji greška u jednom ili više alata ili FOMDD model je pogrešan).

Napomena: gorenavedene ideje su inspirisane teorijom kategorija.^[5]^[6]

Aplikacije[uredi | uredi izvor]

Vidi još[uredi | uredi izvor]

FOSD metamodel—proizvodne linije za proizvodne linije
FOSD program kocke—višedimenzionalne proizvodne linije
FOSD algebrske funkcije—osnovne operacije od kojih su definisane FOSD karakteristike (0-ari i 1-ari) funkcije
FOSD funkcija interakcije—glavni koncepti za igrane interakcije

Refrence[uredi | uredi izvor]

^ ^a ^b ^v „Design and Implementation of Hierarchical Software Systems with Reusable Components” (PDF).
^ „Access Path Selection In Relational Databases”.
^ „Feature-Oriented Programming: A Fresh Look at Objects”. Arhivirano iz originala 03. 08. 2003. g. Pristupljeno 11. 01. 2016.
^ ^a ^b „Scaling Step-Wise Refinement” (PDF).
^ ^a ^b ^v ^g „Feature Oriented Model Driven Development: A Case Study for Portlets” (PDF).
^ ^a ^b ^v „Generative Metaprogramming”.
^ „Feature Models, Grammars, and Propositional Formulas” (PDF).
^ „An Algebra for Features and Feature Composition” (PDF).
^ „Superimposition: A Language-Independent Approach to Software Composition” (PDF).
^ „Guaranteeing Syntactic Correctness for all Product Line Variants: A Language-Independent Approach” (PDF).
^ „FeatureHouse: Language-Independent, Automated Software Composition” (PDF).
^ „Testing Software Product Lines Using Incremental Test Generation” (PDF).

[genvoca-1] v „Design and Implementation of Hierarchical Software Systems with Reusable Components” (PDF).

[selinger-2] „Access Path Selection In Relational Databases”.

[FOP-3] „Feature-Oriented Programming: A Fresh Look at Objects”. Arhivirano iz originala 03. 08. 2003. g. Pristupljeno 11. 01. 2016.

[ahead-4] „Scaling Step-Wise Refinement” (PDF).

[fomdd-5] v ^g „Feature Oriented Model Driven Development: A Case Study for Portlets” (PDF).

[genmeta-6] v „Generative Metaprogramming”.

[splc-7] „Feature Models, Grammars, and Propositional Formulas” (PDF).

[amast08-8] „An Algebra for Features and Feature Composition” (PDF).

[symmetric-9] „Superimposition: A Language-Independent Approach to Software Composition” (PDF).

[CIDE-10] „Guaranteeing Syntactic Correctness for all Product Line Variants: A Language-Independent Approach” (PDF).

[FH-11] „FeatureHouse: Language-Independent, Automated Software Composition” (PDF).

[testing-12] „Testing Software Product Lines Using Incremental Test Generation” (PDF).

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]