ドメイン固有のマルチモデリング

ドメイン固有のマルチモデリング^{[1]は、各ビューが個別の}ドメイン固有言語（DSL）として明示的に作成されるソフトウェア開発パラダイムです。

現代のエンタープライズ システムを成功裏に開発するには、複数の視点を統合する必要があります。ビジネス アナリスト、ドメイン エキスパート、インタラクション デザイナー、データベース エキスパート、さまざまな専門知識を持つ開発者など、全員がこのようなシステムの構築プロセスに参加します。稼働中のシステムを作成するには、それぞれの作業成果物を管理、調整、統合する必要があります。開発プロセスの各参加者は、システムに対するそれぞれの視点に固有の問題を解決するために調整された特定の言語を持っています。これらの異なる視点を統合し、複数の異なる言語による潜在的な不協和音を回避するという課題は、調整問題です。

ドメイン固有のマルチモデリング^{[1]は、単一言語プログラミングや}汎用モデリングなどの従来の開発パラダイムと比較して有望です。この新しいパラダイムのメリットを享受するには、調整問題を解決する必要があります。この問題は、グローバルモデル管理のコンテキストでは断片化問題としても知られています。

この問題を解決するための提案の1つは、コーディネーション法です。^[1]これは、異なるビューを統合し、複数の言語を調整するという障害を克服するための3段階の方法です。この方法では、言語の境界を越えた参照、つまり異なる言語間の重複を(1)識別し、(2)指定する方法を規定しています。最後に、この方法は、(3)この知識を一貫性、ナビゲーション、ガイダンスの形で実際の開発に適用する方法について具体的な提案を提供します。

複数のドメイン固有言語に基づくエンタープライズ システムは数多く存在します。拡張マークアップ言語(XML) で定義されたメタモデルを持つ言語は、特に広く採用されています。複数の言語を使用した開発を説明するために、ケース スタディの Apache Open For Business (OFBiz) システムの例を挙げます。簡単に言うと、OFBiz は、在庫、会計、電子商取引などの標準コンポーネントを含むエンタープライズ リソース プランニングシステムです。これらのコンポーネントは、XML ベースの言語と通常の Java コードを組み合わせて実装されています。例として、コンテンツ管理コンポーネント、特に、以下のスクリーンショットに示すように、管理ユーザーがオンライン Web アンケートを作成するユース ケースに注目します。この例をアンケート作成例と呼びます。

この図は、実行中の OFBiz インスタンスのコンテンツ管理アプリケーションの管理インターフェイスのスクリーンショットを示しています。アンケートを作成するには、ユーザーは入力フォームのフィールドに入力し、更新ボタンを押します。これにより、新しいアンケートが作成され、編集して後で OFBiz のフロントエンド Web サイトに公開できます。このユース ケースでは、舞台裏でさまざまな言語で記述された複数の成果物が関係しています。この例では、これらの言語のうち、エンティティ、サービス、およびフォーム DSL の 3 つだけに焦点を当てます。

これら 3 つの言語は、OFBiz における構造、動作、およびユーザー インターフェイスの懸念事項にほぼ対応しています。エンティティ DSL は、基礎となるデータ モデルを記述し、作成されたアンケートを保存する方法を表すために使用されます。サービス DSL は、ユーザーが更新ボタンを押したときに呼び出されるサービスのインターフェイスを記述するために使用されます。最後に、フォーム DSL は、フォームの外観を記述するために使用されます。3 つの言語はそれぞれ異なる用途に合わせて調整されていますが、完全に分離することはできません。ユーザー インターフェイスは特定のアプリケーション ロジックを呼び出し、このアプリケーション ロジックはアプリケーションのデータを操作します。これは、非直交的な懸念事項の例です。言語が重複しているのは、それらが表す懸念事項を完全に分離できないためです。これら 3 つの言語をボトムアップ方式で調べ、重複している部分を明らかにしてみましょう。

