Oblasno-specifično multimodelovanje

Oblasno-specifično multimodelovanje je softversko razvojna paradigma gde gde se svaki pregled pravi što određeniji kao poseban oblasno-specifičan jezik (OSJ).

Uspešan razvoj modernog preduzetnog sistema zahteva sastajenje više pogleda. Poslovni analitičari, oblasni eksperti, interakcijski dizajneri, eksperti baze bodataka, i porgrameri sa različitim ekspertizama učestvuju u procesu stvaranja takvog sistema. Njihovi različiti proizvodi rada moraju biti rukovođeni, svrstani, i integrisani da bi proizveli sistem koji radi. Svaki učesnik razvojnog procesa ima poseban jezik skrojen da reši probleme specifične njegovom pogledu na sistem. Izazov je u integraciji ovih različitih pogleda i izbegavanje potencijalnih kakofinije više različitih jezika je koordinacijski problem.

Oblasno-specifično multimodelovanje je obećavajuće kada se poredi sa tradicionalnijim razvojnim paradigmima kao što su jedno-jezičko programiranje i opšte namensko modelovanje. Da bi iskoristili beneficije ove nove paradigme, moramo da rešimo koordinaciski problem. Ovaj problem je takođe poznat kao fragmentaciski problem u kontekstu Globalnog modelnog menadžmenta.

Jedan predlog za rešavanje ovog problema je koordinaciski metod. Ovo je metod u tri koraka za savlađivanje prepreka integracije različitih pogleda i koordinacije više jezika. Metod propisuje kako da (1) identifikuje i (2) specificira reference preko jezičkih granica, to je preklapanje između različitih jezika. Konačno, metoda nudi konkretne predloge o tome kako da (3) primeni ovo znanje u stvarnom razvoju u formi doslednosti, navigacije, i rukovanja.

Motivacioni primer

Preduzetni sistemi bazirani na više oblasno-specifičnih jezika su obilni. Jezici sa metamodelom definisanim u the Proširivom jeziku za obeležavanje (XML) imaju osobeno široko prisvajanje. Da bi ilustrovali razvoj sa više jezika, izvući ćemo primer iz istraživanja slučaja: The Apache Open For Business (OFBiz) sistem. Kratko izjavljeno, OFBiz je ERP sistem koji uključuje standardne komponente kao što su inventar, računovodstvo, elektronska trgovina itd. Ovi komponenti su implementirani od strane mešavine  XML-baziranih jezika i regularnog Java koda. Kao primer, hajde da se fokusiramo na menadžment sadržine komponent, naročito kao primer u kojem administrativni korisnik kreira onlajn veb anketu prikazanu u slici ispod. Ovaj primer će se odnositi kao stvoriti anketu primer.

Figura pokazuje sliku administrativnog interfejsa od aplikacije menadžmenta sadržine u pokrenutoj OFBiz instanci. Da bi kreirao anketu, korisnik popunjava polja ulazne forme i pritiska dugme ažuriranja. ovo kreira novu anketu koja moze da bude menjana i kasnije objavljena na a prednje krajnjoj stranici u OFBiz. Zakulisano, ovaj slučaj upotrebe koristi nakolicinu artefakata pisanih u različitim jezicima. U ovom primeru, hajde da se fokusiramo na samo tri ovakva jezika: Entity, Service, i Form OSJ.

Ova tri jezika grubo odgovaraju strukturalnoj, ponašanskoj, i korisničkoj sučeljskoj brizi u OFBiz. Entitet OSJ se koristi da opiše osnovni model podataka i samim tim način na koji će kreirana anketa biti sačuvana. Service OSJ se koristi da opiše interfejs usluge koja je pozvana kada korisnik pritisne dugme  ažuriranja. Konačno, Form OSJ se koristi da opiše vizuelni prikaz forme. Iako su tri jezika skrojena za različite stvari, oni ne mogu biti potpuno razdvojeni. Korisnički interfejs poziva određenu aplikacijsku logiku i ova aplikacijska logika manipuliše podacima aplikacije. Ovo je oprime za ne-ortogonalne brige. Jezici se preklapaju zato što se brige koje oni predstavljaju ne mogu razdvojiti u potpunosti. Ispitajmo ova tri jezika u maniru odozdo-nagore i da ukažemo na njihova preklapanja.

