Обласно-специфично мултимоделовање

Обласно-специфично мултимоделовање је софтверско развојна парадигма где где се сваки преглед прави што одређенији као посебан обласно-специфичан језик (ОСЈ).

Успешан развој модерног предузетног система захтева састајење више погледа. Пословни аналитичари, обласни експерти, интеракцијски дизајнери, експерти базе бодатака, и порграмери са различитим експертизама учествују у процесу стварања таквог система. Њихови различити производи рада морају бити руковођени, сврстани, и интегрисани да би произвели систем који ради. Сваки учесник развојног процеса има посебан језик скројен да реши проблеме специфичне његовом погледу на систем. Изазов је у интеграцији ових различитих погледа и избегавање потенцијалних какофиније више различитих језика је координацијски проблем.

Обласно-специфично мултимоделовање је обећавајуће када се пореди са традиционалнијим развојним парадигмима као што су једно-језичко програмирање и опште наменско моделовање. Да би искористили бенефиције ове нове парадигме, морамо да решимо координациски проблем. Овај проблем је такође познат као фрагментациски проблем у контексту Глобалног моделног менаџмента.

Један предлог за решавање овог проблема је координациски метод. Ово је метод у три корака за савлађивање препрека интеграције различитих погледа и координације више језика. Метод прописује како да (1) идентификује и (2) специфицира референце преко језичких граница, то је преклапање између различитих језика. Коначно, метода нуди конкретне предлоге о томе како да (3) примени ово знање у стварном развоју у форми доследности, навигације, и руковања.

Мотивациони пример

Предузетни системи базирани на више обласно-специфичних језика су обилни. Језици са метамоделом дефинисаним у the Проширивом језику за обележавање (XML) имају особено широко присвајање. Да би илустровали развој са више језика, извући ћемо пример из истраживања случаја: The Apache Open For Business (OFBiz) систем. Кратко изјављено, OFBiz je ERP систем који укључује стандардне компоненте као што су инвентар, рачуноводство, електронска трговина итд. Ови компоненти су имплементирани од стране мешавине  XML-базираних језика и регуларног Јава кода. Као пример, хајде да се фокусирамо на менаџмент садржине компонент, нарочито као пример у којем административни корисник креира онлајн веб анкету приказану у слици испод. Овај пример ће се односити као створити анкету пример.

Фигура показује слику административног интерфејса од апликације менаџмента садржине у покренутој OFBiz инстанци. Да би креирао анкету, корисник попуњава поља улазне форме и притиска дугме ажурирања. ово креира нову анкету која мозе да буде мењана и касније објављена на a предње крајњој страници у OFBiz. Закулисано, овај случај употребе користи наколицину артефаката писаних у различитим језицима. У овом примеру, хајде да се фокусирамо на само три оваква језика: Entity, Service, и Form ОСЈ.

Ова три језика грубо одговарају структуралној, понашанској, и корисничкој сучељској бризи у OFBiz. Ентитет ОСЈ се користи да опише основни модел података и самим тим начин на који ће креирана анкета бити сачувана. Service ОСЈ се користи да опише интерфејс услуге која је позвана када корисник притисне дугме  ажурирања. Коначно, Form ОСЈ се користи да опише визуелни приказ форме. Иако су три језика скројена за различите ствари, они не могу бити потпуно раздвојени. Кориснички интерфејс позива одређену апликацијску логику и ова апликацијска логика манипулише подацима апликације. Ово је оприме за не-ортогоналне бриге. Језици се преклапају зато што се бриге које они представљају не могу раздвојити у потпуности. Испитајмо ова три језика у маниру одоздо-нагоре и да укажемо на њихова преклапања.

Ентитет ОСЈ