エンティティ DSL は、OFBiz のデータ構造を定義します。以下のリストは、調査の概念を表すビジネス オブジェクトである Survey エンティティの定義を示しています。リストのコードは一目瞭然です。Survey というエンティティが 10 個のフィールドで定義されています。各フィールドには名前とタイプがあります。フィールド surveyId は主キーとして使用されます。この定義は、OFBiz のエンティティ エンジンと呼ばれる中心コンポーネントによって読み込まれます。エンティティ エンジンは、対応するビジネス オブジェクトをインスタンス化します。エンティティ エンジンの目的は、すべてのビジネス オブジェクトのトランザクション プロパティを管理し、Java Database Connectivity、Enterprise JavaBeans、さらには一部のレガシー システムなどのさまざまな永続化メカニズムと対話することです。

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

サービス DSL は、OFBiz のサービスのインターフェイスを指定します。各サービスは、システムのアプリケーション ロジックの一部をカプセル化します。この言語の目的は、さまざまな実装メカニズムを均一に抽象化することです。個々のサービスは、Java、スクリプト言語、またはルール エンジンを使用して実装できます。以下のリストは、createSurvey サービスのインターフェイスを示しています。

名前とは別に、サービス要素はこのサービスの実装の場所と呼び出しコマンドを指定します。default-entity-name 属性は、このサービスが前のリストで定義された Survey エンティティを参照することを指定します。これは 2 つの言語間の重複であり、具体的にはいわゆるソフト参照です。サービス DSL のモデルは、エンティティ DSL のモデルを参照します。この参照は、以下の 2 つの自動属性要素で使用され、型付き属性の形式でサービスの入力と出力を指定します。入力として、サービスは Survey エンティティのすべての非主キー (nonpk) フィールドに対応する属性を受け入れます。これらの属性はオプションです。出力として、サービスは Survey の主キー (pk) フィールド (この場合は surveyId フィールド) に対応する属性を返します。これらの属性は必須です。この場合、言語間の参照の目的は冗長性を減らすことです。createSurvey サービスの属性は Survey エンティティのフィールドに対応するため、一度だけ指定する必要があります。

  <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" option= "false" /> </service>   
           
                 
                        
       
       
  

フォーム DSL は、ユーザー インターフェイスの入力フォームのレイアウトと外観を記述するために使用されます。この言語は、フォームやフィールドなどのドメイン概念で構成されます。以下のリストは、EditSurvey フォームの実装を示しています。今回は、フォーム DSL がサービス DSL と重複しています。フォームの target 属性と alt-target 要素は、このフォームの送信からの入力が updateSurvey サービスまたは createSurvey サービスのいずれかに送信されるよう指定します。auto-fields-service 要素は、フォームに updateSurvey サービスの各属性 (createSurvey サービスの属性に類似) に対応するフィールドを含めるよう指定します。これにより、前のリストの auto-attributes 要素の場合と同様に、別のモデルから定義をインポートするのと同様の効果が得られます。さらに下に進むと、isAnonymous などのこれらのインポートされたフィールドの外観をカスタマイズできることがわかります。最後に、ローカライズされたタイトルを持つ 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>   
         
      
     
        
         
        
          
      
    
          
           
       
    
  

ここで説明されているアンケート作成の例は、3 つの異なる言語のモデルを使用して実装されています。完全な実装には、フォームが配置される画面のレイアウトを指定するための Screen DSL や、サービスを実装するために使用されるデータ操作言語である Minilang DSL など、さらに多くの言語が関係します。ただし、これら 3 つの言語は、各懸念事項を具体化するという主要な考え方を示しています。また、この例では、言語をわずかに重複させることで冗長性を減らす簡単な方法も示しています。

上で説明したようなドメイン固有言語は、表現力が限られています。言語の範囲を超えた特殊な機能を実装するには、Javaなどの汎用言語でコードスニペットを追加する必要があることがよくあります。この方法は、マルチレベルカスタマイズと呼ばれます。^[2] この方法は、複数の言語を使用するセットアップで非常に一般的に使用されているため、例の続きで説明します。これをPDFビルドの例と呼ぶことにします。

