Multimodelowanie specyficzne dla domeny

Multimodeling specyficzny dla domeny to paradygmat tworzenia oprogramowania, w którym każdy widok jest wyraźnie określony jako oddzielny język specyficzny dla domeny (DSL).

Pomyślny rozwój nowoczesnego systemu korporacyjnego wymaga zbieżności wielu perspektyw. W procesie budowy takiego systemu biorą udział analitycy biznesowi, eksperci dziedzinowi, projektanci interakcji, eksperci od baz danych i programiści o różnych specjalizacjach. Ich różne produkty pracy muszą być zarządzane, dostosowywane i integrowane, aby stworzyć działający system. Każdy uczestnik procesu rozwoju ma określony język dostosowany do rozwiązywania problemów specyficznych dla jego spojrzenia na system. Wyzwaniem związanym z integracją tych różnych poglądów i uniknięciem potencjalnej kakofonii wielu różnych języków jest problem z koordynacją .

Wielomodelowanie specyficzne dla domeny jest obiecujące w porównaniu z bardziej tradycyjnymi paradygmatami programowania, takimi jak programowanie w jednym języku i modelowanie ogólnego przeznaczenia . Aby czerpać korzyści z tego nowego paradygmatu, musimy rozwiązać problem koordynacji. Ten problem jest również znany jako problem fragmentacji w kontekście globalnego zarządzania modelami .

Jedną z propozycji rozwiązania tego problemu jest metoda koordynacji . Jest to trzyetapowa metoda przezwyciężenia przeszkód związanych z integracją różnych poglądów i koordynacją wielu języków. Metoda opisuje, jak (1) zidentyfikować i (2) określić odniesienia ponad granicami językowymi, czyli nakładanie się różnych języków. Wreszcie, metoda oferuje konkretne propozycje, jak (3) zastosować tę wiedzę w rzeczywistym rozwoju w postaci spójności, nawigacji i wskazówek.

Motywujący przykład

Istnieje wiele systemów korporacyjnych opartych na wielu językach specyficznych dla domeny . Języki z metamodelem zdefiniowanym w Extensible Markup Language (XML) cieszą się szczególnie powszechnym przyjęciem. Aby zilustrować programowanie w wielu językach, zaczerpniemy przykład ze studium przypadku: Apache Open For Business (OFBiz) . Krótko mówiąc, OFBiz to system planowania zasobów przedsiębiorstwa , który zawiera standardowe komponenty, takie jak inwentaryzacja, księgowość, handel elektroniczny itp. Komponenty te są implementowane przez mieszankę języków opartych na XML i zwykłego kodu Java. Jako przykład skupmy się na do zarządzania treścią , w szczególności na przypadku użycia, w którym użytkownik administracyjny tworzy ankietę internetową online, jak pokazano na zrzucie ekranu poniżej. Ten przykład będziemy nazywać tworzenia ankiety .

Rysunek przedstawia zrzut ekranu interfejsu administracyjnego aplikacji do zarządzania treścią w działającej instancji OFBiz . Aby utworzyć ankietę, użytkownik wypełnia pola formularza wejściowego i naciska aktualizacji . Spowoduje to utworzenie nowej ankiety, którą można edytować, a następnie opublikować na stronie frontendowej w OFBiz . Za kulisami ten przypadek użycia obejmuje kilka artefaktów napisanych w różnych językach. W tym przykładzie skupmy się tylko na trzech z tych języków: Entity, Service i Form DSL.

Te trzy języki odpowiadają z grubsza problemom strukturalnym, behawioralnym i interfejsowi użytkownika w OFBiz . Entity DSL służy do opisywania podstawowego modelu danych, a tym samym sposobu, w jaki utworzona ankieta zostanie zapisana. Usługa DSL służy do opisania interfejsu usługi, która jest wywoływana, gdy użytkownik naciśnie aktualizacji . Wreszcie formularz DSL jest używany do opisywania wyglądu formularza. Chociaż te trzy języki są dostosowane do różnych rzeczy, nie można ich całkowicie oddzielić. Interfejs użytkownika wywołuje określoną logikę aplikacji, a ta logika aplikacji manipuluje danymi aplikacji. To jest przykład problemów nieortogonalnych . Języki nakładają się na siebie, ponieważ problemów, które reprezentują, nie można całkowicie rozdzielić. Przyjrzyjmy się tym trzem językom oddolnie i zwróćmy uwagę na ich nakładanie się.