Ентитет ОСЈ дефинише структуру података у OFBiz. Списак испод показује дефиницију анкете ентитета која је пословни објекат који репрезентује концепт анкете. Код у списку је само-објашњив: Ентитет назван анкета је дефинисан са 10 поља. Свако поље има име и тип. Поље које је анкетирано се користи као примарни кључ. Ова дефиниција је очитана од стране централне компоненте у OFBiz назване ентитет машине. Ентитет машине инстанцира одговарајући пословни објекат. Сврха ентитета машине је да управља трансакцијским својствима свих пословних објеката и да врши интеракцију са различитим упорним механизмима као што су Повезивање Јаве базе података, Предузетни ЈаваБинс или чак неки системи старе методе.

 <entity entity-name="Survey" ... title="Survey Entity">
   <field name="surveyId" type="id-ne"/>
   <field name="surveyName" type="name"/>
   <field name="description" type="description"/>
   <field name="comments" type="comment"/>
   <field name="submitCaption" type="short-varchar"/>
   <field name="responseService" type="long-varchar"/>
   <field name="isAnonymous" type="indicator" .../>
   <field name="allowMultiple" type="indicator" .../>
   <field name="allowUpdate" type="indicator" .../>
   <field name="acroFormContentId" type="id-ne" .../>
   <prim-key field="surveyId"/>
 </entity>

Сервис ОСЈ

Сервисни ОСЈ спецификује интерфејс сервиса у OFBiz. Свака услуга енкапсулира део апликацијске логике система. Сврха овог језиka је да има униформну апстракцију преко разних имплементираних механизама. Индивидуалне услуге се могу имплементирати у Јави, скриптном језику, или се може користити правилник. Списак испод показује интерфејс креирајАнкету сервиса.

Изузев имена, сервисни елемент, специфицира локацију и призива команду имплементације за ову услугу. Уобичајено име-ентитета атрибута одређује да се ова услуга односи на Анкетни ентитет који је дефинисан у претходном списку. Ово је преклапање између два језика, посебно тзв мека референца. Модел у услузи ОСЈ се односи на модел у ентитету ОСЈ. Ова референца се користи у два само атрибуирана елемента испод који одређују улаз и излаз службе у форми искуцаних атрибута. Као улаз, сервис прихвата атрибуте који одговарају свим не-примарним кључним (nonpk) пољима анкетног ентитета и ови атрибути су опционални. Као излаз, услуга враћа атрибуте који одговарају приамрном кључним (pk) областима анкете, т.ј., у овом случају анкетирано подручје, и ови атрибути су обавезни. Сврха рефернци преко језика је у овом случају да смање редундантност. Атрибути креирајАнкету услуге одговарају пољима анкетног ентитета и зато је само неопходно да се специфицирају једанпут.

 <service name="createSurvey" default-entity-name="Survey" ...
          location="org/ofbiz/content/survey/SurveyServices.xml"
          invoke="createSurvey"> ...
   <permission-service service-name="contentManagerPermission"
                       main-action="CREATE"/>
   <auto-attributes include="nonpk" mode="IN" optional="true"/>
   <auto-attributes include="pk" mode="OUT" optional="false"/>
 </service>

Форма ОСЈ

Форма ОСЈ се користи да опише план и визуелни изглед унесених форми у кориснички интерфејс. Језик се састоји од обласних концепата као што су форма и поље. Списак испод показује имплементацију форме мењајућихАнкета. Овог пута форма ОСЈ се преклапа са услугом ОСЈ. Циљни атрибут форме и алт-циљних елемената наводи да улаз из подношења ове форме треба да буде усмерен или ка ажурирајАнкету или ка КреирајАнкету услугама. Елемент ауто-сервисних поља прецизира да би форма требало да укључује и поље које одговара сваком од атрибута ажурирајАнкету услуге (које су сличне атрибутима креирајАнкету услуге). Ово производи сличан ефекат побољшања дефиниција из другог модела као што је случај са аутоматским-атрибутским елементима у претходном списку. Даље, можемо да видимо да је могуће променити изглед ових увезених поља као што су isAnonymous. Finally, a submitButton који су додати са локализованим називом таква да корисник може да пошаље његове податке до референтне услуге.

 <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 use-when="survey!=null" name="surveyId" ... />
   ...
   <field name="isAnonymous">
     <drop-down no-current-selected-key="N" allow-empty="false">
       <option key="Y"/><option key="N"/>
     </drop-down>
   </field>
   ...
   <field name="submitButton" title="${uiLabelMap.CommonUpdate}"
          widget-style="smallSubmit">
     <submit button-type="button"/>
   </field>
 </form>