ユーザーが作成したオンライン アンケートに対する各アンケート回答のPDF ファイルを作成するとします。PDF ファイルの作成は言語の範囲外であるため、この特殊な機能を実行するには、サードパーティの PDF ライブラリを呼び出す Java コードを記述する必要があります。次の 2 つの成果物が必要です。

まず、以下に示すように、サービス DSL 内の追加のサービス モデルは、モデリング レベルでアクセスできるように具体的なサービスのインターフェイスを定義します。サービス モデルは、実装の場所と、入力属性と出力属性について説明します。

  <サービス名= "buildPdfFromSurveyResponse"エンジン= "java"場所= "org.ofbiz.content.survey.PdfSurveyServices"呼び出し= "buildPdfFromSurveyResponse" > <属性名= "surveyResponseId"モード= "IN"オプション= "false" ... /> <属性名= "outByteWrapper"モード= "OUT"オプション= "false" ... /> </サービス>  
    
    
      
       
      
       
  

次に、以下に示すように、このサービスの実際の実装を含むコード スニペットが必要です。サービスには複数の入力と出力があるため、Java メソッドへの入力は、引数名から引数値へのコンテキストと呼ばれるマップであり、結果と呼ばれる別のマップの形式で出力を返します。

  public static Map buildPdfFromSurveyResponse ( DispatchContext dctx , Map context ) { String id = ( String ) context . get ( "surveyResponseId" ); Map results = new HashMap (); try { // ...レスポンスがデータベースから取得されます... // ...レスポンスから PDF が作成されます... // ...PDF がバイト配列としてシリアル化されます... ByteWrapper outByteWrapper = ...; results . put ( "outByteWrapper" , outByteWrapper ); } catch ( Exception e ) {} return results ; }   
       
        
        
     
      
      
      
       
     
        
     
  

このマルチレベル カスタマイズ方法では、アンケート作成の例と同様にソフト参照を使用します。主な違いは、ここでの参照はモデルとモデルの間ではなく、モデルとコードの間であることです。この場合の利点は、PDF を作成するためのサードパーティの Java ライブラリを利用できることです。もう 1 つの一般的なアプリケーションは、Java コード スニペットを使用して外部 Web サービスを呼び出し、結果を適切な形式でインポートすることです。

この例では、開発で複数の言語を使用する利点の一部を示しています。ただし、この種の開発には困難も伴います。これらの困難は、プロセスに導入する成果物の種類が増えるほど、開発者の作業間の調整が必要になるという観察から生じます。これらの困難を調整問題と呼ぶことにします。調整問題には、概念的側面と技術的側面があります。概念的には、主な問題は、さまざまな言語とその相互作用を理解することです。複数の言語でモデルを適切に設計および調整するには、開発者は言語の相互作用を十分に理解している必要があります。技術的には、主な問題は一貫性を確保することです。不一致を早期に、つまりモデリング時に検出し、開発者がこれらの不一致を解決できるように支援するツールを提供する必要があります。以下では、これら 2 つの側面を詳しく検討します。

開発者が複数の言語で開発を始めるときに最初に直面する問題は、言語の不協和音です。さまざまな言語を学習し、それらの相互作用を理解することは、複雑な成果物の構成を理解するために必要です。たとえば、OFBiz フレームワークには 17 の異なる言語と 200,000 行を超えるドメイン固有言語コードがあるため、その複雑さは非常に圧倒的です。現在、開発者がすぐに操作上の理解に到達できるように、さまざまな言語を特徴付ける確立された方法はありません。開発者は通常、ツールを使用して実験によって学習するため、ここでは学習と探索のアドホックメカニズムとしてツールが重要です。ドメイン固有モデルのツールが役立つのは、特に次の 3 つの領域です。

1. 言語を理解する
2. 言語の相互作用を理解する
3. 言語の使い方を理解する

まず、言語を理解するのは難しい場合があります。XML ベースのドメイン固有言語の場合、構文が重要であるという反論が頻繁に聞かれます。この議論は次のように述べることができます。「さまざまな言語は理解しにくく、特に XML ベースの構文が冗長でわかりにくいため、混乱を招くだけです。Java などの単一の汎用言語を使用する方が、開発者がすでに知っている構文に頼ることができるので良いでしょう。」この反論は確かに重要ですが、核心を見逃しています。XML または同様の表現形式は、開発者が実際に使用する構文ではない可能性があります。XML ベースのドメイン固有言語を使用する利点の 1 つは、ドメイン固有のエディターを提供できることです。次の図は、エンティティ DSL の架空のエディターがどのように見えるかを示しています。このエディターは、ドメインをシンプルで視覚的に魅力的な方法で表示しますが、その下にある XML 表現 (およびおそらくレイアウト構成) を使用することもできます。

XML は悪い選択だと文句を言うのと同じように、Java のような汎用言語も一部のタスクには適さないと反論できるでしょう。さらに、開発者は、XML や Java のコード リストよりも、図のエディターにあまり威圧感を感じないかもしれません。構文が重要であることを認めるなら、さまざまな言語をカスタマイズされたエディターとともに使用することは合理的な戦略になります。エディターが単純であれば、言語は理解しやすくなり、したがって使いやすくなります。言い換えれば、構文が重要であるという反論こそが、ドメイン固有言語の分野を探求する理由そのものなのかもしれません。

第二に、言語の相互作用は言語間の関係を明らかにします。開発者は、異なる成果物内の関連する要素間を移動できる必要があります。異なるソフトウェア成果物間のナビゲーションの容易さは、従来の開発環境のツールにとって重要な基準です。この分野で実証的な研究は行っていませんが、適切なナビゲーション機能により生産性が向上するという仮説を立てています。この主張は、今日のすべての主要な開発環境が、型階層ブラウザーやメソッド定義への参照をすばやく見つけてジャンプする機能など、非常に洗練されたナビゲーション機能を提供しているという観察によって裏付けられています。開発環境がこれらのナビゲーション機能を提供できるのは、抽象構文ツリーの形式で継続的に更新されるソースファイルのモデルを維持しているためです。

複数の言語を使用する開発環境では、ナビゲーションははるかに困難です。既存の環境は、前の例の言語のような任意の言語、場合によってはアプリケーション固有の言語の抽象構文木として DSL モデルを解析および表現するように調整されていません。さらに、この内部表現がなければ、既存の環境ではそのような言語の言語内参照も言語間参照も解決できず、したがって便利なナビゲーションを提供できません。つまり、開発者はシステムの各部分がどのように関連しているかの概念モデルを維持する必要があります。一方、複数の言語に対応したナビゲーション機能を備えた新しいツールは、言語間の関係を理解するのに非常に役立ちます。調査の作成例に関して言えば、そのようなツールは、ソフト参照をナビゲーション ポイントとして使用して、3 つの言語間の関係を表示する必要があります。

第三に、言語の使用を理解するには、開発環境において正しい編集操作と間違った編集操作を区別できなければなりません。従来の開発環境は、プログラムの作成中に長い間ガイダンスを提供してきました。増分コンパイルにより、環境は開発者にステートメントの完成方法などの詳細な提案を提供できます。文法に準拠した入力のみを入力できる構文指向のエディターなど、より侵入的な種類のガイダンスも存在します。言語の文法でパラメータ化できる汎用テキストエディターは、長い間存在してきました。^[3]

既存のエディターは、ガイダンスを提供する際に言語間の一貫性関係を考慮していません。前の例では、理想的なエディターは、たとえば、開発者がフォーム定義のターゲット属性を編集するときに、createSurvey サービスを有効な値として提案できる必要があります。異なる言語からの成果物を推論できる環境は、ローカルな一貫性はあるがグローバルな一貫性がないプログラム状態を開発者が特定できるようにもなります。このような状況は、モデルが適切に形成され、したがってローカルに一貫性があるが、同時に言語間の制約に違反している場合に発生する可能性があります。モデルを完成させる方法に関する提案の形でのガイダンスまたはインテリジェントな支援は、複数の言語と複雑な一貫性制約のあるセットアップに役立ちます。ツールが提案する編集操作により、開発者は言語の使用方法を学習するプロセスを開始しやすくなります。

調整問題の技術的な側面は、本質的に一貫性を強制することです。モデリング時に、複数の言語のモデル間の不一致をどのように検出できるでしょうか。複数の言語に基づくシステムの一貫性要件の複雑さを完全に理解するには、一貫性の概念を洗練することが役立ちます。

一貫性は、内部一貫性または内部一貫性のいずれかになります。内部一貫性は、単一のモデル内の要素の一貫性に関係します。ここでの要件は、モデルがそのメタモデルに準拠している必要がある、つまり構文的に整形式である必要があることです。アンケート作成の例では、エンティティ モデルは、たとえばエンティティ DSL の XSD スキーマに準拠している必要があります。このスキーマはエンティティ DSL のメタモデルであり、要素の構成方法と、ある程度の属性の有効なドメインを指定します。

言語の境界を越えた参照が解決できる場合、相互一貫性が実現されます。この種の一貫性は、さらに (1) モデル間の一貫性と (2) モデルとコードの一貫性に細分できます。モデル間の一貫性は、参照整合性とシステムの高レベルの制約に関係します。アンケート作成の例では、サービス リストの default-entity-name 属性は、エンティティ リストの name 属性を参照しています。これらの値の 1 つを変更して、もう 1 つを更新しないと、参照が壊れます。後述するように、異なるモデル間でのより高レベルの一貫性制約も存在します。プロジェクトには、モデル要素の命名と関連付けに関する特定のパターンまたは規則がある場合があります。現在の開発環境は、前の例のような言語間の一貫性を強制するために、手書きのプラグインまたは同様のメカニズムを使用して特定の言語に合わせて調整する必要があります。

モデルとコードの一貫性は、マルチレベルのカスタマイズにおいて不可欠な要件です。PDFビルドの例のようにモデルにコード スニペットが追加されている場合は、モデルとコードが実際に適合していることを確認する必要があります。これは、モデルとコード間のソフト参照が壊れていないことを確認するという問題の一部であり、モデル間の一貫性における参照整合性に似ています。しかし、コードがモデルで設定された期待に違反していないことを確認するという問題でもあります。PDFビルドの例では、モデルは outByteWrapper が常に出力の一部となるように指定しています。つまり、outByteWrapper キーは結果マップに配置されます。コードを分析すると、10 行目より前に例外がスローされない場合にのみ、outByteWrapper が出力の一部となることがわかります。つまり、コードの実行によっては、モデリング レベルの仕様に違反することになります。より一般的には、マルチレベルのカスタマイズでは、関係するモデルとコード スニペットに非常にきめ細かい制約が課されると言えます。

調整の問題は、1 つのシステムで複数の言語が使用されていることから生じます。前の 2 つのサブセクションでは、この問題には概念的な側面と低レベルの技術的な側面の両方があることを示しています。ここで説明した課題は、仮説的な課題ではなく、実際の課題です。具体的には、エンタープライズ リソース プランニング システム OFBiz とヘルスケア システムDistrict Health Information System ( DHIS ) という 2 つの具体的で代表的なケース スタディでこれらの課題に直面しました。どちらのケースも、実際に産業で使用されている中規模のシステムです。これらのシステムでの作業中に遭遇した実際的な問題に対するソリューションは、一連のガイドラインとプロトタイプです。以下では、ガイドラインとプロトタイプを一貫した方法に組み込んだ全体的な概念フレームワーク、つまり調整方法を紹介します。

コーディネーション法^[1]の目標は、コーディネーション問題を解決し、複数の言語による開発をより適切にサポートすることです。この方法を正しく理解するには、個々の言語の設計を規定するものではないことを理解することが重要です。このために、すでに多くの方法とツールが提案されています。^{[4] [5]}この方法は、複数のドメイン固有言語のセットアップが存在することを前提としています。そのようなセットアップがあれば、この方法を適用できます。この方法は、下の図に示すように 3 つのステップで構成されています。各ステップは、図に小さなボックスで示されているいくつかの部分で構成されています。点線のボックスは自動プロセスを表し、実線のボックスは手動プロセスを表します。以下では、これらのステップについてもう少し詳しく説明します。

識別ステップの目標は、言語の重複を識別することです。例で説明したように、重複とは 2 つの言語の関心事が交差する領域です。アンケート作成ユースケースのフォーム DSL からサービス DSL へのソフト参照、およびサービス DSL からエンティティ DSL へのソフト参照は、このような重複の例です。別の例としては、カスタマイズされたコード スニペットを使用してモデルを拡張する場合が挙げられます。このような重複は、モデルの範囲を超えた特殊な要件を実装するために汎用言語の表現力が必要な場合によく発生します。識別ステップは、重複の複雑さに応じて、手動または自動のプロセスになります。重複が識別され、明示されると、この情報は、メソッドの 2 番目のステップである仕様ステップへの入力として使用されます。

仕様ステップの目標は、言語がどのように相互作用するかを指定する調整モデルを作成することです。システム内の言語境界を越えた参照は、その特定のシステムの調整モデルを構成します。調整モデルは、主要なソフトウェア成果物を共通の表現にマッピングすることによって作成されます。ドメインまたはアプリケーション固有の制約などの追加情報もエンコードされ、豊富な表現が提供されます。調整モデルは、言語の文法や制約などの一般的な情報と、具体的なモデルやアプリケーション固有の制約などのアプリケーション固有の情報に基づいています。つまり、同じ言語が複数の製品で使用されている場合でも、各製品には独自の調整モデルの仕様があります。調整モデルは、方法の最終ステップであるアプリケーション ステップで、さまざまな形式の推論の基礎として使用されます。

アプリケーション ステップの目標は、調整モデルを活用することです。調整モデルにより、ツールは 3 層の有用な情報を導き出すことができます。まず、調整モデルを使用して、複数の言語間で一貫性を強制できます。調整モデルは、異なる言語の要素が互いに参照する方法などの一貫性関係を指定します。ツールは参照整合性を強制し、展開前に最終システムの静的チェックを実行できます。次に、一貫性関係は、開発セットアップでさまざまな言語の Web をナビゲート、視覚化、およびマッピングするために使用されます。この情報は、さまざまな言語の要素をすばやくリンクして関連付け、さまざまなモデル間の追跡可能性を提供するために使用されます。3 番目に、一貫性関係と要素の関連性に関するナビゲーション情報に基づいて、ツールはガイダンス、具体的には完了または支援を提供できます。たとえば、モデルの完了は、ドメイン固有のツール間で一般的な方法で提供できます。

コーディネーション法^[1]は、複数の言語で作業する場合に特定のワークフローを規定する概念フレームワークとして最もよく考えることができます。このワークフローを構成する 3 つの連続するステップは、統合ワークベンチや開発環境ではサポートされていません。むしろ、開発者の既存の環境を拡張して、(1) 識別、(2) 仕様、(3) アプリケーションのサポートを追加することに重点が置かれています。このアプローチの主な利点は、開発者が実際に私たちの作業をテストし、フィードバックを提供してくれたことです。この方法のこのような評価は、純粋に仮説的な問題を解決するリスクを軽減するため、価値があります。いくつかの論文では、コーディネーション法のさまざまなステップを紹介し、この評価について報告し、個々の実験の技術的側面について詳しく説明しています。全体として、結果は有望です。実稼働システムでかなりの数のエラーが見つかり、将来のツール要件について開発者との建設的な対話が生まれました。これらのガイドラインに基づき、ツールでサポートされた開発プロセスは、コーディネーションの問題を解決し、ドメイン固有のマルチモデリングを実用的な提案にする真剣な試みです。

• ドメイン固有言語
• ドメイン固有のモデリング
• モデル駆動エンジニアリング