Oдлика-оријентисаног програмирањa

Одлика-оријентисаног програмирања (ООП) или функција оријентисаног софтверског развоја (ФОСР) је општа парадигма за синтезу програма у линији софтверских производа.

Веза између Layer Stacks и трансформација композиција

ФОСД је проистекао из слоја на бази дизајна и нивоа апстракције у мрежним протоколима и проширивим базама података у касним 1980-им.^[1] Програм је гомила слојева. Сваки слој додаје функционалност претходно састављених слојева и различитих композиција слојева и производи различите програме. Није изненађујућа потреба за компактним језиком за изражавање таквих пројеката. Основни алгебарски одговор рачун: сваки слој је функција (програма трансформације) који је додао нови код постојећем програму да се изради нови програм, и дизајн програма је био моделиран израз, односно, у саставу трансформација (слојева). Слика у наставку илуструје слагање слојева h, j, и i (где је h на дну и i на врху). Алгебарске ознаке i(j(h)) и i•j•h су изрази тих пројеката.

Временом, идеја слојева је генерализована на функције, где је особина пораст у развоју програма или функционалности. Парадигма за израду програма и синтеза је признала да је генерализација релацијске оптимизације упита, где су дефинисани програми упита евалуације као релациони алгебарски изрази, и оптимизација упита је процена израза.^[2] Линија софтверских производа (ЛСП) је породица програма, где је сваки програм који је дефинисан јединственог састава функција, и не постоје два програма који имају исту комбинацију. FOSD је од тада еволуирао у студију игране модуларности, алате, анализе, технике и дизајн за подршку синтези програма функција на бази.

Друга тема истраживања са вођством које поседује оријентисано програмирање је концепт играних интеракција, која је настала у телекомуникацијама. Затим, термин функција оријентисаног програмирања је настао у.^[3] Овај рад фокусиран је на интеракцији између ових слојева, које треба решити у случају композиције. Због таквих играних интеракција, карактеристике треба прилагодити када се састају са осталим функцијама.

Даљи напредак у FOSD-у настао је из препознавања следећих чињеница: Сваки програм има више делова (нпр извор, направљен фајл, документацију, итд) и додавањем функција у програму треба разрадити сваки од његових делова, тако да су све репрезентације доследне. Поред тога, неко од ових делова може бити генерисано (или изведен) од других делова. У овом чланку, математика три последње генерације FOSD-а, наиме GenVoca,^[1] AHEAD,^[4] и FOMDD^[5]^[6] су описани, и линкове ка линијама производа који су развијени коришћењем алата ФОСД-а су обезбеђени. Такође, четири додатна резултата који се односе на све генерације ФОСД-а су изнета на другом месту: метамодели, програм коцке, одлика алгебре, и игране интеракције.

GenVoca

GenVoca (помешана имена Genesis и Avoca)^[1] је саставна парадигма за дефинисање програма производне линије. Основни програми су 0-ари функције или трансформација тзв вредности:

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

и карактеристике су унарне функције/трансформације елабората (мења, проширује, детаљније) програма:

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

где • означава функцију састава. Дизајн програма је назван као израз, нпр:

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

A GenVoca модел домена линије софтверских производа је скуп основних програма и функција (види метамодели и програм коцке). Програми (изрази) који могу да се створе дефинишу линију производа. Израз оптимизација је програм дизајна оптимизације, и евалуација израза је синтеза програма.

Напомена: GenVoca се базира на развоја програма корак по корак: процеси који истичу дизајн једноставност и разумљивост, који су кључ за разумевање програмирања и аутоматизовану изградњу програма. Размислите програм p3 горе: почиње са основним програмом h, затим је функција j додата (читај: функционалност • функције ј се додаје у codebase-у од функције h), и коначно функција i је додата (читај: Функционалност • функције i се додаје у codebase-у од функција j•h).

Напомена: немају све комбинације функција смисла. Функције модела (што се може превести у пропозицијску формулу) су графички прикази који дефинишу правне комбинације карактеристика.^[7]