Креирај анкету пример, описан овде, је имплементација коришћењем модела у три различита језика. Комплетна имплементација заправо подразумева још више језика као што су Екран ОСЈ који одређуеј план екрана где је форма постављена, и  Миниланг ОСЈ који је подацима-манипулативни језик коришћен за имплементацију услуге. Ипак, ови језици илуструју главну идеју прављења сваке бриге конкретне. Овај пример такође показује прост начин смањивања сувишности дозвољавајући језицима да се преклапају помало.

Више-степено прилагођавање

Обласно-специфични језици, као ови већ описани, имају лимитирану изражајност. Често је неопходно додавати комадиће кода у језику опште-намене као што је Јава да би додавали особену функционалност која је изван оквира језика. Овај мето се назива више-степено пролагођавање. Пошто се овај метод често користи у уређењима са више језика, ми ћемо га илустровати помоћу наставка овог примера. Хајде да назовемо ово Направи ПДФ пример.

Претпоставимо да желимо да направимо ПДФ фајл за сваки анкетни одговор онлајн анкетама које су корисници креирали. Прављење ПДФ фајла је изван оквира наших језика тако да ми морамо да напишено неки Јава код који може да позове ПДФ библиотеку треће стране која ће да обави ову специјализовану функционалност. Два артефакта су потребна:

Прво, додатни услужни модел, као што је приказано испод, у сервисном ОСЈ који дефинише интерфејс од конкретне услуге такве да јој се може приступити на моделарском нивоу. Сервисни модел описује локацију имплементације и описује шта су улазни и излазни атрибути.

 <service name="buildPdfFromSurveyResponse" engine="java"
   location="org.ofbiz.content.survey.PdfSurveyServices"
   invoke="buildPdfFromSurveyResponse">
   <attribute name="surveyResponseId" mode="IN"
     optional="false" .../>
   <attribute name="outByteWrapper" mode="OUT"
     optional="false" .../>
 </service>

Друго, потребни су нам фрагменти кода, као што је приказано испод, који садрже стварне имплементације ове услуге. Сервис мозе да има више улаза и излаза тако да је улазни Јава метод мапа, звана контекст, из имена аргумената до до вредности аргумената и враћа излаз у форми друге мапе, зване резултати.

 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 механизам за учење и истраживање зато што програмери типично користе алате да науче пробајући. Постоје три посебна подручја где су алата за обласно-специфичне моделе од помоћи:

1. Разумевање језика
2. Разумевање језичких интеракција
3. РАзумевање како користити језике

Прво, разумевање језика може да буде тешко и у случају XML-базираних обласно-специфичних језика честа и интуитивни приговор је приговор синкасним питањима. Овај аргумент се може констатовати на следећи начин: “Различити језици су тешки за разумевање и само додају конфузији за то што је њихова XML-базирана синтакса посебно опширна и неразумљива. коришћење једног опште-наменског језиак као Јава би било боље зато што онда програмери могу да се ослоне на синтаксу коју већ знају”. Док је ова примедба сигурно битна, она промашује главну тачку. XML или слични репрезентациски формати можда нису синтакса са којом ће програмери стварно да раде. Једна од предности коришћења XML-базираних обласно-специфичних језика је да ми можемо да ми можемо да обезбедимо обласно-специфичне уређиваче. Слика испод показује како хипотетички уређивач за Ентитет ОСЈ би могао да изгледа. Овај уређивач показује област у у простом и визуелно привлачном маниру али као да корсити XML представљање (а можда и конфигурацијски план) испод.

