Domänspecifik multimodellering

Domänspecifik multimodellering är ett programvaruutvecklingsparadigm där varje vy görs explicit som ett separat domänspecifikt språk ( DSL).

Framgångsrik utveckling av ett modernt företagssystem kräver konvergens av flera åsikter. Affärsanalytiker, domänexperter, interaktionsdesigners, databasexperter och utvecklare med olika slags expertis deltar alla i processen att bygga ett sådant system. Deras olika arbetsprodukter måste hanteras, anpassas och integreras för att skapa ett körande system. Varje deltagare i utvecklingsprocessen har ett speciellt språk som är anpassat för att lösa problem som är specifika för deras syn på systemet. Utmaningen med att integrera dessa olika åsikter och undvika den potentiella kakofonien av flera olika språk är samordningsproblemet .

Domänspecifik multimodellering är lovande jämfört med mer traditionella utvecklingsparadigm som enspråkig programmering och generell modellering . För att skörda frukterna av detta nya paradigm måste vi lösa samordningsproblemet. Detta problem är också känt som fragmenteringsproblemet i samband med Global Model Management .

Ett förslag för att lösa detta problem är samordningsmetoden . Detta är en trestegsmetod för att övervinna hindren för att integrera olika vyer och samordna flera språk. Metoden föreskriver hur man (1) identifierar och (2) specificerar referenserna över språkgränserna, det vill säga överlappningarna mellan olika språk. Slutligen ger metoden konkreta förslag på hur man (3) kan tillämpa denna kunskap i faktisk utveckling i form av konsekvens, navigering och vägledning.

Motiverande exempel

Det finns gott om företagssystem baserade på flera domänspecifika språk . Språk med en metamodell definierad i Extensible Markup Language (XML) har en särskilt utbredd användning. För att illustrera utveckling med flera språk kommer vi att dra ett exempel från en fallstudie: Apache Open For Business (OFBiz) -systemet. Kort sagt, OFBiz är ett företagsresursplaneringssystem som inkluderar standardkomponenter som inventering, redovisning, e-handel etc. Dessa komponenter implementeras av en blandning av XML-baserade språk och vanlig Java-kod. Låt oss som ett exempel fokusera på innehållshanteringskomponenten , särskilt ett användningsfall där den administrativa användaren skapar en webbenkät online som visas i skärmdumpen nedan. Vi kommer att hänvisa till detta exempel som skapa enkätexemplet .

Bilden visar en skärmdump av det administrativa gränssnittet för innehållshanteringsapplikationen i en körande OFBiz- instans. För att skapa en enkät fyller användaren i fälten i inmatningsformuläret och trycker på uppdateringsknappen . Detta skapar en ny undersökning som kan redigeras och senare publiceras på en frontend-webbplats i OFBiz . Bakom kulisserna involverar detta användningsfall flera artefakter skrivna på olika språk. Låt oss i det här exemplet bara fokusera på tre av dessa språk: Entiteten, Tjänsten och Form DSL.

Dessa tre språk motsvarar ungefär det strukturella, beteendemässiga och användargränssnittsproblemet i OFBiz . Entity DSL används för att beskriva den underliggande datamodellen och därmed hur den skapade undersökningen kommer att sparas. Tjänsten DSL används för att beskriva gränssnittet för tjänsten som anropas när användaren trycker på uppdateringsknappen . Slutligen används Form DSL för att beskriva formulärets visuella utseende. Även om de tre språken är skräddarsydda för olika saker, kan de inte separeras helt. Användargränssnittet anropar en viss applikationslogik och denna applikationslogik manipulerar applikationens data. Detta är ett exempel på icke-ortogonala problem . Språken överlappar varandra eftersom de problem som de representerar inte kan separeras helt. Låt oss undersöka dessa tre språk nerifrån och upp och peka på deras överlappningar.

Entity DSL