Entitet OSJ

Entitet OSJ definiše strukturu podataka u OFBiz. Spisak ispod pokazuje definiciju ankete entiteta koja je poslovni objekat koji reprezentuje koncept ankete. Kod u spisku je samo-objašnjiv: Entitet nazvan anketa je definisan sa 10 polja. Svako polje ima ime i tip. Polje koje je anketirano se koristi kao primarni ključ. Ova definicija je očitana od strane centralne komponente u OFBiz nazvane entitet mašine. Entitet mašine instancira odgovarajući poslovni objekat. Svrha entiteta mašine je da upravlja transakcijskim svojstvima svih poslovnih objekata i da vrši interakciju sa različitim upornim mehanizmima kao što su Povezivanje Jave baze podataka, Preduzetni JavaBins ili čak neki sistemi stare metode.

 <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>

Servis OSJ

Servisni OSJ specifikuje interfejs servisa u OFBiz. Svaka usluga enkapsulira deo aplikacijske logike sistema. Svrha ovog jezika je da ima uniformnu apstrakciju preko raznih implementiranih mehanizama. Individualne usluge se mogu implementirati u Javi, skriptnom jeziku, ili se može koristiti pravilnik. Spisak ispod pokazuje interfejs kreirajAnketu servisa.

Izuzev imena, servisni element, specificira lokaciju i priziva komandu implementacije za ovu uslugu. Uobičajeno ime-entiteta atributa određuje da se ova usluga odnosi na Anketni entitet koji je definisan u prethodnom spisku. Ovo je preklapanje između dva jezika, posebno tzv meka referenca. Model u usluzi OSJ se odnosi na model u entitetu OSJ. Ova referenca se koristi u dva samo atribuirana elementa ispod koji određuju ulaz i izlaz službe u formi iskucanih atributa. Kao ulaz, servis prihvata atribute koji odgovaraju svim ne-primarnim ključnim (nonpk) poljima anketnog entiteta i ovi atributi su opcionalni. Kao izlaz, usluga vraća atribute koji odgovaraju priamrnom ključnim (pk) oblastima ankete, t.j., u ovom slučaju anketirano područje, i ovi atributi su obavezni. Svrha refernci preko jezika je u ovom slučaju da smanje redundantnost. Atributi kreirajAnketu usluge odgovaraju poljima anketnog entiteta i zato je samo neophodno da se specificiraju jedanput.

 <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>

Forma OSJ

Forma OSJ se koristi da opiše plan i vizuelni izgled unesenih formi u korisnički interfejs. Jezik se sastoji od oblasnih koncepata kao što su forma i polje. Spisak ispod pokazuje implementaciju forme menjajućihAnketa. Ovog puta forma OSJ se preklapa sa uslugom OSJ. Ciljni atribut forme i alt-ciljnih elemenata navodi da ulaz iz podnošenja ove forme treba da bude usmeren ili ka ažurirajAnketu ili ka KreirajAnketu uslugama. Element auto-servisnih polja precizira da bi forma trebalo da uključuje i polje koje odgovara svakom od atributa ažurirajAnketu usluge (koje su slične atributima kreirajAnketu usluge). Ovo proizvodi sličan efekat poboljšanja definicija iz drugog modela kao što je slučaj sa automatskim-atributskim elementima u prethodnom spisku. Dalje, možemo da vidimo da je moguće promeniti izgled ovih uvezenih polja kao što su isAnonymous. Finally, a submitButton koji su dodati sa lokalizovanim nazivom takva da korisnik može da pošalje njegove podatke do referentne usluge.

 <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>