Као што ми можемо да се жалимо да је XML лош избор, можемо да приговоримо да је и опште-наменски језик попут Јаве лош избор за неке задатке. Штавише, програмери могу да се осећају мање застрашени од стране уређивача у слици него од списка кодова у XML или Јави. Ако прихватимо да је синтакса битна онда коришћење различитих језика са скројеним уређивачима постаје разумна стратегија. Једноставност овог уређивача чини језик лакшима за разумевање и самим тим лакшим за коришћење. Другим речима, приговор синтакса је битна је можда прави разлог зашто ми истражујемо поље обласно-специфичних језика.

Друго, језичке интеракције откривају односе између језика. Програмери треба да буду способни да скачи између повезаних елемената у различитим артефактима. Лакоћа навигације између различитих софтверских артефаката је важан критеријум за алате у традиционалним развојним окружењима. Иако нисмо изводили емпиријске студије у овој области, претпостављамо да одговарајућа навигација подстиче повећану продуктивност. Ову тврдњу подржава обзервација да сва бина развојан окружења данас нуде доста софистицирано навигационо постројење као што је тип хијерахиског прегледача или способност да брзо лоцира и пређе са референце на медотску дефиницију. Развојан окружења могу да обезбеде ове навигационе објекте зато што они одржавају константно ажуриран модел изворних датотека у форми апстрактног синтаксног дрвета.

У развојном окружењу са више језика, навигација је много тежа. Постојећа окружења нису спремљена за парсинг и предтављање ОСЈ модела као опстрактних синтаскинх грана за произвољне а можда и апликационо-специфичне језике као што су језици  из претходног примера. Даље без овог унутрашњег заступања, постојећа окружења не могу да реше ни унутар- ни међу-језичке референце за такве језике и самим тим не могу да обезбеде корисну навигацију. Ово значи да порграмери морају да одржавају концептуални модел о томе како су делови њихових система повезани. нови алати са навигационим објектима усмерени на више језика ће са друге стране бити од велике помоћу у разумевању односа између језика. Усмислу креирај анкету примера такви алати би требало да показују односе између три језиак користећи меке референце као навигацијске тачке.

Треће, да би разумели језичку корисност морамо да будемо способни да уочимо разлику између исправних операција уређивања и погрешних операција уређивања у нашем развојном окружењу. традиционална развојна окружења имају дуге обезбеђене смернице током писања програма. Постепена компилација дозвољава окружењима да нуде детаљисане сугестије програмеру као што је како да попуне изјаву . Више наметљиве врсте смерница такође постоје, на пример, синтаксно-оријентисани уређивачи где само улаз у складу са граматиком може бити унесен. Генерични текстуални уређивачи који могу бити параметризовани са граматиком језика постоје већ дуже време.

Постојећи уређивачи не узимају своју унутрашње-језичке константне односе у обзир када дају смернице. У претходном примеру, идеални уређивач би требало, на пример, да буде у стању да сугерише креирајАнкету сервис као валидну вредност када програмер уређује циљне атрибуте у Форми дефиницији. Окружење које би могло да разуме о атрефактима различитих језика би могло такође да помогне програмеру да идентификује програмска стања где је постојала локална али не и глобална константност. Таква ситуација може да наиђе када је модел добро формиран и самим тим локално константан али у исто време крши унутрашња језичка ограничења. Смернице или интелигентна помоћ  у форми предлога како да се комплетира модел биле би корисне за уређења са више језика и комплексним ограничењима доследности. Алатно-предложене уређивачке операције би могле да направе за програмере лакши старт процеса учења како да користе језике.

Координација као технички изазов