Entity DSL definierar strukturen för data i OFBiz . Listan nedan visar definitionen av undersökningsenheten som är det affärsobjekt som representerar begreppet en undersökning. Koden i listan är självförklarande: En enhet som heter Survey definieras med 10 fält. Varje fält har ett namn och en typ. Fältet surveyId används som primärnyckel . Denna definition laddas av en central komponent i OFBiz som kallas entitetsmotorn . Entitetsmotorn instansierar ett motsvarande affärsobjekt . Syftet med entitetsmotorn är att hantera transaktionsegenskaper för alla affärsobjekt och interagera med olika beständighetsmekanismer som Java Database Connectivity, Enterprise JavaBeans eller till och med något äldre system .

     
      
      
      
      
      
      
       
       
       
       
     
   <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=  "indikator"  ...  />  <field  name=  "acroFormContentId"  type=  "id-ne"  ...  />  <prim-key  field=  "surveyId"  />  </entity> 

Service DSL

Tjänsten DSL anger gränssnittet för tjänsterna i OFBiz . Varje tjänst kapslar in en del av systemets applikationslogik. Syftet med detta språk är att ha en enhetlig abstraktion över olika implementeringsmekanismer. Enskilda tjänster kan implementeras i Java, ett skriptspråk eller med hjälp av en regelmotor . Listan nedan visar gränssnittet för createSurvey-tjänsten.

Förutom namnet specificerar serviceelementet placeringen och anropskommandot för implementeringen för denna tjänst. Attributet default-entity-name anger att den här tjänsten hänvisar till Survey-entiteten som definierades i föregående lista. Detta är en överlappning mellan de två språken, närmare bestämt en så kallad mjuk referens . En modell i Service DSL hänvisar till en modell i Entity DSL. Denna referens används i de två autoattributelementen nedan som anger ingången och utmatningen av tjänsten i form av typade attribut. Som indata accepterar tjänsten attribut som motsvarar alla icke-primära nyckel (nonpk)-fält i Survey-entiteten och dessa attribut är valfria. Som utdata returnerar tjänsten attribut som motsvarar primärnyckelfälten (pk) i Survey, dvs i detta fall surveyId-fältet, och dessa attribut är obligatoriska. Syftet med referensen över språk är i detta fall att minska redundans. Attributen för createSurvey-tjänsten motsvarar fälten för Survey-enheten och det är därför bara nödvändigt att ange dem en gång.

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

Form DSL

Form DSL används för att beskriva layouten och det visuella utseendet på inmatningsformulär i användargränssnittet. Språket består av domänbegrepp som Form och Field. Listan nedan visar implementeringen av EditSurvey-formuläret. Den här gången överlappar Form DSL med Service DSL. Formulärets målattribut och alt-target-elementen anger att input från inlämningen av detta formulär ska riktas till antingen updateSurvey- eller createSurvey-tjänsterna. Auto-fields-service-elementet anger att formuläret ska innehålla ett fält som motsvarar vart och ett av attributen för updateSurvey-tjänsten (som liknar attributen för createSurvey-tjänsten). Detta ger en liknande effekt av att importera definitioner från en annan modell som i fallet med autoattributelementen i föregående lista. Längre ner kan vi se att det är möjligt att anpassa utseendet på dessa importerade fält som isAnonymous. Slutligen läggs en submitButton till med en lokaliserad titel så att användaren kan skicka sina data till den refererade tjänsten.

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

Skapa enkätexemplet , som beskrivs här, implementeras med hjälp av modeller på tre olika språk. Den fullständiga implementeringen involverar faktiskt ännu fler språk som en Screen DSL för att specificera layouten på skärmen där formuläret placeras, och en Minilang DSL som är ett datamanipuleringsspråk som används för att implementera tjänsten. Dessa tre språk illustrerar dock huvudtanken med att göra varje angelägenhet konkret. Exemplet visar också ett enkelt sätt att minska redundans genom att låta språken överlappa varandra något.

Anpassning på flera nivåer

Domänspecifika språk , som de som beskrivs ovan, har begränsad uttrycksförmåga. Det är ofta nödvändigt att lägga till kodavsnitt i ett allmänt språk som Java för att implementera specialiserad funktionalitet som ligger utanför språkens omfattning. Denna metod kallas anpassning på flera nivåer . Eftersom denna metod är mycket vanligt förekommande i inställningar med flera språk, kommer vi att illustrera den med en fortsättning på exemplet. Låt oss kalla detta bygg-PDF- exemplet.

Anta att vi vill bygga en PDF-fil för varje enkätsvar på de online-undersökningar som användarna skapar. Att bygga en PDF-fil ligger utanför omfattningen av våra språk så vi måste skriva lite Java-kod som kan anropa ett tredjeparts PDF-bibliotek för att utföra denna specialiserade funktionalitet. Två artefakter krävs:

Först, en ytterligare tjänstemodell, som visas nedan, i Service DSL som definierar gränssnittet för den konkreta tjänsten så att den kan nås på modelleringsnivån. Tjänstemodellen beskriver platsen för implementeringen och vad input- och outputattributen är.

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

För det andra behöver vi ett kodavsnitt, som visas nedan, som innehåller den faktiska implementeringen av denna tjänst. En tjänst kan ha flera ingångar och utgångar så indata till Java-metoden är en karta, kallad kontext, från argumentnamn till argumentvärden och returnerar utdata i form av en annan karta, kallad resultat.

     
       
        
        
     
      
      
      
       
     
        
     
   public  static  Map  buildPdfFromSurveyResponse  (  DispatchContext  dctx  ,  Map  context  )  {  String  id  =  (  String  )  context  .  get  (  "surveyResponseId"  );  Kartresultat  =  ny  HashMap  (  );  prova  {  // ...svaret hämtas från databasen...  // ...en pdf byggs från svaret...  // ...pdf:n serialiseras som en bytearray...  ByteWrapper  outByteWrapper  =  ...;  resultat  .  put  (  "outByteWrapper"  ,  outByteWrapper  );  }  catch  (  Undantag  e  )  {}  returnerar  resultat  ;  } 

Denna anpassningsmetod på flera nivåer använder mjuka referenser som liknar skapa enkätexemplet . Den största skillnaden är att referensen här är mellan modell och kod snarare än mellan modell och modell. Fördelen i det här fallet är att ett Java-bibliotek från tredje part för att bygga PDF-filer kan utnyttjas. En annan typisk applikation är att använda Java-kodsnuttar för att anropa externa webbtjänster och importera resultat i lämpligt format.

Koordinationsproblem

Exemplet illustrerar några av fördelarna med att använda flera språk i utvecklingen. Det finns dock också svårigheter förknippade med denna typ av utveckling. Dessa svårigheter härrör från observationen att ju fler typer av artefakter vi introducerar i vår process, desto mer koordinering behövs mellan utvecklarnas insatser. Vi kommer att kalla dessa svårigheter som samordningsproblemet . Samordningsproblemet har en konceptuell och en teknisk aspekt. Konceptuellt är huvudproblemet att förstå de olika språken och deras interaktion. För att designa och samordna modeller på flera språk på rätt sätt måste utvecklare ha en tillräcklig förståelse för hur språk interagerar. Tekniskt sett är huvudproblemet att upprätthålla konsekvens. Verktyg måste tillhandahållas för att upptäcka inkonsekvenser tidigt, dvs vid modelleringstid, och hjälpa utvecklare att lösa dessa inkonsekvenser. I det följande kommer vi att undersöka dessa två aspekter mer i detalj.

Samordning som en konceptuell utmaning

Det första problemet som utvecklare stöter på när de börjar utveckla med flera språk är språkkakofoni . Att lära sig de olika språken och förstå deras interaktion är nödvändigt för att förstå den komplexa sammansättningen av artefakter. Ramverket OFBiz har till exempel sjutton olika språk och mer än 200 000 rader domänspecifik språkkod så komplexiteten kan vara ganska överväldigande! Det finns för närvarande ingen etablerad metod för att karakterisera olika språk så att utvecklare snabbt kan nå en operativ förståelse. Verktyg är viktiga här som en ad hoc- mekanism för lärande och utforskning eftersom utvecklare vanligtvis använder verktyg för att lära sig genom experiment. Det finns särskilt tre områden där verktyg för domänspecifika modeller är användbara:

1. Att förstå ett språk
2. Förstå språkinteraktioner
3. Förstå hur man använder språk

För det första kan det vara svårt att förstå ett språk och i fallet med XML-baserade domänspecifika språk är en ofta förekommande och intuitiv invändning syntaxfrågan . Detta argument kan uttryckas på följande sätt: ”De olika språken är svåra att förstå och ökar bara förvirringen eftersom deras XML-baserade syntax är särskilt mångsidig och oförståelig. Att använda ett enda allmänt språk som Java skulle vara bättre eftersom utvecklare då kunde lita på en syntax som de redan känner till”. Även om denna invändning verkligen är viktig, missar den en central punkt. XML eller liknande representationsformat kanske inte är den syntax som utvecklare faktiskt arbetar med. En av fördelarna med att använda XML-baserade domänspecifika språk är att vi då kan tillhandahålla domänspecifika editorer. Bilden nedan visar hur en hypotetisk editor för Entity DSL kan se ut. Den här redigeraren presenterar domänen på ett enkelt och visuellt tilltalande sätt men kan mycket väl använda XML-representationen (och kanske en layoutkonfiguration) under.

Precis som vi kan klaga på att XML är ett dåligt val, kan vi också invända att ett allmänt språk som Java är ett dåligt val för vissa uppgifter. Dessutom kan utvecklare känna sig mindre skrämda av redaktören i figur än av kodlistor i XML eller Java. Om vi ​​accepterar att syntax spelar någon roll så blir användningen av olika språk med skräddarsydda editorer en rimlig strategi. Redaktörens enkelhet gör språket lättare att förstå och därmed lättare att använda. Med andra ord syntaxfrågan invändningen vara själva anledningen till att vi utforskar området för domänspecifika språk .

För det andra avslöjar språkinteraktioner relationer mellan språk. Utvecklare bör kunna hoppa mellan relaterade element i olika artefakter. Enkel navigering mellan olika programvaruartefakter är ett viktigt kriterium för verktyg i traditionella utvecklingsmiljöer. Även om vi inte har utfört några empiriska studier på detta område, antar vi att korrekta navigationsanläggningar ökar produktiviteten. Detta påstående stöds av observationen att alla större utvecklingsmiljöer idag erbjuder ganska sofistikerade navigeringsfaciliteter som typhierarki-webbläsare eller möjligheten att snabbt hitta och hoppa till referenser till en metoddefinition. Utvecklingsmiljöerna kan tillhandahålla dessa navigeringsmöjligheter eftersom de upprätthåller en kontinuerligt uppdaterad modell av källfilerna i form av ett abstrakt syntaxträd .

I en utvecklingsmiljö med flera språk är navigering mycket svårare. Befintliga miljöer är inte inriktade på att analysera och representera DSL-modeller som abstrakta syntaxträd för godtyckliga och kanske till och med applikationsspecifika språk som språken från föregående exempel. Utan denna interna representation kan existerande miljöer inte lösa varken intra- eller mellanspråksreferenser för sådana språk och kan därför inte ge användbar navigering. Detta innebär att utvecklare måste upprätthålla en konceptuell modell av hur delarna av deras system hänger ihop. Nya verktyg med navigeringsmöjligheter anpassade till flera språk skulle å andra sidan vara till stor hjälp för att förstå relationerna mellan språk. När det gäller skapa enkätexemplet bör sådana verktyg visa relationerna mellan de tre språken genom att använda mjuka referenser som navigeringspunkter.

För det tredje, för att förstå språkanvändning måste vi kunna skilja korrekta redigeringsoperationer från fel i vår utvecklingsmiljö. Traditionella utvecklingsmiljöer har länge gett vägledning under skrivandet av ett program. Inkrementell kompilering gör att miljön kan erbjuda detaljerade förslag till utvecklaren, till exempel hur man slutför ett uttalande. Mer påträngande typer av vägledning finns också såsom syntax-orienterade editorer där endast indata som överensstämmer med grammatiken kan matas in. Generiska textredigerare som kan parametriseras med ett språks grammatik har funnits länge.

Befintliga redaktörer tar inte hänsyn till konsistensrelationer mellan språk när de ger vägledning. I det föregående exemplet bör en idealredigerare till exempel kunna föreslå createSurvey-tjänsten som ett giltigt värde när utvecklaren redigerar target-attributet i Form-definitionen. En miljö som kan resonera om artefakter från olika språk skulle också kunna hjälpa utvecklaren att identifiera programtillstånd där det finns lokal men inte global konsistens. En sådan situation kan uppstå när en modell är välformad och därmed lokalt konsistent men samtidigt bryter mot en mellanspråklig begränsning. Vägledning eller intelligent hjälp i form av förslag på hur man färdigställer en modell skulle vara användbar för inställningar med flera språk och komplexa konsekvensbegränsningar. Verktygsföreslagna redigeringsoperationer kan göra det lättare för utvecklaren att komma igång med processen att lära sig hur man använder språken.

Samordning som en teknisk utmaning

Den tekniska aspekten av samordningsproblemet handlar i huvudsak om att upprätthålla konsekvens. Hur kan vi upptäcka inkonsekvenser mellan modeller från flera språk vid modelleringstidpunkten? För att till fullo förstå komplexiteten i konsistenskraven för ett system baserat på flera språk, är det användbart att förfina vårt koncept för konsekvens.

Konsistens kan vara antingen intra- eller interkonsistens. Intrakonsistens avser konsistensen av element inom en enda modell. Kraven här är att modellen måste överensstämma med sin metamodell, dvs vara syntaktisk välformad. När det gäller skapa enkätexemplet måste entitetsmodellen till exempel överensstämma med XSD-schemat för Entity DSL. Detta schema är metamodellen för Entity DSL och det specificerar hur element kan sammansättas och vad som i viss utsträckning är giltiga domäner av attribut.

Interkonsistens uppnås när referenser över språkgränserna kan lösas. Denna typ av konsistens kan ytterligare delas in i (1) modell-till-modell-konsistens och (2) modell-till-kod-konsistens. Konsistens mellan modell och modell gäller systemets referensintegritet såväl som begränsningar på hög nivå. I skapa enkätexemplet hänvisar standard-entity-name-attributet från tjänstelistan till namnattributet från enhetslistan. Om vi ​​ändrar ett av dessa värden utan att uppdatera det andra bryter vi referensen. Mer konsistensbegränsningar på hög nivå över olika modeller finns också som diskuteras senare. Ett projekt kan ha vissa mönster eller konventioner för att namnge och relatera modellelement. Aktuella utvecklingsmiljöer måste skräddarsys för specifika språk med handskrivna plugins eller liknande mekanismer för att upprätthålla överensstämmelse mellan språk som de från föregående exempel.

Konsistens mellan modell och kod är ett väsentligt krav vid anpassning på flera nivåer. När modeller kompletteras med kodsnuttar som i build PDF- exemplet är det nödvändigt att kontrollera att modeller och kod faktiskt passar . Detta är delvis en fråga om att se till att mjuka referenser mellan modeller och kod inte bryts, liknande referensintegritet i modell-till-modell konsistens. Men det handlar också om att se till att koden inte bryter mot förväntningar som ställs upp i modellen. I build PDF- exemplet specificerar modellen att outByteWrapper alltid kommer att vara en del av utdata, dvs. outByteWrapper-nyckeln placeras i resultatkartan. En analys av koden visar att outByteWrapper endast kommer att vara en del av utdata om inga undantag kastas före rad 10. Med andra ord kommer vissa möjliga exekveringar av koden att bryta mot en specifikation på modelleringsnivån. Mer generellt kan vi konstatera att anpassning på flera nivåer lägger mycket finkorniga begränsningar på de inblandade modellerna och kodavsnitten.

Att lösa koordinationsproblemet

Samordningsproblemet uppstår från det faktum att flera språk används i ett enda system. De två föregående underavsnitten illustrerar att detta problem har både en konceptuell sida och en teknisk sida på låg nivå. De utmaningar som vi har beskrivit är verkliga snarare än hypotetiska utmaningar. Specifikt har vi ställts inför dessa utmaningar i två konkreta och representativa fallstudier: ett företagsresursplaneringssystem, OFBiz , och ett hälsovårdssystem , District Health Information System ( DHIS ). Båda fallen är medelstora system som är i faktisk industriell användning. Vår lösning på de praktiska problem vi har stött på under vårt arbete med dessa system är en uppsättning riktlinjer och prototyper. I det följande kommer vi att introducera ett övergripande konceptuellt ramverk som införlivar riktlinjerna och prototyperna i en sammanhängande metod: samordningsmetoden .

Samordningsmetod

Målet med samordningsmetoden är att lösa samordningsproblemet och därigenom ge bättre stöd för utveckling med flera språk. För att korrekt uppskatta metoden är det viktigt att förstå att den inte föreskriver utformningen av enskilda språk. Många metoder och verktyg har redan föreslagits för detta. Denna metod förutsätter att det finns en installation med flera domänspecifika språk. Givet en sådan uppställning kan man tillämpa metoden. Metoden består av tre steg som visas i diagrammet nedan. Varje steg består av ett par delar som visas som små rutor i diagrammet. Rutor med streckade linjer representerar automatiska processer och rutor med heldragna linjer representerar manuella. I det följande kommer vi att förklara dessa steg lite mer detaljerat.

Steg 1: identifiering

Målet med identifieringssteget är att identifiera språköverlappningar. Som beskrivs i exemplet är en överlappning ett område där frågorna för två språk skär varandra. De mjuka referenserna från Form DSL till Service DSL och från Service DSL till Entity DSL i användningsfallet för skapa enkät är exempel på sådana överlappningar. Ett annat exempel är fallet där ett anpassat kodavsnitt används för att utöka en modell. Sådana överlappningar är frekventa när uttrycksförmågan hos allmänspråkiga språk behövs för att implementera specialiserade krav som ligger utanför modellens räckvidd. Identifieringssteget kan antingen vara en manuell eller en automatisk process beroende på komplexiteten i överlappningarna. När överlappningarna har identifierats och gjorts explicita används denna information som input till det andra steget i metoden: specifikationssteget.

Steg 2: specifikation

Målet med specifikationssteget är att skapa en samordningsmodell som specificerar hur språk interagerar. Referenserna över språkgränserna i ett system utgör samordningsmodellen för just det systemet. Den skapas genom att mappa de huvudsakliga programvaruartefakterna till en gemensam representation. Ytterligare information som domän- eller applikationsspecifika begränsningar kan också kodas för att ge en rik representation. Samordningsmodellen är baserad på generisk information såsom språkgrammatik och begränsningar samt applikationsspecifik information såsom konkreta modeller och applikationsspecifika begränsningar. Detta innebär att även om samma språk används över flera produkter, har varje produkt en specifikation av sin egen unika koordinationsmodell. Samordningsmodellen används som underlag för olika former av resonemang i metodens sista steg: tillämpningssteget.

Steg 3: ansökan

Målet med ansökningssteget är att dra nytta av samordningsmodellen. Samordningsmodellen tillåter verktyg att härleda tre lager av användbar information. För det första kan samordningsmodellen användas för att upprätthålla konsekvens över flera språk. Samordningsmodellen specificerar konsistensrelationer såsom hur element från olika språk kan referera till varandra. Verktyg kan upprätthålla referensintegritet och utföra statiska kontroller av det slutliga systemet före implementering. För det andra används konsistensrelationerna för att navigera, visualisera och kartlägga webben av olika språk i en utvecklingsuppsättning. Denna information används för att snabbt länka och relatera element från olika språk och för att ge spårbarhet mellan olika modeller. För det tredje, baserat på konsistensrelationer och navigeringsinformation om hur element är relaterade, kan verktyg ge vägledning, specifikt komplettering eller assistans. Modellkomplettering kan till exempel tillhandahållas på ett generiskt sätt över domänspecifika verktyg.

Utvärdering av samordningsmetoden

Samordningsmetoden kan bäst ses som ett konceptuellt ramverk som föreskriver ett visst arbetsflöde när man arbetar med flera språk. De tre på varandra följande stegen som utgör detta arbetsflöde stöds inte av en integrerad arbetsbänk eller utvecklingsmiljö. Fokus ligger snarare på att utöka utvecklarens befintliga miljöer för att lägga till stöd för (1) identifiering, (2) specifikation och (3) applikation. Den största fördelen med detta tillvägagångssätt har varit att utvecklare faktiskt har testat vårt arbete och gett oss feedback. Denna typ av utvärdering av metoden är värdefull eftersom den minskar risken för att lösa ett rent hypotetiskt problem. Flera artiklar introducerar de olika stegen i koordinationsmetoden, rapporterar om denna utvärdering och utvecklar de tekniska aspekterna av varje enskilt experiment. Sammantaget har resultaten varit lovande: ett betydande antal fel har hittats i produktionssystemen och gett upphov till en konstruktiv dialog med utvecklare om framtida verktygskrav. En utvecklingsprocess baserad på dessa riktlinjer och stödd av verktyg utgör ett seriöst försök att lösa samordningsproblemet och göra domänspecifik multimodellering till ett praktiskt förslag.

Se även

• Domänspecifikt språk
• Domänspecifik modellering
• Modelldriven teknik