Kreiraj anketu primer, opisan ovde, je implementacija korišćenjem modela u tri različita jezika. Kompletna implementacija zapravo podrazumeva još više jezika kao što su Ekran OSJ koji određuej plan ekrana gde je forma postavljena, i  Minilang OSJ koji je podacima-manipulativni jezik korišćen za implementaciju usluge. Ipak, ovi jezici ilustruju glavnu ideju pravljenja svake brige konkretne. Ovaj primer takođe pokazuje prost način smanjivanja suvišnosti dozvoljavajući jezicima da se preklapaju pomalo.

Više-stepeno prilagođavanje

Oblasno-specifični jezici, kao ovi već opisani, imaju limitiranu izražajnost. Često je neophodno dodavati komadiće koda u jeziku opšte-namene kao što je Java da bi dodavali osobenu funkcionalnost koja je izvan okvira jezika. Ovaj meto se naziva više-stepeno prolagođavanje. Pošto se ovaj metod često koristi u uređenjima sa više jezika, mi ćemo ga ilustrovati pomoću nastavka ovog primera. Hajde da nazovemo ovo Napravi PDF primer.

Pretpostavimo da želimo da napravimo PDF fajl za svaki anketni odgovor onlajn anketama koje su korisnici kreirali. Pravljenje PDF fajla je izvan okvira naših jezika tako da mi moramo da napišeno neki Java kod koji može da pozove PDF biblioteku treće strane koja će da obavi ovu specijalizovanu funkcionalnost. Dva artefakta su potrebna:

Prvo, dodatni uslužni model, kao što je prikazano ispod, u servisnom OSJ koji definiše interfejs od konkretne usluge takve da joj se može pristupiti na modelarskom nivou. Servisni model opisuje lokaciju implementacije i opisuje šta su ulazni i izlazni atributi.

 <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>

Drugo, potrebni su nam fragmenti koda, kao što je prikazano ispod, koji sadrže stvarne implementacije ove usluge. Servis moze da ima više ulaza i izlaza tako da je ulazni Java metod mapa, zvana kontekst, iz imena argumenata do do vrednosti argumenata i vraća izlaz u formi druge mape, zvane rezultati.

 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;
 }

Metoda više-stepenog prilagođavanja koristi meke reference slične kreiraj anketu primeru. Glavna razlika je da je referenca ovde između modela i koda a ne između modela i modela. Prednost, u ovom slučaju, je da strana Java bibloteka za pravljenje PDFova se može zadužiti. Još jedna tipična aplikacija je da se koriste fragmenti Java koda da se pozovu spoljne vebusluge i unesu rezultati u odgovarajućem formatu.

Koordinacijski problem

Ovaj primer ilustruje neke od prednosti korišćenja više jezika u razvijanju. Ipak,  takođe postoje teškoće povezane sa ovakvim načinom razvoja. Ove poteškoće potiču od obzervacije da šro više različitih vrsta artefakata mi iskoristimo u našem procesu, više koordinacije između programerskih napona je potrebno. Mi ćemo se odnositi na ove probleme kao koordinacijski problem. Koordinacijski problem  ima konceptualni i tehnički aspekt. Konceptualno, glavni problem je razumeti različite jezike i njihovu interakciju. Da se valjano dizajniraju i koordiniraju modeli u više jezika, programeri moraju da imaju dovoljno razumevanje o tome kako jezici uzajamno deluju. Tehnički, glavni problem je da se da se sprovede doslednost. Alatke moraju biti obezbeđene da rano otkriju nedoslednosti, t.j., u modelarsko vreme, i da pomognu programerima u ispravljanju ovih nedoslednosti. u sledećem tekstu, ispitaćemo ova dva aspekta detaljnije.

Koordinacija kao konceptualni izazov