Технички аспект координацијског проблема је у суштини питање спровођења доследности. Како моземо да пронађемо недоследности преко модела из више језика у моделарско време? Да би потпуно разумели комплексност захтева доследности система базирани на више језика, корисно је да прерадимо наш концепт доследности.

Доследност може бити ли унутрашња или међу-доследност. Унутрашња-доследност се бави доследношћу елемената једном моделу. Захтеви овде су да модел мора да се прилагоди свом метамоделу, т.ј., да буде синтетички добро формиран. У смислу креирај анкету примера, ентитет модел мора да се, на пример, прилагоди ХСД шеми за Ентитет ОСЈ. Ова шема је метамодел Ентитета ОСЈ и она образлаже како елементи могу бити састављени и шта су, до неке мере, ваљане области атрибута.

Међу-доследност је постигнута када референце међу језичким границама могу бити решене. Овај тип доследности се може даље поделити на (1) модел-до-модела доследност and (2) модел-до-кода доследност. Модел-до-модела доследност се односи на референцијални интегритет као и ограничења на високом нивоу система. У креирај анкету примеру, почетно-ентитетско-име атрибута из сервисног листинга се односи наименски атрибут из Ентитет списка. Ако променимо једну од ових вредности без ажурирања друге, прекидамо референцу. Више ограничења доследности високог нивоа преко различитих модела такође постоје и о њима касније. Пројекат може да иам одређене обрасце или конвенције за именовање и повезивање модела елемената. Садашња развојна окружења морају бити скројена специфичним језицима са ручно писаним додацима или сличним механизмима у циљу спровођења доследности међу језицима као што су они из претходног примера.

Модел-до-кода доследност је суштински услов у више-степеном прилагођавању. Када су модели допуњени са фракцијама кода као у направи ПДФ примеру, неопходно је проверити да модели и код стварно пристају. Ово је делимично питање сигурности да се меке референце између модела и кода неће прекинути, слично референтном интегритету у модел-домедела доследности. Али је такође питање сигурности да код не крши очекивања постављена у моделу. У Направи ПДФ примеру, модел прецизира да outByteWrapper ће увек бити део изалаза, т.ј., outByteWrapper кључ је стављен на мапи резултата. Анализа кода показује да ће outByteWrapper само бити део излаза ако нема изузетака пре линије 10. Другим речима, неке могуће егзекуције ће да прекрше спецификацију на моделарском нивоу. Више генерално, можемо да констатуејмо да више-степено прилагођавање намеће веома фине структуре ограничења на укљученим моделима и фрагментима кода.

Решавање проблема координације

Координациски проблем се јавља из чињенице да се више језика користи у једном систему. Две претходне подсекције су илустровале да овај проблем има и концептуалну страну и техничку страну ниског нивоа. Изазове, које имамо описане, су стварни а не хипотетички изазови. Конкректно, суочавали смо се са овим изазовима у две конкретне и репрезентативне студије случаја: предузетни систем планирања ресурса, OFBiz, и систем заштите здравља, окружни здравствени информациони систем (ОЗИС). Оба случаја су системи средње величине која су у стварној индустријској примени. Наше решење практичних проблем са којима смо се сусретали током нашег рада са овим системима су скупови смерница и прототипова. У следећем тексту, ми ћемо увести општи концептуални оквир који укључује смернице и прототипове у кохерентну методу: координациску методу.

Координацијска метода

Циљ координациске методе је да реши координациски проблем и самисм тим обезбеди бољу подршку за развој са више језика. Да би правилно ценили овај метод, битно је да се разуме да он не прописује дизајн индивидуалних језика. Доста метода и алата су већ предложени за ово. Ова метода претпоставља постојање уређења са више обласно-специфичних језика. Дајући сваком уређење, може се применити метод. Метода се сатоји из три корака показана у диаграму испод. Сваки корак се састоји од неколико делова који су приказани као мале кутије у диаграму. Кутије са испрекиданим линијама показују аутоматске процесе а кутиеј са пуним линијама показују мануалне. У следећем тексту, објаснићемо ове кораке у мало више детаља.