DSL jednostki

Entity DSL definiuje strukturę danych w OFBiz . Poniższa lista zawiera definicję encji Ankieta, która jest obiektem biznesowym reprezentującym koncepcję ankiety. Kod na liście nie wymaga wyjaśnień: jednostka o nazwie Ankieta jest zdefiniowana za pomocą 10 pól. Każde pole ma nazwę i typ. Pole SurveyId jest używane jako klucz podstawowy . Ta definicja jest ładowana przez centralny komponent OFBiz zwany silnikiem encji . Mechanizm encji tworzy instancję odpowiedniego obiektu biznesowego . Celem silnika encji jest zarządzanie właściwościami transakcyjnymi wszystkich obiektów biznesowych i interakcja z różnymi mechanizmami trwałości, takimi jak Java Database Connectivity , Enterprise JavaBeans , a nawet niektóre starsze systemy .

     
      
      
      
      
      
      
       
       
       
       
     
   <  nazwa-obiektu=  "Ankieta"  ...  title=  "Jednostka ankiety"  >  <  nazwa pola=  "identyfikator-survey"  type=  "identyfikator-ne"  />  <  nazwa pola=  "nazwa-ankiety"  typ=  "nazwa"  />  <  nazwa  pola =   "opis"  typ =  "opis"  />  <  nazwa pola =  "komentarze"  typ =  "komentarz"  />  <nazwa  pola =  "submitCaption"  typ =  "short-varchar"  />  <nazwa  pola =  "responseService"  type=  "long-varchar"  />  <  nazwa pola =  "isAnonymous"  type=  "wskaźnik"  ...  />  <  nazwa pola =  "allowMultiple"  type =  "wskaźnik"  ...  />  <nazwa  pola =  "allowUpdate"  type=  "indicator"  ...  />  <field  name=  "acroFormContentId"  type=  "id-ne"  ...  />  <prim-key  field=  "surveyId"  />  </entity> 

Usługa DSL

Usługa DSL określa interfejs usług w OFBiz . Każda usługa hermetyzuje część logiki aplikacji systemu. Celem tego języka jest uzyskanie jednolitej abstrakcji dla różnych mechanizmów wykonawczych. Poszczególne usługi można zaimplementować w języku Java, języku skryptowym lub przy użyciu mechanizmu reguł . Poniższy listing przedstawia interfejs usługi createSurvey.

Element service oprócz nazwy określa lokalizację i polecenie wywołania implementacji tej usługi. Atrybut default-entity-name określa, że ​​ta usługa odnosi się do encji Survey, która została zdefiniowana w poprzednim wykazie. Jest to nakładanie się tych dwóch języków, a konkretnie tak zwane miękkie odniesienie . Model w Service DSL odnosi się do modelu w Entity DSL. To odwołanie jest używane w dwóch poniższych elementach autoatrybutów, które określają dane wejściowe i wyjściowe usługi w postaci wpisanych atrybutów. Jako dane wejściowe usługa akceptuje atrybuty odpowiadające wszystkim polom klucza innego niż klucz podstawowy (nonnpk) encji Ankieta, a atrybuty te są opcjonalne. Na wyjściu usługa zwraca atrybuty odpowiadające polom klucza podstawowego (pk) Ankiety, czyli w tym przypadku polu SurveyId, przy czym te atrybuty są obowiązkowe. Celem odniesienia między językami jest w tym przypadku ograniczenie redundancji. Atrybuty usługi createSurvey odpowiadają polom encji Ankieta i dlatego konieczne jest ich określenie tylko raz.

     
           
            
                        
       
       
   <service  name=  "createSurvey"  default-entity-name=  "Ankieta"  ...  location=  "org/ofbiz/content/survey/SurveyServices.xml"  invoke=  "createSurvey"  >  ...  <  nazwa-usługi- uprawnień  =   "contentManagerPermission"  main-action=  "CREATE"  />  <auto-atrybuty  obejmują=  "nonpk"  mode=  "IN"  opcjonalne=  "true"  />  <auto-atrybuty  obejmują=  "pk"  tryb=  "OUT"  opcjonalne=  "fałsz"  /> <  /usługa> 