Prvi problem sa kojim se programeri susretnu nastaje kada započnu sa razvojem sa više jezika u jezičkoj kakofoniji. Učenje različitih jezika i razumevanje njihovih interakcija je potrebno da bi se napravio smisao od kompleksnih kompozicija artefakata. OFBiz okvir na primer ima sedamnaest različitih jezika i više od 200 000 linija oblasno-specifičnog jezičkog koda tako da kompleksnost može da bude brilično velika! trenutno ne postoji nijedna ustanovljena metoda kategorizacije različithi jezika takva da programeri mogu brzo da dođu do operativnih razumevanja. Alatke su implementirane ovde kao ad hoc mehanizam za učenje i istraživanje zato što programeri tipično koriste alate da nauče probajući. Postoje tri posebna područja gde su alata za oblasno-specifične modele od pomoći:

1. Razumevanje jezika
2. Razumevanje jezičkih interakcija
3. RAzumevanje kako koristiti jezike

Prvo, razumevanje jezika može da bude teško i u slučaju XML-baziranih oblasno-specifičnih jezika česta i intuitivni prigovor je prigovor sinkasnim pitanjima. Ovaj argument se može konstatovati na sledeći način: “Različiti jezici su teški za razumevanje i samo dodaju konfuziji za to što je njihova XML-bazirana sintaksa posebno opširna i nerazumljiva. korišćenje jednog opšte-namenskog jeziak kao Java bi bilo bolje zato što onda programeri mogu da se oslone na sintaksu koju već znaju”. Dok je ova primedba sigurno bitna, ona promašuje glavnu tačku. XML ili slični reprezentaciski formati možda nisu sintaksa sa kojom će programeri stvarno da rade. Jedna od prednosti korišćenja XML-baziranih oblasno-specifičnih jezika je da mi možemo da mi možemo da obezbedimo oblasno-specifične uređivače. Slika ispod pokazuje kako hipotetički uređivač za Entitet OSJ bi mogao da izgleda. Ovaj uređivač pokazuje oblast u u prostom i vizuelno privlačnom maniru ali kao da korsiti XML predstavljanje (a možda i konfiguracijski plan) ispod.

Kao što mi možemo da se žalimo da je XML loš izbor, možemo da prigovorimo da je i opšte-namenski jezik poput Jave loš izbor za neke zadatke. Štaviše, programeri mogu da se osećaju manje zastrašeni od strane uređivača u slici nego od spiska kodova u XML ili Javi. Ako prihvatimo da je sintaksa bitna onda korišćenje različitih jezika sa skrojenim uređivačima postaje razumna strategija. Jednostavnost ovog uređivača čini jezik lakšima za razumevanje i samim tim lakšim za korišćenje. Drugim rečima, prigovor sintaksa je bitna je možda pravi razlog zašto mi istražujemo polje oblasno-specifičnih jezika.

Drugo, jezičke interakcije otkrivaju odnose između jezika. Programeri treba da budu sposobni da skači između povezanih elemenata u različitim artefaktima. Lakoća navigacije između različitih softverskih artefakata je važan kriterijum za alate u tradicionalnim razvojnim okruženjima. Iako nismo izvodili empirijske studije u ovoj oblasti, pretpostavljamo da odgovarajuća navigacija podstiče povećanu produktivnost. Ovu tvrdnju podržava obzervacija da sva bina razvojan okruženja danas nude dosta sofisticirano navigaciono postrojenje kao što je tip hijerahiskog pregledača ili sposobnost da brzo locira i pređe sa reference na medotsku definiciju. Razvojan okruženja mogu da obezbede ove navigacione objekte zato što oni održavaju konstantno ažuriran model izvornih datoteka u formi apstraktnog sintaksnog drveta.