Напомена: Новија формулација GenVoca је симетрична: постоји само једна база програма, 0 (празан програм), а све карактеристике су унарне функције. Ово указује на тумачење да GenVoca обухвата програмске структуре од суперпозиције, идеју да су сложене структуре састављене од стављања једноставнијих структура.^[8]^[9] Још једна реформулација GenVoca је као моноид: GenVoca модел је скуп карактеристика са операцијом састава (•); Композиција је асоцијативна и постоји један идентитет елемента (тј 1, функција идентитета). Иако су све композиције могуће, нису све смислене раније поменуте.

GenVoca карактеристике су првобитно реализоване помоћу C предпроцесора (#ifdef feature ... #endif) технике. Напреднија техника, названа mixin слојеви, показала је повезаност објект-оријентисане функције за сарадњу на бази дизајна.

AHEAD

Алгебарске хијерархијске једначине за апликације дизајна (AHEAD) ^[4] генерализовао је GenVoca на два начина. Прво је открио унутрашњу структуру GenVoca вредности као торке. Сваки програм има више делова, као што су извор, документација, bytecode, и направљен фајл. GenVoca вредност је торка програмских репрезентација. У производној линији parsers-а, на пример, база анализатора f дефинисала је граматику gf, Java извор sf, документације df. Програм f се моделира по торци f=[gf, sf, df]. Свака презентација програма може имати под делове, и они могу имати под делове, рекурзивно. У принципу, GenVoca вредност је торка угнежђених торки који дефинишу хијерархију делова за одређени програм.

Пример. Претпоставимо да сутерминал делова фајлови. У AHEAD-у, граматика gf одговара једној датотеци BNF-а, извор sf одговара торци Јава фајлова [c1…cn], и документација df је торка од HTML датотеке [h1…hk]. GenVoca вредност (угњеждена торка) може се описати као редитељ графикона: Графикон за програм f је приказан на слици са десне стране. Стрелице означавају пројекције, односно, мапирања из торке једне од његових компоненти. AHEAD спроводи записе, као датотека директоријума, тако да је f директоријум који садржи датотеке gf и под делове sf и df. Слично томе, директоријум sf садржи датотеке c1…cn, и директоријум df садржи датотеке h1…hk.

Напомена: Фајлови могу бити хијерархијски декомпоноване допуне. Свака Јава класа може се раставити у торку чланова и друге класе декларација (на пример, иницијализација блокова, итд).

Друго, AHEAD изражава карактеристике као угњеждене торке од унарних функција под називом deltas. Deltas може бити програм побољшања (семантика очувања трансформације), екстензија (семантика продужава трансформације), или интеракција (семантика за промену трансформације). Ми користимо неутралан израз "Deltas" који представља све ове могућности, јер се све јављају у FOSD-у.

За илустрацију, претпоставимо да се функција ј простире на граматику од $\Delta$ g_j (додају нова правила и токене), простире се изворни код од $\Delta$ s_j (нове класе и чланови се додају и постојеће методе су модификоване), и проширену документацију од $\Delta$ d_j. Торка на deltas за дугометражно ј се моделује j=[ $\Delta$ g_j, $\Delta$ s_j, $\Delta$ d_j], коју зовемо delta торка.. Kao primer, $\Delta$ s_j представља промене које су учињене у сваком разреду у sf од функција j, i.e., $\Delta$ s_j=[ $\Delta$ c₁… $\Delta$ c_n]. Делови програма су рекурзивно израчунати састављањем елемената торке-мудар. Делови за анализатор p (чији GenVoca израз је j•f) су:

  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]         -- саставити торке елемент-мудар

То јест, граматика p је основна граматика састављена са екстензијом ( $\Delta$ g_j•g_f), извор p је основа извора састављена са његовог продужења ( $\Delta$ s_j•s_f),и тако даље. Као елементи delta торке могу саме бити delta торке, састав recurses, нпр, $\Delta$ s_j•s_f= [ $\Delta$ c₁… $\Delta$ c_n]•[c₁…c_n]=[ $\Delta$ c₁•c₁… $\Delta$ c_n•c_n]. Сумирајући, GenVoca вредности су угњежђене торке програмских артефаката, а карактеристике су угњежђене delta торке, где их • рекурзивно компонује. То је суштина AHEAD-а.

Идеје представљене изнад конкретно представљају два FOSD принципа. Принцип униформности наводи да су сви програмски артефакти третирани и рафинирани на исти начин. (Ово је доказано од deltas-а за различите типове артефакта горе). Принцип прилагодљивости наводи на све нивое апстракција равномерну третирају. (То доводи до хијерархијској гњежђење на торку горе).