Formularz DSL

Formularz DSL służy do opisywania układu i wyglądu formularzy wejściowych w interfejsie użytkownika. Język składa się z pojęć dziedzinowych, takich jak forma i pole. Poniższy listing przedstawia implementację formularza EditSurvey. Tym razem Form DSL pokrywa się z Service DSL. Atrybut target formularza i elementy alt-target określają, że dane wejściowe z przesłania tego formularza powinny być kierowane do usług updateSurvey lub createSurvey. Element auto-fields-service określa, że ​​formularz powinien zawierać pole odpowiadające każdemu z atrybutów usługi updateSurvey (które są podobne do atrybutów usługi createSurvey). Daje to podobny efekt importowania definicji z innego modelu, jak w przypadku elementów autoatrybutów w poprzednim zestawieniu. W dalszej części możemy zobaczyć, że można dostosować wygląd tych importowanych pól, takich jak isAnonymous. Na koniec dodawany jest przycisk przesyłania ze zlokalizowanym tytułem, dzięki któremu użytkownik może przesłać swoje dane do usługi, do której się odwołuje.

     
         
      
     
         
        
          
      
      
           
       
    
   <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>  </pole >  ...  <field  name=  "submitButton"  title=  "${uiLabelMap.CommonUpdate}"  widget-style=  "smallSubmit"  >  <submit  button-type=  "button"  />  </field>  </form> 

Opisany tutaj przykład tworzenia ankiety został zaimplementowany przy użyciu modeli w trzech różnych językach . Pełna implementacja obejmuje w rzeczywistości jeszcze więcej języków, takich jak Screen DSL do określania układu ekranu, na którym umieszczany jest formularz, oraz Minilang DSL, który jest językiem manipulacji danymi używanym do implementacji usługi. Jednak te trzy języki ilustrują główną ideę skonkretyzowania każdego problemu. Przykład pokazuje również prosty sposób zmniejszenia redundancji poprzez umożliwienie nieznacznego nakładania się języków.

Personalizacja na wielu poziomach

Języki specyficzne dla domeny , takie jak te opisane powyżej, mają ograniczoną ekspresyjność. Często konieczne jest dodanie fragmentów kodu w języku ogólnego przeznaczenia, takim jak Java, w celu zaimplementowania wyspecjalizowanej funkcjonalności wykraczającej poza zakres tych języków. Ta metoda nazywana jest dostosowywaniem wielopoziomowym . Ponieważ ta metoda jest bardzo często używana w konfiguracjach z wieloma językami, zilustrujemy ją kontynuacją przykładu. Nazwijmy to kompilacji PDF .

Załóżmy, że chcemy utworzyć plik PDF dla każdej odpowiedzi na ankiety online tworzone przez użytkowników. Budowanie pliku PDF wykracza poza zakres naszych języków, dlatego musimy napisać kod Java, który może wywołać bibliotekę PDF innej firmy w celu wykonania tej wyspecjalizowanej funkcji. Wymagane są dwa artefakty:

Po pierwsze, dodatkowy model usługi, jak pokazano poniżej, w usłudze DSL usługi, który definiuje interfejs konkretnej usługi w taki sposób, że można uzyskać do niej dostęp na poziomie modelowania. Model usługi opisuje lokalizację implementacji oraz jakie są atrybuty wejściowe i wyjściowe.

    
    
    
      
       
      
       
   <service  name=  "buildPdfFromSurveyResponse"  engine=  "java"  location=  "org.ofbiz.content.survey.PdfSurveyServices"  invoke=  "buildPdfFromSurveyResponse"  >  <atrybut  name=  "surveyResponseId"  mode=  "IN"  option=  "false"  .. .  />  <  nazwa atrybutu =  "outByteWrapper"  mode =  "OUT"  opcjonalnie =  "false"  ...  /> <  /usługa> 

