Обласно-специфично мултимоделовање је софтверско развојна парадигма где где се сваки преглед прави што одређенији као посебан обласно-специфичан језик (ОСЈ).
Успешан развој модерног предузетног система захтева састајење више погледа. Пословни аналитичари, обласни експерти, интеракцијски дизајнери, експерти базе бодатака, и порграмери са различитим експертизама учествују у процесу стварања таквог система. Њихови различити производи рада морају бити руковођени, сврстани, и интегрисани да би произвели систем који ради. Сваки учесник развојног процеса има посебан језик скројен да реши проблеме специфичне његовом погледу на систем. Изазов је у интеграцији ових различитих погледа и избегавање потенцијалних какофиније више различитих језика је координацијски проблем.
Обласно-специфично мултимоделовање је обећавајуће када се пореди са традиционалнијим развојним парадигмима као што су једно-језичко програмирање и опште наменско моделовање. Да би искористили бенефиције ове нове парадигме, морамо да решимо координациски проблем. Овај проблем је такође познат као фрагментациски проблем у контексту Глобалног моделног менаџмента.
Један предлог за решавање овог проблема је координациски метод. Ово је метод у три корака за савлађивање препрека интеграције различитих погледа и координације више језика. Метод прописује како да (1) идентификује и (2) специфицира референце преко језичких граница, то је преклапање између различитих језика. Коначно, метода нуди конкретне предлоге о томе како да (3) примени ово знање у стварном развоју у форми доследности, навигације, и руковања.
Мотивациони пример Предузетни системи базирани на више обласно-специфичних језика су обилни. Језици са метамоделом дефинисаним у the Проширивом језику за обележавање (XML) имају особено широко присвајање. Да би илустровали развој са више језика, извући ћемо пример из истраживања случаја: The Apache Open For Business (OFBiz) систем. Кратко изјављено, OFBiz je ERP систем који укључује стандардне компоненте као што су инвентар, рачуноводство, електронска трговина итд. Ови компоненти су имплементирани од стране мешавине XML-базираних језика и регуларног Јава кода. Као пример, хајде да се фокусирамо на менаџмент садржине компонент, нарочито као пример у којем административни корисник креира онлајн веб анкету приказану у слици испод. Овај пример ће се односити као створити анкету пример.
Датотека:CreateSurvey-screen.png
Фигура показује слику административног интерфејса од апликације менаџмента садржине у покренутој OFBiz инстанци. Да би креирао анкету, корисник попуњава поља улазне форме и притиска дугме ажурирања. ово креира нову анкету која мозе да буде мењана и касније објављена на a предње крајњој страници у OFBiz. Закулисано, овај случај употребе користи наколицину артефаката писаних у различитим језицима. У овом примеру, хајде да се фокусирамо на само три оваква језика: Entity, Service, и Form ОСЈ.
Ова три језика грубо одговарају структуралној, понашанској, и корисничкој сучељској бризи у OFBiz. Ентитет ОСЈ се користи да опише основни модел података и самим тим начин на који ће креирана анкета бити сачувана. Service ОСЈ се користи да опише интерфејс услуге која је позвана када корисник притисне дугме ажурирања. Коначно, Form ОСЈ се користи да опише визуелни приказ форме. Иако су три језика скројена за различите ствари, они не могу бити потпуно раздвојени. Кориснички интерфејс позива одређену апликацијску логику и ова апликацијска логика манипулише подацима апликације. Ово је оприме за не-ортогоналне бриге. Језици се преклапају зато што се бриге које они представљају не могу раздвојити у потпуности. Испитајмо ова три језика у маниру одоздо-нагоре и да укажемо на њихова преклапања.
Ентитет ОСЈ Ентитет ОСЈ дефинише структуру података у OFBiz. Списак испод показује дефиницију анкете ентитета која је пословни објекат који репрезентује концепт анкете. Код у списку је само-објашњив: Ентитет назван анкета је дефинисан са 10 поља. Свако поље има име и тип. Поље које је анкетирано се користи као примарни кључ. Ова дефиниција је очитана од стране централне компоненте у OFBiz назване ентитет машине. Ентитет машине инстанцира одговарајући пословни објекат. Сврха ентитета машине је да управља трансакцијским својствима свих пословних објеката и да врши интеракцију са различитим упорним механизмима као што су Повезивање Јаве базе података, Предузетни ЈаваБинс или чак неки системи старе методе.
<prim-key field="surveyId"/>
Сервис ОСЈ Сервисни ОСЈ спецификује интерфејс сервиса у OFBiz. Свака услуга енкапсулира део апликацијске логике система. Сврха овог језиka је да има униформну апстракцију преко разних имплементираних механизама. Индивидуалне услуге се могу имплементирати у Јави, скриптном језику, или се може користити правилник. Списак испод показује интерфејс креирајАнкету сервиса.
Изузев имена, сервисни елемент, специфицира локацију и призива команду имплементације за ову услугу. Уобичајено име-ентитета атрибута одређује да се ова услуга односи на Анкетни ентитет који је дефинисан у претходном списку. Ово је преклапање између два језика, посебно тзв мека референца. Модел у услузи ОСЈ се односи на модел у ентитету ОСЈ. Ова референца се користи у два само атрибуирана елемента испод који одређују улаз и излаз службе у форми искуцаних атрибута. Као улаз, сервис прихвата атрибуте који одговарају свим не-примарним кључним (nonpk) пољима анкетног ентитета и ови атрибути су опционални. Као излаз, услуга враћа атрибуте који одговарају приамрном кључним (pk) областима анкете, т.ј., у овом случају анкетирано подручје, и ови атрибути су обавезни. Сврха рефернци преко језика је у овом случају да смање редундантност. Атрибути креирајАнкету услуге одговарају пољима анкетног ентитета и зато је само неопходно да се специфицирају једанпут. ... <permission-service service-name="contentManagerPermission" main-action="CREATE"/> <auto-attributes include="nonpk" mode="IN" optional="true"/> <auto-attributes include="pk" mode="OUT" optional="false"/>
Форма ОСЈ Форма ОСЈ се користи да опише план и визуелни изглед унесених форми у кориснички интерфејс. Језик се састоји од обласних концепата као што су форма и поље. Списак испод показује имплементацију форме мењајућихАнкета. Овог пута форма ОСЈ се преклапа са услугом ОСЈ. Циљни атрибут форме и алт-циљних елемената наводи да улаз из подношења ове форме треба да буде усмерен или ка ажурирајАнкету или ка КреирајАнкету услугама. Елемент ауто-сервисних поља прецизира да би форма требало да укључује и поље које одговара сваком од атрибута ажурирајАнкету услуге (које су сличне атрибутима креирајАнкету услуге). Ово производи сличан ефекат побољшања дефиниција из другог модела као што је случај са аутоматским-атрибутским елементима у претходном списку. Даље, можемо да видимо да је могуће променити изглед ових увезених поља као што су isAnonymous. Finally, a submitButton који су додати са локализованим називом таква да корисник може да пошаље његове податке до референтне услуге. <code> <form name="EditSurvey" type="single" target="updateSurvey" title="" default-map-name="survey"> <alt-target use-when="survey==null" target="createSurvey"/> <auto-fields-service service-name="updateSurvey"/>
... <field name="isAnonymous"> <drop-down no-current-selected-key="N" allow-empty="false">
</drop-down> </field> ...
</form></code> Креирај анкету пример, описан овде, је имплементација коришћењем модела у три различита језика. Комплетна имплементација заправо подразумева још више језика као што су Екран ОСЈ који одређуеј план екрана где је форма постављена, и Миниланг ОСЈ који је подацима-манипулативни језик коришћен за имплементацију услуге. Ипак, ови језици илуструју главну идеју прављења сваке бриге конкретне. Овај пример такође показује прост начин смањивања сувишности дозвољавајући језицима да се преклапају помало.
Више-степено прилагођавање Обласно-специфични језици, као ови већ описани, имају лимитирану изражајност. Често је неопходно додавати комадиће кода у језику опште-намене као што је Јава да би додавали особену функционалност која је изван оквира језика. Овај мето се назива више-степено пролагођавање. Пошто се овај метод често користи у уређењима са више језика, ми ћемо га илустровати помоћу наставка овог примера. Хајде да назовемо ово Направи ПДФ пример.
Претпоставимо да желимо да направимо ПДФ фајл за сваки анкетни одговор онлајн анкетама које су корисници креирали. Прављење ПДФ фајла је изван оквира наших језика тако да ми морамо да напишено неки Јава код који може да позове ПДФ библиотеку треће стране која ће да обави ову специјализовану функционалност. Два артефакта су потребна:
Прво, додатни услужни модел, као што је приказано испод, у сервисном ОСЈ који дефинише интерфејс од конкретне услуге такве да јој се може приступити на моделарском нивоу. Сервисни модел описује локацију имплементације и описује шта су улазни и излазни атрибути.
Друго, потребни су нам фрагменти кода, као што је приказано испод, који садрже стварне имплементације ове услуге. Сервис мозе да има више улаза и излаза тако да је улазни Јава метод мапа, звана контекст, из имена аргумената до до вредности аргумената и враћа излаз у форми друге мапе, зване резултати. public static Map buildPdfFromSurveyResponse (DispatchContext dctx , Map context) { String id = (String) context.get("surveyResponseId"); Map results = new HashMap(); try { ...the response is retrieved from the database... ...a pdf is built from the response... ...the pdf is serialized as a bytearray... ByteWrapper outByteWrapper = ...; results.put("outByteWrapper",outByteWrapper ); } catch (Exception e) {} return results;
Метода више-степеног прилагођавања користи меке референце сличне креирај анкету примеру. Главна разлика је да је референца овде између модела и кода а не између модела и модела. Предност, у овом случају, је да страна Јава библотека за прављење ПДФова се може задужити. Још једна типична апликација је да се користе фрагменти Јава кода да се позову спољне вебуслуге и унесу резултати у одговарајућем формату.
Координацијски проблем Овај пример илуструје неке од предности коришћења више језика у развијању. Ипак, такође постоје тешкоће повезане са оваквим начином развоја. Ове потешкоће потичу од обзервације да шро више различитих врста артефаката ми искористимо у нашем процесу, више координације између програмерских напона је потребно. Ми ћемо се односити на ове проблеме као координацијски проблем. Координацијски проблем има концептуални и технички аспект. Концептуално, главни проблем је разумети различите језике и њихову интеракцију. Да се ваљано дизајнирају и координирају модели у више језика, програмери морају да имају довољно разумевање о томе како језици узајамно делују. Технички, главни проблем је да се да се спроведе доследност. Алатке морају бити обезбеђене да рано открију недоследности, т.ј., у моделарско време, и да помогну програмерима у исправљању ових недоследности. у следећем тексту, испитаћемо ова два аспекта детаљније.
Координација као концептуални изазов Први проблем са којим се програмери сусретну настаје када започну са развојем са више језика у језичкој какофонији. Учење различитих језика и разумевање њихових интеракција је потребно да би се направио смисао од комплексних композиција артефаката. OFBiz оквир на пример има седамнаест различитих језика и више од 200 000 линија обласно-специфичног језичког кода тако да комплексност може да буде брилично велика! тренутно не постоји ниједна установљена метода категоризације различитхи језика таква да програмери могу брзо да дођу до оперативних разумевања. Алатке су имплементиране овде као ad hoc механизам за учење и истраживање зато што програмери типично користе алате да науче пробајући. Постоје три посебна подручја где су алата за обласно-специфичне моделе од помоћи: Разумевање језика Разумевање језичких интеракција РАзумевање како користити језике