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

Парадигме програмирања
Језик дејства Агентно-оријентисано програмирање Агентно низно оријентисано програмирање Аутоматно програмирање Паралелно израчунавање Релативистичко програмирање Програмирање покретних података Декларативно програмирање (контраст: Императивно програмирање) Ограничења Принудно логичко програмирање Упоредно принудно логичко програмирање Податак-ток програмирање Проток основе Мобилни оријентисани (табела) Реактивно програмирање Функционално програмирање Функционално логичко програмирање Чисто функционални програмски језик Логичко програмирање Абдуктивна логика програмирања Одговор сет програмирање Упоредно логичко програмирање Функционално логичко програмирање Индуктивно логичко програмирање Динамички програмски језик Крајње-корисничко развијање Програмирање вођено догађајима Сервис оријентисана архитектура Програмирање вођено временом Израз-оријентисан програмски језик Одлика-оријентисаног програмирања Програмирање на нивоу функција (контраст: програмирање на нивоу вредности) Генеричко програмирање Императивно програмирање (контраст: Декларативно програмирање) Писменост Процедура Индуктивно програмирање Језички-оријентисано програмирање Природни програмски језик Специфичне дисциплине Обласно-специфичан језик Граматички оријентисано програмирање Дијалект Намерно програмирање Метапрограмирање Аутоматско програмирање Рефлексија Атрибут-оријентисано програмирање Хомоиконичност Шаблон Политика на бази дизајна Неструктуирано програмирање (контраст: Структуирано програмирње) Поредак Недетерминистичко програмирање Паралелна обрада Процес-оријентисано програмирање Прећутно програмирање Конкатенативни програмски језик Семантички-оријентисано програмирање Структурно програмирање (контраст: Неструктуирано програмирање) Блок структуирање Модуларно програмирање (контраст: Монолитна апликација) Објектно оријентисано програмирање (ООП) Класе-основе програмирања Паралелно објектно-оријентисано програмирање Прототип-основе програмирања раздвајање проблема: Аспектно-оријентисано програмирање Улога-оријентисано програмирање Наслов-оријентисано програмирање Рекурзија Програмирање на нивоу вредности (контраст: Програмирање на нивоу функција) Пробабилистички програмски језик Појам
п р у

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

ФОСД је проистекао из слоја на бази дизајна и нивоа апстракције у мрежним протоколима и проширивим базама података у касним 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

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

  p1 = j • f       -- програм p1 има карактеристике j и f
  p2 = j • h       -- програм p2 има карактеристике j и h
  p3 = i • j • h   -- програм p3 има карактеристике 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-у.

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

  p2 = j • f                            -- GenVoca експресија
     = [${\displaystyle \Delta }$gj, ${\displaystyle \Delta }$sj, ${\displaystyle \Delta }$dj] • [gf, sf, df]   -- замена
     = [${\displaystyle \Delta }$gj•gf, ${\displaystyle \Delta }$sj•sf, ${\displaystyle \Delta }$dj•df]         -- саставити торке елемент-мудар

То јест, граматика p је основна граматика састављена са екстензијом (${\displaystyle \Delta }$g_j•g_f), извор p је основа извора састављена са његовог продужења (${\displaystyle \Delta }$s_j•s_f),и тако даље. Као елементи delta торке могу саме бити delta торке, састав recurses, нпр, ${\displaystyle \Delta }$s_j•s_f= [${\displaystyle \Delta }$c₁…${\displaystyle \Delta }$c_n]•[c₁…c_n]=[${\displaystyle \Delta }$c₁•c₁…${\displaystyle \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:

  ${\displaystyle \Delta }$bi • ${\displaystyle \Delta }$bj • javac • javacc = javac • javacc • ${\displaystyle \Delta }$gi • ${\displaystyle \Delta }$gj

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

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

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

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

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

Апликације

• Network Protocols
• Extensible Database Systems
• Data Structures
• Distributed Army Fire Support Simulator
• Production System Compiler
• Graph Product Line
• Extensible Java Preprocessors
• Web Portlets
• SVG Applications

Види још

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

Рефренце