Оригинална имплементација AHEAD је AHEAD алатка Suite and Jak језик, што показује и принцип униформности и скалабилности. Следећа генерација алата укључује CIDE^[10] и Функцију Кућа.^[11]

FOMDD

Деривационост и префињеност односа између програм артефакта

Функција оријентисаности модел покретног дизајна (ФОМПД)^[5]^[6] комбинује идеје AHEAD са моделом покретног дизајна (МПД) (модел-покретна архитектура (МПА)). AHEAD функције хватања пратиле су цену ажурирања програмских артефаката када се функција додаје у програм. Али постоје и други функционални односи између програмских артефаката које изражавају извођења. На пример, однос између граматике gf и њеног анализатора извора sf је дефинисан као компајлер-компајлер алат, нпр javacc. Слично томе, однос између Java извора sf и њеног bytecode bf је дефинисан javac компајлер. Путујући дијаграм изражава те односе. Објекти су програмски делови, надоле стреле су деривати и хоризонталне стреле су deltas. Фигура са десне стране показује путујући дијаграм за програм p3 = i•j•h = [g3,s3,b3].

Основно својство путујућег дијаграма је да сви путеви између два објекта су еквивалентни. На пример, један од начина да изведемо бајткод b3 на анлизатор p3 (доњи десни објекат у горњој слици) из граматике gf од анализатора f (горњи леви објекат) је за извођење бајткода bf и прераде у b3, док је други начин оплемењивање gf у g3, а затим извести b3:

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

Постоје ${\tbinom {4}{2}}$ могући путеви да изведемо бајткод b3 наанализатор p3 из граматике gf у анлизатор f. Сваки пут представља метапрограм чије извршење синтетише циљни објекат (b3) од почетног објекта (gf). Постоји потенцијал оптимизације: прелажење сваке стреле неког дневног путујућег дијаграма има цену. Најјефтинији (тј најкраћи) пут између два објекта у дневном путујућем дијаграму је геодетски, који представља најефикаснији мета програм који производи циљни објекат из датог предмета.

Напомена: "метричка цена" не треба бити монетарна вредност; цена се може мерити у време производње, врхом или укупном потребном меморијом, неформална метрика попут "лакшег објашњења", или комбинацијом горе (нпр, вишекритеријумска оптимизација). Идеја о геодезији је прилично уопштена, и треба да се схвати и цени овог општијег контекста.

Напомена: Могуће је да постоји m стартни објекат и n завршни објекат у геодезији; када је m = 1 и n> 1, то је проблем Штајнеровог дрва, што је NP-тешко.

Путујући дијаграми су важни за најмање два разлога: (1) постоји могућност оптимизације синтезе артефаката (на пример, геодезија) и (2) да одредите различите начине изградње циљног објекта од почетног објекта.^[5]^[12] Путања кроз дијаграм одговара ланцу алата: за FOMDD модел да буде доследан, то треба доказати (или показати кроз тестирање) да сви ланци алата ту мапирају један објекат на други, у ствари приносе исте резултате. (Ако различити путеви/алати ланца дају различите резултате, онда или постоји грешка у једном или више алата или FOMDD модел је погрешан).

Напомена: горенаведене идеје су инспирисане теоријом категорија.^[5]^[6]

Апликације

Види још

FOSD метамодел—производне линије за производне линије
FOSD програм коцке—вишедимензионалне производне линије
FOSD алгебрске функције—основне операције од којих су дефинисане FOSD карактеристике (0-ари и 1-ари) функције
FOSD функција интеракције—главни концепти за игране интеракције

Рефренце

^ ^а ^б ^в „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”. Архивирано из оригинала 03. 08. 2003. г. Приступљено 11. 01. 2016.
^ ^а ^б „Scaling Step-Wise Refinement” (PDF).
^ ^а ^б ^в ^г „Feature Oriented Model Driven Development: A Case Study for Portlets” (PDF).
^ ^а ^б ^в „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] а ^б ^в „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”. Архивирано из оригинала 03. 08. 2003. г. Приступљено 11. 01. 2016.

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

[fomdd-5] а ^б ^в ^г „Feature Oriented Model Driven Development: A Case Study for Portlets” (PDF).

[genmeta-6] а ^б ^в „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]