U razvojnom okruženju sa više jezika, navigacija je mnogo teža. Postojeća okruženja nisu spremljena za parsing i predtavljanje OSJ modela kao opstraktnih sintaskinh grana za proizvoljne a možda i aplikaciono-specifične jezike kao što su jezici  iz prethodnog primera. Dalje bez ovog unutrašnjeg zastupanja, postojeća okruženja ne mogu da reše ni unutar- ni među-jezičke reference za takve jezike i samim tim ne mogu da obezbede korisnu navigaciju. Ovo znači da porgrameri moraju da održavaju konceptualni model o tome kako su delovi njihovih sistema povezani. novi alati sa navigacionim objektima usmereni na više jezika će sa druge strane biti od velike pomoću u razumevanju odnosa između jezika. Usmislu kreiraj anketu primera takvi alati bi trebalo da pokazuju odnose između tri jeziak koristeći meke reference kao navigacijske tačke.

Treće, da bi razumeli jezičku korisnost moramo da budemo sposobni da uočimo razliku između ispravnih operacija uređivanja i pogrešnih operacija uređivanja u našem razvojnom okruženju. tradicionalna razvojna okruženja imaju duge obezbeđene smernice tokom pisanja programa. Postepena kompilacija dozvoljava okruženjima da nude detaljisane sugestije programeru kao što je kako da popune izjavu . Više nametljive vrste smernica takođe postoje, na primer, sintaksno-orijentisani uređivači gde samo ulaz u skladu sa gramatikom može biti unesen. Generični tekstualni uređivači koji mogu biti parametrizovani sa gramatikom jezika postoje već duže vreme.

Postojeći uređivači ne uzimaju svoju unutrašnje-jezičke konstantne odnose u obzir kada daju smernice. U prethodnom primeru, idealni uređivač bi trebalo, na primer, da bude u stanju da sugeriše kreirajAnketu servis kao validnu vrednost kada programer uređuje ciljne atribute u Formi definiciji. Okruženje koje bi moglo da razume o atrefaktima različitih jezika bi moglo takođe da pomogne programeru da identifikuje programska stanja gde je postojala lokalna ali ne i globalna konstantnost. Takva situacija može da naiđe kada je model dobro formiran i samim tim lokalno konstantan ali u isto vreme krši unutrašnja jezička ograničenja. Smernice ili inteligentna pomoć  u formi predloga kako da se kompletira model bile bi korisne za uređenja sa više jezika i kompleksnim ograničenjima doslednosti. Alatno-predložene uređivačke operacije bi mogle da naprave za programere lakši start procesa učenja kako da koriste jezike.

Koordinacija kao tehnički izazov

Tehnički aspekt koordinacijskog problema je u suštini pitanje sprovođenja doslednosti. Kako mozemo da pronađemo nedoslednosti preko modela iz više jezika u modelarsko vreme? Da bi potpuno razumeli kompleksnost zahteva doslednosti sistema bazirani na više jezika, korisno je da preradimo naš koncept doslednosti.

Doslednost može biti li unutrašnja ili među-doslednost. Unutrašnja-doslednost se bavi doslednošću elemenata jednom modelu. Zahtevi ovde su da model mora da se prilagodi svom metamodelu, t.j., da bude sintetički dobro formiran. U smislu kreiraj anketu primera, entitet model mora da se, na primer, prilagodi HSD šemi za Entitet OSJ. Ova šema je metamodel Entiteta OSJ i ona obrazlaže kako elementi mogu biti sastavljeni i šta su, do neke mere, valjane oblasti atributa.