Корак 1: идентификација

Циљ идентификационог корака је да идентификује језичке преклопе. Као што је описано у приемру, преклоп је поље где се интереси два језика укрштају. Мека референца из Форме ОСЈ у Сервис ОСЈ и из Сервис ОСЈ у Ентитет ОСЈ код креирај анкету случају употребе су примери оваквих преклапања. Још један пример је случај где се прилагођени фрагменти кода користе за проширење модела. Оваква прекалпања су честа када је експресивност језика опште-намене потребна за имплементацију специализованих захтева који су изван оквира модела. Идентификациски корак мможе бити или мануелни или аутоматски процес у зависности од сложености преклапања. Када су преклапања пронађена и начињена експлицитним, ова инфорамција се користи као улаз за други корак у методи: Спецификациски корак.

Корак 2: спецификација

Циљ корака спецификације је да креира координациски модел који одређује како језици међусобно делују. Референце преко језичких граница у систему предстваљају метод координације за тај одређени систем. Он је створен мапирањем главних софтверских артефаката у заједничку репрезентацију. Додатне инфорамције као што су обласна- или апликационо-специфична  ограничења могу такође бити шифрована да обезбеде богат приказ. Координациски модел је базиран на генеричким информацијама као што је језичка граматика и ограничења као и апликационо специфичне инфорамције као што су конкректни модели и апликационо-специфична ограничења. Ово значи да иако су исти језици коришћени преко више производа, сваки производ има спецификацију свог посебног координацијског модела. Координацијски модел је коришћен као база за различите форме резоноваља у финалном кораку методе: апликацијском кораку.

Корак 3: апликација

Циљ апликацијског корака је да искористи коодринациски модел. координациски модел дозвољава алатима изведу три слоја корисних информација. Прво, координациски модел мозе бити коришћен да спроведе конзисзензност преко више језика. Координацијски модел прецизира релације доследности као када елементи из различитих језика могу да се односе једни на друге. Алати могу да примене референцијални интегритет и да изводе статчке провере финалног система пре распоређивања. Друго, везе доследности се користе за навигацију, визуелизацију и мапирање мреже различитих језика у развојно уређењу. Ова информација се користи да се брзо повежу и односе елементи из различитих језика и да се обезбеди следљивост међу различитим моделима. Треће, на основу доследности односа и навигационе инфорамције о томе како су елементи повезани, алати могу да обезбеде смернице, посебно завршетак или помоћ. Моделни завршетак мозе на пример бити обезбеђен у генеричном маниру преко обласно-специфичних алата.

Процена координацијске методе

Координацијска метода се може најбоље видети као концептуални оквир који прописује одређен процес рада када се ради са више језика. Ува три узастопна корака кај чине овај процес рада нису подржана од стране интегрисане радне тезге или развојног окружења. Фокус је пре на продуживање програмерових постојећих окружења да би подржавали (1) идентификацију, (2) спецификацију, и (3) апликацију. Главна предност овог приступа била је да су програмери стварно тестирали наш рад и дали нам повратне инфорамције. Овакав начин процене методе је вредан зато што смањује ризик решавања чисто хипотетичког проблема. Неколико радова уводи различите кораке координацијске методе, извештава о овој процени, и елаборира о техничким аспектима сваког индивидуалног експеримента. Генерално, резултати су били обећавајући: значајан број грешака је био пронађен у продукцијским системима и дат је повод за конструктивни диалог са програмерима о будућим алатним захтевима. Процес развоја базиран на овим смерницама и подржан од стране алата представља озбиљан покушај да се реши координацијски проблем и да обласно-специфично мултимоделовање буде практичан предлог.

Види још

• Обласно-специфично моделовање
• Обласно-специфичан језик
• Моделом-вођен инжењеринг