Po drugie, potrzebujemy fragmentu kodu, jak pokazano poniżej, który zawiera rzeczywistą implementację tej usługi. Usługa może mieć wiele wejść i wyjść, więc wejście do metody Java jest mapą, zwaną kontekstem, od nazw argumentów do wartości argumentów i zwraca dane wyjściowe w postaci innej mapy, zwanej wynikami.

     
       
        
        
     
      
      
      
       
     
        
     
   public  static  Map  buildPdfFromSurveyResponse  (  DispatchContext  dctx  ,  kontekst  mapy  )  {  String  id  =  (  String  )  context  .  get  (  "identyfikatorodpowiedzi na ankietę"  );  Wyniki  mapy  =  nowa  HashMap  ();  try  {  // ...odpowiedź jest pobierana z bazy danych...  // ...z odpowiedzi tworzony jest plik pdf...  // ...plik pdf jest serializowany jako tablica bajtów...  ByteWrapper  outByteWrapper  =  ...;  wyniki  .  put  (  "outByteWrapper"  ,  outByteWrapper  );  }  catch  (  Wyjątek  e  )  {}  zwróć  wyniki  ;  } 

Ta wielopoziomowa metoda dostosowywania korzysta z miękkich odniesień, podobnie jak w przykładzie dotyczącym tworzenia ankiety . Główna różnica polega na tym, że odniesienie tutaj dotyczy modelu i kodu, a nie modelu i modelu. Zaletą w tym przypadku jest to, że można wykorzystać bibliotekę Java innej firmy do tworzenia plików PDF. Innym typowym zastosowaniem jest używanie fragmentów kodu Java do wywoływania zewnętrznych usług sieciowych i importowania wyników w odpowiednim formacie.

Problem z koordynacją

Przykład ilustruje niektóre zalety używania wielu języków w programowaniu. Istnieją jednak również trudności związane z tego rodzaju rozwojem. Trudności te wynikają z obserwacji, że im więcej rodzajów artefaktów wprowadzamy do naszego procesu, tym bardziej potrzebna jest koordynacja wysiłków programistów. Trudności te będziemy nazywać Problemem Koordynacji . Problem koordynacji ma aspekt koncepcyjny i techniczny. Koncepcyjnie głównym problemem jest zrozumienie różnych języków i ich interakcji. Aby właściwie projektować i koordynować modele w wielu językach, programiści muszą mieć wystarczającą wiedzę na temat interakcji między językami. Z technicznego punktu widzenia głównym problemem jest wymuszenie spójności. Należy zapewnić narzędzia do wczesnego wykrywania niespójności, tj. w czasie modelowania, i pomagać programistom w usuwaniu tych niespójności. W dalszej części przyjrzymy się bardziej szczegółowo tym dwóm aspektom.

Koordynacja jako wyzwanie koncepcyjne

Pierwszym problemem, jaki napotykają programiści rozpoczynający pracę nad wieloma językami, jest kakofonia językowa . Nauka różnych języków i zrozumienie ich interakcji jest konieczne, aby zrozumieć złożoną kompozycję artefaktów. framework OFBiz ma siedemnaście różnych języków i ponad 200 000 linii kodu języka specyficznego dla domeny, więc złożoność może być przytłaczająca! Obecnie nie ma ustalonej metody charakteryzowania różnych języków, dzięki której programiści mogliby szybko osiągnąć zrozumienie operacyjne. Narzędzia są tutaj ważne jako ad hoc do nauki i eksploracji, ponieważ programiści zazwyczaj używają narzędzi do nauki poprzez eksperymenty. Są szczególnie trzy obszary, w których pomocne są narzędzia do modeli specyficznych dla domeny:

1. Zrozumienie języka
2. Zrozumienie interakcji językowych
3. Zrozumienie, jak używać języków

Po pierwsze, zrozumienie języka może być trudne, aw przypadku języków specyficznych dla domeny opartych na XML częstym i intuicyjnym sprzeciwem jest sprzeciw dotyczący składni . Argument ten można sformułować w następujący sposób: „Różne języki są trudne do zrozumienia i tylko zwiększają zamieszanie, ponieważ ich składnia oparta na XML jest szczególnie rozwlekła i niezrozumiała. Używanie jednego języka ogólnego przeznaczenia, takiego jak Java, byłoby lepsze, ponieważ wtedy programiści mogliby polegać na składni, którą już znają”. Chociaż ten zarzut jest z pewnością ważny, pomija centralny punkt. XML lub podobny format reprezentacji może nie być składnią, z którą faktycznie pracują programiści. Jedną z zalet używania języków specyficznych dla domeny opartych na XML jest to, że możemy następnie zapewnić edytory specyficzne dla domeny. Poniższy rysunek pokazuje, jak mógłby wyglądać hipotetyczny edytor Entity DSL. Ten edytor przedstawia domenę w prosty i atrakcyjny wizualnie sposób, ale równie dobrze może wykorzystywać reprezentację XML (i być może konfigurację układu) pod spodem.

Tak jak możemy narzekać, że XML to zły wybór, możemy również sprzeciwić się temu, że język ogólnego przeznaczenia, taki jak Java, jest złym wyborem do niektórych zadań. Co więcej, programiści mogą czuć się mniej onieśmieleni przez edytor w postaci rysunku niż przez Listingi kodu w XML lub Javie. Jeśli zaakceptujemy, że składnia ma znaczenie , użycie różnych języków z dostosowanymi edytorami stanie się rozsądną strategią. Prostota edytora sprawia, że ​​język jest łatwiejszy do zrozumienia, a tym samym łatwiejszy w użyciu. Innymi słowy, dotyczący składni może być właśnie powodem, dla którego badamy dziedzinę języków specyficznych dla domeny .

Po drugie, interakcje językowe ujawniają relacje między językami. Deweloperzy powinni mieć możliwość przeskakiwania między powiązanymi elementami w różnych artefaktach. Łatwość nawigacji między różnymi artefaktami oprogramowania jest ważnym kryterium dla narzędzi w tradycyjnych środowiskach programistycznych. Chociaż nie przeprowadziliśmy żadnych badań empirycznych w tej dziedzinie, stawiamy hipotezę, że odpowiednie urządzenia nawigacyjne zwiększają produktywność. Twierdzenie to jest poparte obserwacją, że wszystkie główne środowiska programistyczne oferują obecnie dość wyrafinowane funkcje nawigacji, takie jak przeglądarka hierarchii typów lub możliwość szybkiego zlokalizowania i przeskoczenia do odniesień do definicji metody. Środowiska programistyczne mogą zapewnić te udogodnienia nawigacyjne, ponieważ utrzymują stale aktualizowany model plików źródłowych w postaci abstrakcyjnego drzewa składniowego .

W środowisku programistycznym z wieloma językami nawigacja jest znacznie trudniejsza. Istniejące środowiska nie są przystosowane do analizowania i przedstawiania modeli DSL jako abstrakcyjnych drzew składni dla dowolnych, a być może nawet specyficznych dla aplikacji języków, takich jak języki z poprzedniego przykładu. Co więcej, bez tej wewnętrznej reprezentacji istniejące środowiska nie mogą rozwiązać ani wewnątrz-, ani międzyjęzykowych odniesień dla takich języków, a zatem nie mogą zapewnić użytecznej nawigacji. Oznacza to, że programiści muszą utrzymywać koncepcyjny model tego, w jaki sposób części ich systemu są ze sobą powiązane. Z drugiej strony nowe narzędzia z udogodnieniami nawigacyjnymi dostosowanymi do wielu języków byłyby bardzo pomocne w zrozumieniu relacji między językami. Jeśli chodzi o tworzenia ankiety, takie narzędzia powinny wyświetlać relacje między trzema językami, używając miękkich odniesień jako punktów nawigacyjnych.

Po trzecie, aby zrozumieć użycie języka, musimy być w stanie odróżnić prawidłowe operacje edycyjne od niewłaściwych w naszym środowisku programistycznym. Tradycyjne środowiska programistyczne od dawna zapewniają wskazówki podczas pisania programu. Kompilacja przyrostowa umożliwia środowisku oferowanie programistom szczegółowych sugestii, takich jak sposób uzupełnienia zestawienia. Istnieją również bardziej inwazyjne rodzaje wskazówek, takie jak edytory zorientowane na składnię, w których można wprowadzać tylko dane wejściowe zgodne z gramatyką. Ogólne edytory tekstu, które można sparametryzować za pomocą gramatyki języka, istnieją od dawna.

Obecni redaktorzy nie biorą pod uwagę relacji spójności między językami przy udzielaniu wskazówek. W poprzednim przykładzie idealny edytor powinien na przykład być w stanie zasugerować usługę createSurvey jako prawidłową wartość, gdy programista edytuje atrybut docelowy w definicji formularza. Środowisko, które mogłoby wnioskować o artefaktach z różnych języków, mogłoby również pomóc programiście zidentyfikować stany programu, w których występowała spójność lokalna, ale nie globalna. Taka sytuacja może wystąpić, gdy model jest dobrze sformułowany , a zatem lokalnie spójny, ale jednocześnie narusza ograniczenie międzyjęzykowe. Wskazówki lub inteligentna pomoc w postaci propozycji, jak uzupełnić model, byłyby przydatne w przypadku konfiguracji z wieloma językami i złożonymi ograniczeniami spójności. Operacje edycyjne sugerowane przez narzędzie mogą ułatwić programiście rozpoczęcie procesu nauki korzystania z języków.

Koordynacja jako wyzwanie techniczne

Techniczny aspekt problemu koordynacji jest zasadniczo kwestią egzekwowania spójności. Jak możemy wykryć niespójności między modelami z wielu języków w czasie modelowania? Aby w pełni zrozumieć złożoność wymagań dotyczących spójności systemu opartego na wielu językach, warto udoskonalić naszą koncepcję spójności.

Spójność może być spójnością wewnątrz- lub między-spójnością. Spójność wewnętrzna dotyczy spójności elementów w ramach jednego modelu. Wymagania tutaj są takie, że model musi być zgodny ze swoim metamodelem, tj. być dobrze sformułowany składniowo. Jeśli chodzi o przykład tworzenia ankiety, model jednostki musi na przykład być zgodny ze schematem XSD Entity DSL. Ten schemat jest metamodelem Entity DSL i określa, w jaki sposób elementy mogą być komponowane i jakie są, do pewnego stopnia, prawidłowe domeny atrybutów.

Wzajemną spójność uzyskuje się, gdy można rozwiązać odniesienia przekraczające granice językowe. Ten rodzaj spójności można dalej podzielić na (1) spójność modelu z modelem i (2) spójność modelu z kodem. Spójność między modelami dotyczy integralności referencyjnej oraz ograniczeń wysokiego poziomu systemu. W dotyczącym tworzenia ankiety atrybut default-entity-name z listy Service odnosi się do atrybutu name z listy Entity. Jeśli zmienimy jedną z tych wartości bez aktualizacji drugiej, przerwiemy odniesienie. Istnieje również więcej ograniczeń spójności wysokiego poziomu w różnych modelach, jak omówiono później. Projekt może mieć określone wzorce lub konwencje nazewnictwa i powiązań elementów modelu. Obecne środowiska programistyczne muszą być dostosowane do określonych języków za pomocą odręcznych wtyczek lub podobnych mechanizmów, aby wymusić spójność między językami, takimi jak te z poprzedniego przykładu.

Spójność modelu z kodem jest podstawowym wymaganiem w przypadku dostosowywania wielopoziomowego. Kiedy modele są uzupełniane fragmentami kodu, tak jak w kompilacji PDF , konieczne jest sprawdzenie, czy modele i kod faktycznie pasują . Częściowo jest to kwestia upewnienia się, że miękkie odniesienia między modelami i kodem nie zostaną zerwane, podobnie jak integralność referencyjna w spójności między modelami. Ale to także kwestia upewnienia się, że kod nie narusza oczekiwań postawionych w modelu. W kompilacji PDF model określa, że ​​outByteWrapper zawsze będzie częścią danych wyjściowych, tj. klucz outByteWrapper jest umieszczany na mapie wyników. Analiza kodu pokazuje, że outByteWrapper będzie częścią danych wyjściowych tylko wtedy, gdy przed linią 10 nie zostaną zgłoszone żadne wyjątki. Innymi słowy, niektóre możliwe wykonania kodu naruszą specyfikację na poziomie modelowania. Mówiąc bardziej ogólnie, możemy stwierdzić, że dostosowywanie wielopoziomowe nakłada bardzo szczegółowe ograniczenia na zaangażowane modele i fragmenty kodu.

Rozwiązanie problemu koordynacji

Problem z koordynacją wynika z faktu, że w jednym systemie używanych jest wiele języków. Dwa poprzednie podrozdziały ilustrują, że problem ten ma zarówno stronę koncepcyjną, jak i stronę techniczną niskiego poziomu. Wyzwania, które opisaliśmy, są wyzwaniami rzeczywistymi, a nie hipotetycznymi. Konkretnie, zmierzyliśmy się z tymi wyzwaniami w dwóch konkretnych i reprezentatywnych studiach przypadków: system planowania zasobów przedsiębiorstwa, OFBiz oraz system opieki zdrowotnej , Okręgowy System Informacji o Zdrowiu ( DHIS ). Oba przypadki to średniej wielkości systemy, które są w rzeczywistym użyciu przemysłowym. Naszym rozwiązaniem praktycznych problemów, które napotkaliśmy podczas pracy z tymi systemami, jest zestaw wytycznych i prototypów. Poniżej przedstawimy ogólne ramy koncepcyjne, które obejmują wytyczne i prototypy w spójną metodę: metodę koordynacji .

Metoda koordynacji

Celem metody koordynacji jest rozwiązanie problemu koordynacji, a tym samym zapewnienie lepszego wsparcia dla programowania w wielu językach. Aby właściwie docenić tę metodę, ważne jest, aby zrozumieć, że nie narzuca ona projektowania poszczególnych języków. W tym celu zaproponowano już wiele metod i narzędzi. Ta metoda zakłada istnienie konfiguracji z wieloma językami specyficznymi dla domeny. Biorąc pod uwagę taką konfigurację, można zastosować metodę. Metoda składa się z trzech kroków, jak pokazano na poniższym schemacie. Każdy krok składa się z kilku części, które są pokazane jako małe prostokąty na schemacie. Pola z liniami przerywanymi reprezentują procesy automatyczne, a pola z liniami ciągłymi reprezentują procesy ręczne. Poniżej wyjaśnimy te kroki bardziej szczegółowo.

Krok 1: identyfikacja

Celem etapu identyfikacji jest zidentyfikowanie nakładających się języków. Jak opisano w przykładzie, nakładanie się to obszar, w którym przecinają się problemy dwóch języków. Miękkie odwołania od Form DSL do Service DSL i od Service DSL do Entity DSL w przypadku użycia tworzenia ankiety są przykładami takich nakładek. Innym przykładem jest przypadek, w którym do rozszerzenia modelu używany jest dostosowany fragment kodu. Takie nakładanie się jest częste, gdy ekspresywność języków ogólnego przeznaczenia jest potrzebna do wdrożenia specjalistycznych wymagań, które wykraczają poza zakres modelu. Etap identyfikacji może być procesem ręcznym lub automatycznym, w zależności od złożoności nakładania się. Kiedy nakładanie się zostanie zidentyfikowane i wyraźnie wyjaśnione, informacja ta jest wykorzystywana jako dane wejściowe do drugiego etapu metody: etapu specyfikacji.

Krok 2: specyfikacja

Celem etapu specyfikacji jest stworzenie modelu koordynacji , który określa sposób interakcji języków. Odniesienia ponad granicami językowymi w systemie stanowią model koordynacji dla tego konkretnego systemu. Jest tworzony przez mapowanie głównych artefaktów oprogramowania na wspólną reprezentację. Dodatkowe informacje, takie jak ograniczenia specyficzne dla domeny lub aplikacji, mogą być również kodowane w celu zapewnienia bogatej reprezentacji. Model koordynacji opiera się na ogólnych informacjach, takich jak gramatyka języka i ograniczenia, jak również na informacjach specyficznych dla aplikacji, takich jak konkretne modele i ograniczenia specyficzne dla aplikacji. Oznacza to, że chociaż te same języki są używane w kilku produktach, każdy produkt ma specyfikację własnego, unikalnego modelu koordynacji. Model koordynacji jest wykorzystywany jako podstawa dla różnych form wnioskowania w ostatnim etapie metody: etapie aplikacji.

Krok 3: aplikacja

Celem etapu aplikacji jest skorzystanie z modelu koordynacji. Model koordynacji umożliwia narzędziom uzyskanie trzech warstw przydatnych informacji. Po pierwsze, model koordynacji można wykorzystać do wymuszenia spójności w wielu językach. Model koordynacji określa relacje spójności, takie jak sposób, w jaki elementy z różnych języków mogą odnosić się do siebie. Narzędzia mogą wymuszać integralność referencyjną i przeprowadzać statyczne kontrole ostatecznego systemu przed wdrożeniem. Po drugie, relacje spójności są używane do nawigacji, wizualizacji i mapowania sieci różnych języków w konfiguracji programistycznej. Informacje te służą do szybkiego łączenia i powiązania elementów z różnych języków oraz zapewnienia identyfikowalności między różnymi modelami. Po trzecie, w oparciu o relacje spójności i informacje nawigacyjne o tym, jak elementy są ze sobą powiązane, narzędzia mogą zapewnić wskazówki, w szczególności uzupełnienie lub pomoc. Uzupełnianie modelu można na przykład zapewnić w sposób ogólny za pomocą narzędzi specyficznych dla domeny.

Ocena metody koordynacji

Metodę koordynacji można najlepiej postrzegać jako ramy koncepcyjne, które określają określony przepływ pracy podczas pracy z wieloma językami. Trzy kolejne kroki składające się na ten przepływ pracy nie są obsługiwane przez zintegrowane środowisko pracy ani środowisko programistyczne. Nacisk kładziony jest raczej na rozszerzenie istniejących środowisk deweloperskich w celu dodania obsługi (1) identyfikacji, (2) specyfikacji i (3) aplikacji. Główną zaletą tego podejścia było to, że programiści faktycznie przetestowali naszą pracę i przekazali nam informacje zwrotne. Taka ocena metody jest cenna, ponieważ zmniejsza ryzyko rozwiązania czysto hipotetycznego problemu. W kilku artykułach przedstawiono różne etapy metody koordynacji, sprawozdanie z tej oceny i omówiono techniczne aspekty każdego indywidualnego eksperymentu. Ogólnie rzecz biorąc, wyniki są obiecujące: w systemach produkcyjnych wykryto znaczną liczbę błędów, co dało początek konstruktywnemu dialogowi z programistami na temat przyszłych wymagań dotyczących narzędzi. Proces rozwoju oparty na tych wytycznych i wspierany narzędziami stanowi poważną próbę rozwiązania problemu koordynacji i uczynienia multimodelowania specyficznego dla domeny praktyczną propozycją.

Zobacz też

• Język specyficzny dla domeny
• Modelowanie specyficzne dla domeny
• Inżynieria oparta na modelach