Među-doslednost je postignuta kada reference među jezičkim granicama mogu biti rešene. Ovaj tip doslednosti se može dalje podeliti na (1) model-do-modela doslednost and (2) model-do-koda doslednost. Model-do-modela doslednost se odnosi na referencijalni integritet kao i ograničenja na visokom nivou sistema. U kreiraj anketu primeru, početno-entitetsko-ime atributa iz servisnog listinga se odnosi naimenski atribut iz Entitet spiska. Ako promenimo jednu od ovih vrednosti bez ažuriranja druge, prekidamo referencu. Više ograničenja doslednosti visokog nivoa preko različitih modela takođe postoje i o njima kasnije. Projekat može da iam određene obrasce ili konvencije za imenovanje i povezivanje modela elemenata. Sadašnja razvojna okruženja moraju biti skrojena specifičnim jezicima sa ručno pisanim dodacima ili sličnim mehanizmima u cilju sprovođenja doslednosti među jezicima kao što su oni iz prethodnog primera.

Model-do-koda doslednost je suštinski uslov u više-stepenom prilagođavanju. Kada su modeli dopunjeni sa frakcijama koda kao u napravi PDF primeru, neophodno je proveriti da modeli i kod stvarno pristaju. Ovo je delimično pitanje sigurnosti da se meke reference između modela i koda neće prekinuti, slično referentnom integritetu u model-domedela doslednosti. Ali je takođe pitanje sigurnosti da kod ne krši očekivanja postavljena u modelu. U Napravi PDF primeru, model precizira da outByteWrapper će uvek biti deo izalaza, t.j., outByteWrapper ključ je stavljen na mapi rezultata. Analiza koda pokazuje da će outByteWrapper samo biti deo izlaza ako nema izuzetaka pre linije 10. Drugim rečima, neke moguće egzekucije će da prekrše specifikaciju na modelarskom nivou. Više generalno, možemo da konstatuejmo da više-stepeno prilagođavanje nameće veoma fine strukture ograničenja na uključenim modelima i fragmentima koda.

Rešavanje problema koordinacije

Koordinaciski problem se javlja iz činjenice da se više jezika koristi u jednom sistemu. Dve prethodne podsekcije su ilustrovale da ovaj problem ima i konceptualnu stranu i tehničku stranu niskog nivoa. Izazove, koje imamo opisane, su stvarni a ne hipotetički izazovi. Konkrektno, suočavali smo se sa ovim izazovima u dve konkretne i reprezentativne studije slučaja: preduzetni sistem planiranja resursa, OFBiz, i sistem zaštite zdravlja, okružni zdravstveni informacioni sistem (OZIS). Oba slučaja su sistemi srednje veličine koja su u stvarnoj industrijskoj primeni. Naše rešenje praktičnih problem sa kojima smo se susretali tokom našeg rada sa ovim sistemima su skupovi smernica i prototipova. U sledećem tekstu, mi ćemo uvesti opšti konceptualni okvir koji uključuje smernice i prototipove u koherentnu metodu: koordinacisku metodu.

Koordinacijska metoda

Cilj koordinaciske metode je da reši koordinaciski problem i samism tim obezbedi bolju podršku za razvoj sa više jezika. Da bi pravilno cenili ovaj metod, bitno je da se razume da on ne propisuje dizajn individualnih jezika. Dosta metoda i alata su već predloženi za ovo. Ova metoda pretpostavlja postojanje uređenja sa više oblasno-specifičnih jezika. Dajući svakom uređenje, može se primeniti metod. Metoda se satoji iz tri koraka pokazana u diagramu ispod. Svaki korak se sastoji od nekoliko delova koji su prikazani kao male kutije u diagramu. Kutije sa isprekidanim linijama pokazuju automatske procese a kutiej sa punim linijama pokazuju manualne. U sledećem tekstu, objasnićemo ove korake u malo više detalja.

Korak 1: identifikacija

Cilj identifikacionog koraka je da identifikuje jezičke preklope. Kao što je opisano u priemru, preklop je polje gde se interesi dva jezika ukrštaju. Meka referenca iz Forme OSJ u Servis OSJ i iz Servis OSJ u Entitet OSJ kod kreiraj anketu slučaju upotrebe su primeri ovakvih preklapanja. Još jedan primer je slučaj gde se prilagođeni fragmenti koda koriste za proširenje modela. Ovakva prekalpanja su česta kada je ekspresivnost jezika opšte-namene potrebna za implementaciju specializovanih zahteva koji su izvan okvira modela. Identifikaciski korak mmože biti ili manuelni ili automatski proces u zavisnosti od složenosti preklapanja. Kada su preklapanja pronađena i načinjena eksplicitnim, ova inforamcija se koristi kao ulaz za drugi korak u metodi: Specifikaciski korak.

Korak 2: specifikacija

Cilj koraka specifikacije je da kreira koordinaciski model koji određuje kako jezici međusobno deluju. Reference preko jezičkih granica u sistemu predstvaljaju metod koordinacije za taj određeni sistem. On je stvoren mapiranjem glavnih softverskih artefakata u zajedničku reprezentaciju. Dodatne inforamcije kao što su oblasna- ili aplikaciono-specifična  ograničenja mogu takođe biti šifrovana da obezbede bogat prikaz. Koordinaciski model je baziran na generičkim informacijama kao što je jezička gramatika i ograničenja kao i aplikaciono specifične inforamcije kao što su konkrektni modeli i aplikaciono-specifična ograničenja. Ovo znači da iako su isti jezici korišćeni preko više proizvoda, svaki proizvod ima specifikaciju svog posebnog koordinacijskog modela. Koordinacijski model je korišćen kao baza za različite forme rezonovalja u finalnom koraku metode: aplikacijskom koraku.

Korak 3: aplikacija

Cilj aplikacijskog koraka je da iskoristi koodrinaciski model. koordinaciski model dozvoljava alatima izvedu tri sloja korisnih informacija. Prvo, koordinaciski model moze biti korišćen da sprovede konziszenznost preko više jezika. Koordinacijski model precizira relacije doslednosti kao kada elementi iz različitih jezika mogu da se odnose jedni na druge. Alati mogu da primene referencijalni integritet i da izvode statčke provere finalnog sistema pre raspoređivanja. Drugo, veze doslednosti se koriste za navigaciju, vizuelizaciju i mapiranje mreže različitih jezika u razvojno uređenju. Ova informacija se koristi da se brzo povežu i odnose elementi iz različitih jezika i da se obezbedi sledljivost među različitim modelima. Treće, na osnovu doslednosti odnosa i navigacione inforamcije o tome kako su elementi povezani, alati mogu da obezbede smernice, posebno završetak ili pomoć. Modelni završetak moze na primer biti obezbeđen u generičnom maniru preko oblasno-specifičnih alata.

Procena koordinacijske metode

Koordinacijska metoda se može najbolje videti kao konceptualni okvir koji propisuje određen proces rada kada se radi sa više jezika. Uva tri uzastopna koraka kaj čine ovaj proces rada nisu podržana od strane integrisane radne tezge ili razvojnog okruženja. Fokus je pre na produživanje programerovih postojećih okruženja da bi podržavali (1) identifikaciju, (2) specifikaciju, i (3) aplikaciju. Glavna prednost ovog pristupa bila je da su programeri stvarno testirali naš rad i dali nam povratne inforamcije. Ovakav način procene metode je vredan zato što smanjuje rizik rešavanja čisto hipotetičkog problema. Nekoliko radova uvodi različite korake koordinacijske metode, izveštava o ovoj proceni, i elaborira o tehničkim aspektima svakog individualnog eksperimenta. Generalno, rezultati su bili obećavajući: značajan broj grešaka je bio pronađen u produkcijskim sistemima i dat je povod za konstruktivni dialog sa programerima o budućim alatnim zahtevima. Proces razvoja baziran na ovim smernicama i podržan od strane alata predstavlja ozbiljan pokušaj da se reši koordinacijski problem i da oblasno-specifično multimodelovanje bude praktičan predlog.

Vidi još

• Oblasno-specifično modelovanje
• Oblasno-specifičan jezik
• Modelom-vođen inženjering