モデル駆動エンジニアリングのために汎用言語とDSLを組み合わせる - Johan den Haan
この記事はJohan den Haan氏のブログ記事「http://www.theenterprisearchitect.eu/archive/2008/04/15/combining_general_purpose_lang」を、氏の許可を得て翻訳したものです。（原文公開日：2008年4月15日）
モデル駆動エンジニアリングに関する以前の記事で、私はMDEの基本的な原則は「全てがモデルである」ということだと述べた。モデルとその要素にはファーストクラスの地位が与えられている。本質的な違いは、モデルがもはやプログラマのための単なるドキュメントとして使用されるだけではなく、ソフトウェア開発を駆動させるために直接利用できるということだ。モデルは、実装、変換、ソフトウェア成果物の諸相、システムに関する視点などを定義するのに用いられる。この記事で、私はモデルとは何なのか（モデルに関する様々な利用シナリオを考慮に入れる）、そしてメタモデルを使っていかにモデルが定義されるかについて明らかにしていく。
メタモデルを用いたモデルの定義は、言語的な定義と見なすことができるものであり、これは汎用言語（"general purpose language"）ないしは、ドメイン固有言語（"domain specific language"）を用いて行われる。ほとんどの手法において、汎用言語とドメイン固有言語のどちらかが選択されるが、私は、両者の利点を用いて２つの手法を組み合わせることができると考えている。このような手法が持つ威力について、BPMNとBPELを用いたプロセスモデリングを例に示していく。これは、ほぼ直接実行することができるようなドメイン固有プロセスモデリングを構築するものだ。
この抽象的な主題について、できる限りシンプルに、ただし科学的な根拠に基づいて説明しようと試みた。その結果、今回の記事は非常に長くなってしまったのだ。読者が一部を飛ばしたいと思われるのであれば、以下の目次を使って興味のあるパートに飛んで頂きたい。
モデルとは何か？
「モデル」という単語はラテン語の「modulus」という単語に由来している。この意味は、基準、ルール、パターン、従うべき例（Ludewig, 2003）などだ。ソフトウェアエンジニアリングにおけるモデルという単語の定義を以下に示す。
- モデルとは、研究対象であるシステム（"SUS"）に関する一連のステートメントである。ここでいうステートメントとは、研究対象であるシステムに関するなんらかの表現であり、真偽の考察ができるものである（Seidewitz, 2003）。
- あるモデルは、（現実の、あるいは言語に基礎をおいた）システムを抽象化したものであり、それによって予測を立てたり、インタフェースを作成することができるようになる（Kühne, 2006）。
他にも多くの定義が見られる。様々な定義をすべて洗い上げることにはあまり意味がないと思われる。モデルに関する何らかの基準や特徴を見た方が役に立つだろう。Ludewig （Ludewig, 2003） とKühne （Kühne, 2006）はどちらもStachowiak （Stachowiak, 1973）に言及している。Stachwiakは、モデルは３つの特徴を持ち、この３つの基準に合わなければモデルではないと論じている。
- マッピング（"Mapping"）：モデルはオリジナルに基づく。オリジナル（システム）は、まだ構築されていないものかもしれないし、完全に想像上のものに留まっているかもしれない。したがって、Kühneは主体（"subject"）の方がオリジナルよりも適切な単語であると付け加えている。
- 簡略化（"Reduction"）：主体が持つ全ての属性がモデルに紐づけられる訳ではなく、モデルとは何らか簡略化されたものだ。それでも、主体が持つ少なくともいくつかの属性はモデルに反映されていなければならない。
- 実用的（"Pragmatic"）：モデルはある目的に従って、主体の代わりに使うことができる必要がある。
モデルは常に主体と何らかの関係を持つ（主体はほとんどの場合システムだが、他のモデルである場合もある）。この関係は２つの次元から分類することができる。それがモデルの役割とモデルの利用法だ。
モデルの役割
モデルには以下の役割がある（Kühne, 2006）。
- 表象モデル（"Token model"）：表象モデルとは、一般にモデルについて語る時に人々が思い浮かべるものである。表象モデルは、主体（もしくはその一部）の要素と１対１対応する代表物から構成されている。つまり、抽象化は行われていない。表象モデルの別名としては、「代表モデル（"representation model"）」（直接代表する性質から）、「インスタンスモデル（"instance model"）」（モデルの要素が型ではなくインスタンスであるため）、「単一モデル（"singular model"）」（各要素は普遍ではなく個別のものに割り当てられているため）、「外延モデル（"extensional model"）」（システムの要素に対して数え上げることができるため）などが挙げられる。語られたモデルの具体例としては、地図や特定の家の建築計画がある。
- 型モデル（"Type model"）：表象モデルとは対称的に、型モデルは主体の要素が持つ普遍的な局面を分類によって捕捉する。オブジェクトの性質（例えば、４つ足、毛皮、鋭い歯、立体視）はオブジェクトを分類するのに用いられる（例えば、肉食動物）。型モデルに対する別名としては、「スキーマモデル」「分類モデル」「普遍モデル」「内包的モデル」がある。型モデルは分類することによって作られることから、システムの表象モデルは、システムの型モデルのインスタンスであると言うこともできる。
図１は例を用いて２つの概念をより詳細に説明したものである。主体は現実世界であり、表象モデルは現実世界の要素と１対１で紐づく。型モデルでは要素を街と道路という２つの概念に分類し、それらの関係を示している。
図１ - モデルの役割の種類 （Kühne, 2006）
モデルの利用法
異なる役割に分類することの他に、モデルはその利用法に従って分類され得る。あるモデルは、実存するオリジナルを映すことができる（例えば写真）し、これから作成するものの仕様として使うこともできる（例えば建築計画）。前者のモデルを記述的（"descriptive"）と呼び、後者を規範的（"prescriptive"）と呼ぶ（Ludewig, 2003）。最初は記述的であったモデルが後になって規範的になる場合は、過渡的（"transient"）と呼ぶ。これはオリジナルを変更しなければいけない場合である。最初にオリジナルに対する記述的なモデルが作成される（例えば家）。その後、何らかの変更がモデルに対して加えられ、オリジナルに適用される（家の絵を修正し、実際に建物を変更する）。
ソフトウェアエンジニアリングにおいては、多くのモデルが利用されるが、多くは規範的である（図２を参照）。要求仕様だけは、記述的であると同時に規範的である。ユーザの要求を記述し、開発されるプロダクトの規範となるからだ。この２重の役割のために、仕様は最も重要なソフトウェアのモデルとなるのだ（Ludewig, 2003）。ソフトウェアエンジニアリングにおける問題は、記述的モデルを構成するのが極めて困難であるということだ。記述的なモデルを構築するには、オリジナルについてよく知らなければならない。ほとんどの場合、ソフトウェアエンジニアリングプロジェクトの「現実世界」はひどいもの（"mess"）であり、要件は完全でも正確でもない。もう一つの問題は、記述的モデルは実世界のごく一部をカバーしているに過ぎない、シンプルさとリアリズムの妥協の産物だということだ。一方、規範的モデルは構築するのは容易だが、作成者の意図にかかわらず命令を下すことができるという問題がある。多くの考えが実際に試されることはない。
図２ - ソフトウェアエンジニアリングプロセスにおける（シンプルな）モデルの連鎖；点線の矢印は「記述的モデル」を意味し、矢印は「規範的モデル」を意味する。図４に基づく。（Ludewig, 2003）
メタモデルとは何か？
モデルの特徴、役割、利用シナリオが明らかになった所で、次の問題はどうやってモデルの言語が定義されるのかということだ。メタモデルはしばしばモデルのモデルと言われるもので、モデル（およびそのマイクロプロセス）を定義する上で重要な概念である。メタモデルは常に型モデルである。主体モデルの要素を分類するからだ。
図３はUMLに関する４層のメタモデル階層を示した例だ。基礎構造はモデルレベルの階層から構成されており、（最上位を除いた）各階層は、上位の「インスタンス」として特徴づけられる。図３に示す通り、レベルM0はユーザデータを保持している。レベルM1はレベルM0のデータについてのモデルである。レベルM2はレベルM1のモデルのモデルであることから、メタモデルとも呼ばれる。最終的に、レベルM3はレベルM2の情報についてのモデルを保持しており、メタ-メタモデルとも呼ばれる。OMGによれば、メタモデルは主体モデルにとっての言語定義である。
図３ - UMLの４層メタモデル階層の例 （OMG, 2007）
UMLは広く受け入れられており、また第一世代のMDE手法においては基礎として利用されることに成功していたが、いくつかの問題が見つかっている（Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002）。最も重大なものが、複合的分類という問題だ（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）
複合的分類
AtkinsonとKühneによれば（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）、UMLフレームワークは解釈レベルとinstance-ofリンクにおいてきわめてリベラルな手法を採用しているため、以下の結果を生んでいる。
- 異なる種類のinstance-of関係が厳格に区別されていない。
- 特定の要素がどのレベルにあるべきかを判断するにあたり、明確な原則が存在しない。
こういった問題の原因は、メタモデリングというコンセプトが言語定義の手段として用いられている点にある。AtkinsonとKühneはこれを言語的メタモデリングと呼んでいる（Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002）。しかし、AtkinsonとKühneによれば、メタモデリングに関するこの「伝統的な」見方は、２つの重要な次元のうち１つしかカバーしていない。学生はエンティティのインスタンスであるといった言語的なインスタンス化に加え、学生は人間のインスタンスでもあると定義するような存在論的インスタンス化関係も存在するのだ（Karagiannis & Höfferer, 2006）。言語的メタモデリングにおいて、学生と人間は同じレイヤに存在するが、存在論的な視点からは人間はメタレイヤに存在することになろう。AtkinsonとKühneはこれを存在論的メタモデリングと呼んでいる。
図３に示す例を見よう。「2001年宇宙の旅」のビデオはインスタンスであると同時にビデオでもある。インスタンスがメタレイヤにおいて定義されているのに対し、ビデオは同じレイヤで定義されている。インスタンスは「2001年宇宙の旅」の言語的定義であり、属性と関連を持つことを定義しているのに対し、ビデオは存在論的定義であり、題名という属性を持つことを定義している。
| 出典 | Instance-of関係１ | Instance-of関係２ |
| （Geisler, Klar, & Pons, 1998） | レベル内（"intralevel"）のインスタンス化 | レベル間（"interlevel"）のインスタンス化 |
| （Bézivin & Gerbé, Towards a Precise Definition of the OMG/MDA Framework, 2001） | Instance-of | メタインスタンス |
| （Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002） | 論理ドメインの分類子 | 物理分類子 |
| （Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002） | 存在論的instance-of | 言語的instance-of |
表１ - 文献に見られる、異なる言語的関係
文献において、２つの異なるインスタンス化という考え方は新しいものではない。表１ではその他の文献における異なるインスタンス化関係についての語り方とそれをどう呼んでいるかを概観したものである。ここでは言語的インスタンス化と存在論的インスタンス化という呼称を使い続ける。それが最も扱いやすいからだ。
言語的メタモデリング
モデルBに対する言語的メタモデルAは、Bの記法となっているモデリング言語についてのモデルと見なすことができる。換言すれば、メタモデルＡはモデルBの言語を定義している。この場合、モデルBの要素はメタモデルAに含まれる要素の言語的インスタンスなのだ。要素と言語的型の間にある言語的インスタンス化は、型がどのような式であれば妥当なセンテンスなのかを定義している言語（あるいはその断片）を表象しているのだという推測に基づいている。したがって、要素eが型Tが意味するものに収まっているのであれば、要素eは型Tの言語的インスタンスである（Kühne, 2006）。
言語的インスタンス化は要素の形式に影響される。言語的メタモデルはモデルの構文的構造的側面、すなわち抽象構文を定義する。また同時に、モデルの意味論の一部も定義する。これがすなわち型であり、静的動的意味論である。
- 抽象構文（"Abstract syntax"）：各言語のモデルを形成するエンティティについての抽象的な記述（Geisler, Klar, & Pons, 1998）。
- 型意味論（"Type semantics"）：オブジェクトの型意味論は、言語的メタモデリングのプロセスを通じて定義され、これによって推論が可能になる。例えば、学生はメタモデルの構成エンティティから生成されたものであるため、現実世界のオブジェクトの一種であって関係ではないというものだ（Karagiannis & Höfferer, 2006）。
- 静的意味論（"Static semantics"） （コンテキストによる条件、制約）：構文的エンティティ間の適格条件（"well-formedness condition"）。例えば循環継承の不在など（Geisler, Klar, & Pons, 1998）。
- 動的意味論（"Dynamic semantics"） （明示的意味）：仕様を示すエンティティの（操作的な）ふるまい。例えば、入出力、刺激に対する反応、操作の実行結果など（Geisler, Klar, & Pons, 1998）。
言語的メタモデルの一例として、ビジネスプロセスモデリング記法（BPMN）が挙げられる（OMG, 2006）。これが定義するのは、異なる種類の要素や関連（抽象構文と型意味論）、要素が相互に結合される方法（静的意味論）、そして「イベントはプロセスのフローに影響を与える」といった異なる要素の基本的なふるまいである。その他のよく知られた例としては、E-RメタモデルやUMLメタモデルがある。
存在論的メタモデリング
「伝統的な」言語的メタモデリングの次元に加え、存在論的メタモデリングの次元も同様に重要である。哲学において、存在論とは存在するものについての研究である。存在論は「結合部分において世界を切り分ける」とよく言われる。「存在論的分析によって、知識の構造が明らかになる。あるドメインに対して、存在論はそのドメインに対する知識の表象がもつ全体系の中心を形成する。存在論がなければ、あるいは知識の根底にある概念化がなければ、知識を表象する語彙は存在し得ない」（Chandrasekaran, Josephson, & Benjamins, 1999）。ソフトウェアエンジニアリングにおいても、存在論は重要である。どのようなソフトウェアプログラムであっても、何か有用なことを実行するには現実世界のモデルが必要であり、したがって存在論を必要とするのだ（Chandrasekaran, Josephson, & Benjamins, 1999）。
存在論とは概念と概念間の関係についての体系である。そこではあらゆる概念が定義され、宣言的な方法で解釈される（Devedzic, 2002）。この体系によって定義されるのは、問題領域（"problem domain"）の語彙と、各単語がドメインをモデル化する上でどう組み合わせられるのかという制約である。存在論のより良く知られている同義語が「ドメインモデル」である。２つの要素、あるいは２つのモデル間の存在論的インスタンス化は、意味から見た両者の関係に基づいている（Kühne, 2006）。存在論的階層の具体例を図４に示そう。「ラッシー」（"Lassie"）*1は「コリー」（"Collie"）の存在論的インスタンスであり、「コリー」は「品種」（"Breed"）の存在論的インスタンスである。
言語的メタモデルがモデルの言語（抽象構文、型意味論、静的意味論、動的意味論を含む）を定義しているのに対し、存在論的メタモデルはモデルの内在的意味論（"inherent semantics"）を定義する。この内在的意味論は、モデル化されたリソースの「内的な意味（"inner meaning"）」を記述し、概念について推論するための基礎を提供する（Karagiannis & Höfferer, 2006）。例えば、学生は大学のような機関に所属している男性または女性の人間であるというようにである。存在論は宣言的言語を定義するための基礎である。つまり、「How」ではなく「What」を定義する言語なのだ。
メタモデルの階層
図３において、UMLのメタモデル階層を示した。これまでの議論より、この階層が言語的メタモデルの階層であると結論づけることができる。既存のメタモデルの階層はほとんどが言語的階層なのだ。
存在論的メタモデルの階層
存在論的メタモデルの階層の具体例を図５に示す（Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004）。最上位のレイヤは抽象的な技術的概念を記述している。これらは特定のプラットフォームに限定されないもので、MDAのプラットフォームから独立したモデルに含まれる概念に似ている。例としてはデータセット（"DataSet"）が示されている。これはデータの永続的な断片を表している。このレイヤにある要素は、ドメイン固有の概念にとってメタクラスとなる。「コンテンツ管理」というビジネスドメインから取られた図５の例では、インスタンスとして考えられるのが記事（"Article"）である。この中間レイヤはドメイン固有モデリング言語として利用できる。この例では、モデル化されたコンテンツ管理システムはオンラインの料理本であり 、レシピ（"Recipes"）と呼ばれる記事を保持している。オンラインのニュースペーパーであれば、広告（"Advertisement"）、ニュース（"NewsItem"） and 社説（"Editorial"）といった記事があることになるだろう（Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004）。
図５ - 存在論的メタモデル階層の例 （Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004）
技術レイヤが最上位にあるのは奇妙に見えるだろう。ほとんどの手法はビジネス的な存在論を最重要とし、技術レイヤを最下位に置くトップダウンの手法をとるからだ。しかしそうすると、図６に示すように技術レイヤにおいて概念が複製されることになる。GitzelとMerz （Gitzel & Merz, How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies, 2004）は実際のコード生成の例においてこのような構造を用いており、さらにこう結論づけている。「コード生成のプロセスにおいて、他の階層の方がよりうまく適合するだろうということが明らかになった。技術レイヤを最下位に導入することで、テンプレート内に多くの複製ができてしまう。つまり、JavaセッションBeanとして実装される各コンセプトは、同じ基本構造を必要としながらも、これらの概念は共通の技術的プロパティを定義するような共通のメタクラスを共有することがないのだ」。したがって、MDE手法においては、技術レイヤを最上位においた存在論的メタモデル階層を用いる方が良いのだ。このレイヤに存在する概念は、前述した通り、プラットフォームに依存しない抽象的な技術的概念を表している。
存在論的メタモデルと言語的メタモデルの階層を組み合わせる
ここまで言語的メタモデル階層と存在論的メタモデル階層の例を見てきた。そしてどちらの次元も完全なモデリング手法にとっては必要なのである。
調整とアクセスが可能なモデルと実行時の型の追加の両方をサポートする基盤は、動的な拡張が可能でなければならない（Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002）。これは、MDEの目標がソフトウェアの成果物が人事や（ビジネスの）要件における変更を越えて生き延びることである点に由来する（ モデル駆動エンジニアリングを参照）。動的な拡張を行うためには、モデリングに使われるドメインの型を動的に拡張できなければならない。さらにここからドメインメタタイプを定義できることも求められる。これはつまり存在論的メタモデリングである。（Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002）。
MDEが持つもう一つの目標（モデル駆動エンジニアリング参照）として触れたものに、短期的な生産性を向上させ、ソフトウェアの成果物が人事、開発環境、デプロイ環境の変更を越えて生き延びることがあるが、これらには相互に交換可能で簡潔なモデルと、ユーザによる定義が可能なマッピングが必要となる。（Atkinson & Kühne, Model-Driven Development: A Metamodeling Foundation, 2002）。これには正式なモデル言語を定義する能力、つまり言語的メタモデリングが必要となる。
したがって、MDEには言語的メタモデリングと存在論的メタモデリングの両方が必要なのだ。これらの手法を組み合わせるにあたり、設計上の可能性がいくつか浮かび上がる。例えば、直線状および非直線状階層の利用、言語的要素およびライブラリ要素としての要素の定義、メタモデル階層における厳格さの定義などである。
直線状階層と非直線状階層
UML（OMG, 2007）においては、ステレオタイプという概念が言語的メタモデリングと存在論的メタモデリングを組み合わせる際のソリューションと考えられる。ステレオタイプは軽量なメタモデル拡張機構である。新しいメタモデルレイヤを導入する代わりに、既存のメタモデルが「タグ付けされた」要素によって拡張され得る。ステレオタイプを利用することには２つのメリットがある。第１にステレオタイプは簡単に利用できる。ユーザは他のメタモデル階層について意識する必要がないからだ（Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004）。第２に、ステレオタイプの概念はCASEツールにおいて実装するのが簡単である。メタモデル自体が拡張可能である必要がなく、ツールの中でハードコーディングできるからだ（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）。しかし、これらのメリットに代償がない訳ではない。AtkinsonとKühneは次のように述べている「新しい分類機構が導入されるだけではなく、（ステレオタイピングは）インスタンス化意味論が元々持っているあいまいさを悪化させる。適切な役割とメタモデリングフレームワークの観点から見た解釈をより一層複雑なものにするのだ」（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）。Duddy（Duddy, 2002）はUMLプロファイルを作成するためのタグ機構は、原始的で実践的ではないとしている。エンタープライズアプリケーションインテグレーション（EAI）プロファイル （OMG, 2004）のような既存のUMLプロファイルは、UMLのメタモデルに加えて独自のメタモデルを使用する。このことから結論できるのは、ステレオタイピングが独自の言語を作成するのに十分ではないということだ。メタモデル階層はメタモデルに関するファーストクラスの拡張をサポートしなければならない。これは新しい語族（ドメイン固有言語）の定義を可能にするためだ。
前述した通り、ステレオタイプを用いた単一の共通メタレイヤという手法がもたらす構造は小さく、ドメイン固有のモデルを定義するには十分ではない。メタモデル階層を利用することにより（つまり複合的メタモデルを利用することにより）、MDEツールのユーザは、拡張をさらに柔軟に行うことができるようになる。アプリケーションをモデル化するにあたり、ドメイン固有のモデリング言語がもたらすメリットを受けながら、カスタマイズされたメタモデルを選択することができるからだ（Gitzel & Korthaus, The Role of Metamodeling in Model-Driven Development, 2004）。複合的メタモデルは異なる階層において整理される。図７では、技術レイヤと言語レイヤ間の言語的インスタンス化を用いて直線状メタモデルを示している。存在論的インスタンス化は他のレイヤ間で使用される。
図７ - 直線状メタモデル階層
深いインスタンス化意味論が用いられた場合、これはあるクラスがそのインスタンスについてのステートメントを作成することができ、それらのインスタンスも順次同様のことができるということを意味するのだが（Gitzel & Hildenbrand, A Taxonomy of Metamodel Hierarchies, 2005）、図８および図９に示すような直交するメタモデル階層に意味論上の違いはない。AtkinsonとKühne（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）によれば、言語的分類と存在論的分類を統合するための鍵は、直交する次元として両者を見ることにあるという。しかし、深いインスタンス化という概念を作り出した後では、直交する階層と深いインスタンス化と組み合わせた直線状階層ではどちらを用いた方が良いのかということには議論の余地があると結論づけている。
図８ - 直交するメタモデル階層
図９ - 直交するメタモデル階層の要素の例
GitzelとHildebrandは（Gitzel & Hildenbrand, A Taxonomy of Metamodel Hierarchies, 2005）、非直線状の階層がもつ表現力のほうが高いと述べている。しかしこれは、深いインスタンス化という概念を無視した場合の話である。
意味論上の違いがないとしても、私は直交する階層の方を使用することをすすめる。こちらがインスタンス化の種類が異なることを強調するからだ。直線状の手法においては、言語的インスタンス化と存在論的インスタンス化が混同されやすい。両者が同一の方向において可視化されるからだ。それに加えて、存在論的階層はレシピがクラスであると同時に記事でもあるということを直接的に示す。直線状の階層においては、レシピがクラスでもあることを理解するために、深いインスタンス化を用いて推測しなければならない。
言語的要素とライブラリ要素
前述した概念に基づいてMDE手法のための言語を定義しようとすると、特定の要素を最上位の存在論的メタモデルとして扱うべきか、あるいは最上位の言語的メタモデルとして扱うべきかという疑問が浮かび上がる。
オブジェクト指向プログラミング言語を見れば、中心的な言語的概念と、ライブラリクラスとの区別も行っているということが分かるだろう。ほとんどのオブジェクト指向言語が採用している戦略は、中心的な言語定義をできる限り小さくし、クラスライブラリの中でできる限り多くの概念を定義するというものだ（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）AtkinsonとKühneによれば、このことは次の点に役立つ。
- 言語定義を小さくシンプルに保つ。
- 相当数の（ライブラリ）概念が再構築されることになっても、仮想マシンを安定した状態に保つ。
- ユーザによる調整を最大限可能にする（ユーザはライブラリを変更ないし拡張するかもしれないが、中心的言語概念は変更できない）。
換言すれば、オブジェクト指向言語が示す教訓が示唆しているのは、言語的インスタンス化は最小限にすべきであり、できる限り多くの概念は存在論的分類階層に位置づけられるべきだということだ。オブジェクト指向言語から学べるものとしては、他にも拡張性という同様のメリットを実現するにはどの基本的な概念については言語的次元で取り組まなければならないかということがある。AtkinsonとKühne（Atkinson & Kühne, Rearchitecting the UML infrastructure, 2002）は、モデル駆動言語定義が取り組むべき概念ないし機構は以下に関係するものだけであるとしている。
厳格なインスタンス化意味論とおおらかなインスタンス化意味論
メタモデル階層について議論する上での最後のポイントは、インスタンス化意味論である。ここでは厳格なメタモデリングとおおらかなメタモデリングとを区別することができる。
厳格なメタモデリングが基づいている信条は、instance-of関係のみがメタレベルの境界を越えられるということ、そして全てのinstance-of関係は、直に接しているレベルに対して１つのメタレベル境界を越えなければならないというものだ（Atkinson & Kühne, Strict Profiles: Why and How, 2000）。これは不必要に複雑なモデリングに見えるが、この厳格な定義が存在しなければ、メタモデル階層という考え方全体が崩壊してしまう。実際には、これが意味しているのはモデル要素の位置はinstance-of階層における位置によって定められず、代わりに他の、明示的に示されることが少ない基準によって定められるということだ（Atkinson & Kühne, Processes and products in a multi-level metamodeling architecture, 2001）。
GitzelとMerz（Gitzel & Merz, How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies, 2004）はメタモデル階層が持つ厳格さのために緩和された定義を提示している。彼らによれば、このおおらかな定義は、メタモデル階層がコード生成に利用される際に役に立つという。概念の複製を避けることができるからだ。しかし、彼らが用いている例はプラットフォームに依存する概念を含んでいる。それも、厳格さの定義を緩める必要がある概念においてである（JDOPersistence）。この理由の一部は、技術レイヤを最下位においたメタモデル階層を利用している点にある（別の存在論的メタモデル階層については前述）。プラットフォームに依存する概念はMDE手法に含まれず、存在論的レイヤの最上位に抽象的な技術的概念を用いることで避けることができるので、厳格さを緩める必要があるという議論の例とは見なせない。
しかし、厳格さを緩めることは、ユーザのためにさらなる柔軟性を可能にする上で実際にとても役に立つと考えられる。厳格な手法においては、あるレイヤにおける各要素は上位のレイヤ（メタレイヤ）において定義されなければならない。メタレイヤが完全ではなく、アプリケーションモデラの必要を満たせなければ、メタレイヤを変更する以外にこの問題を解決する方法はない。しかし、これは常にできることではない。このような状況では、アプリケーションモデラにメタ-メタレベルに基づく概念を定義させるという解決が考えられる。後述する例（図10）でこのような状況が起こるのは、アプリケーションモデラが、ビジネスドメインレイヤで定義されていないアクティビティを定義したいと考えた時である。厳格さを緩めることで、広範的サービスレイヤ（"Pervasive Services Layer"）の概念を使うことができるし、それで不十分ならば、直接BPELの概念を使うことができる（詳細は次節を参照）。
プロセスモデリングの具体例
これまで、モデル、メタモデル、メタモデル階層について解説してきた。言語的メタモデリングと存在論的メタモデリングの両者がモデル駆動エンジニアリングをサポートするモデルには必要だと述べてきた。同様に、オブジェクトモデルのための階層の具体例もいくつか示してきた。これはオブジェクトモデルに対するこの手法がもつ適用性について示してはいるが、MDEのための潜在的可能性を余す所なく示すものではない。プロセスモデルもMDEにおいては重要である。そこで、プロセスモデルのためのメタモデル階層を見ていこう。
BPMN（OMG, 2006）やBPEL4WS（OASIS, 2007）をビジネスプロセスモデリングのための汎用言語として利用することについては、多くの議論がなされている。BPMNは（一般的に）分析やドキュメンテーションのためにビジネスプロセスを定義するために用いられるのに対し、BPEL4WSは実行可能なビジネスプロセスを定義するのに用いられる。モデル駆動エンジニアリングの観点からすれば、BPMNからBPEL4WS（BPELと省略）へのマッピングは、興味深いものであると同時に必要なものでもある。最も包括的な手法が紹介されている文献は（Ouyang, Aalst, Dumas, & Hofstede, 2006）だ。ただし、彼らは構文（構造）変換だけに焦点を絞っているが、実際にはBPMNとBPELのギャップは意味論の観点からするとはるかに大きい。（BPMNとBPELのギャップに関する説明については、（Baeyens, 2008）も参照）。
BrahaとØsterbye（Braha & Østerbye, 2006）は、汎用モデリング言語をビジネスプロセスモデリングに使う際には３つの障害があるとしている。
- 意味論（"Semantics"）。請求書の登録（"RegisterInvoice"）といったカスタマイズしたタスクのための特別な意味論が定義できない。モデラはモデル内のタスクを使用する際に必要なデータを定義することを覚えねばならず、またデータを提供し検証することをサポートするツールも存在しない。変換エンジンは請求書の登録のようなタスクを認識しない。これが一般的なタスクとしてモデル化されるからだ。
- 視覚化（"Visualization"）。モデルについてのカスタマイズされた視覚的表現は存在しない。視覚化が重要なのは、ユーザ、ビジネスアナリスト、アーキテクト、開発者といった別々の人々全員がモデルを理解しなければならないからだ。
- 抽象化（"Abstraction"）ビジネスプロセスは高度な抽象レベルにおいてモデル化されるだろう。請求書の登録といったタスクは、例えばWebサービス呼び出しといったシンプルな実装を持たないかもしれないが、その代わり、実装パターンを持つことはできるだろう。たとえば、３つのWebサービス呼び出しと例外ハンドリングの機構といったようにである。これらの詳細はモデルにとって適切ではないが、実装への変換を可能にするために汎用言語を使う上ではモデル化しなければならない。
これらの問題を解決しているドメイン固有プロセスモデリング手法の例は次の文献にて紹介されている（Braha & Østerbye, 2006）、（Jablonski, Faerber, Götz, Volz, Dornstauder, & Müller, 2006）（Becker, Pfeiffer, & Räckers, 2007）。これらは優れた手法を提示しているが、言語を定義するための正式なメタモデル階層を用いてはおらず、BPMNやBPELのような既存の汎用標準とのつながりについて明確に論じていない。
この記事で提示するメタモデリング手法であれば、ドメイン固有プロセスモデリング手法の定義を形式化し、さらにはドメイン固有プロセスモデリングと汎用プロセスモデリングとのギャップを埋めることもできると考えている。プロセスモデリングのためのメタモデル階層の提案を図10に示す。言語的メタモデルと同様、構文といくつかの基本的な意味論を定義するBPMN仕様も使用することができる。BPMNは合成も可能なアクティビティを定義する。例えば、それらのアクティビティは１つまたはそれ以上の他のアクティビティから構築されることもできるのだ。この概念は存在論的インスタンス化の関係を定義するのに使用することもできる。例えば、ビジネスドメインの概念は１つ以上の広範的サービスから構築される。
図10 - ドメイン固有プロセスモデリングのためのメタモデル階層
BPEL要素は存在論的次元の最上位に位置づけられ、それによって、プラットフォームに依存しない抽象的な技術的概念を定義している。BPEL要素は、BPMN概念によって視覚的に表象される。ドメイン固有概念の定義をシンプルにするため、その他のレイヤはBPELレイヤの下に位置づけられる。それが広範的サービスレイヤである。広範的サービスという概念はOMGによってMDAの中に定義されている（OMG, 2003）。広範的サービスとは広い範囲のプラットフォームで利用できるサービスである。したがって、これらのサービスはプラットフォームに依存しない仕方でモデル化できる。広範的サービスの例としては、ディレクトリサービス、イベントハンドリング、永続化、トランザクション、セキュリティが挙げられる。（Soley, 2000）。Baeyensは（Baeyens, 2008）これに対応するものとして「コンポーネント」と呼ばれる概念を提示した。
広い範囲の広範的サービスが利用可能になることで、BPELの知識がなくてもビジネスドメインレイヤを定義することが可能になる。ビジネスドメインレイヤはドメイン固有プロセス言語を定義することをサポートするため、プロセスのモデリングをドメインエキスパート（ビジネスユーザ）がモデルレイヤにおいて行うことが可能になる。結果として現れるモデルで使用されるドメインの概念が、BPELによって定義されている存在論的インスタンスであるため、（ビジネスドメインの概念から広範的サービスを通じて）それらは直接実行が可能であるか、よく形式化されている。つまり、特定のプラットフォームで直接実行可能なプラットフォームに依存しない定義へと自動的に変換することが可能なのだ！変換の定義は、広範的サービスのレベルで定義されることができる。つまりビジネスドメイン全体のために取っておかれているということだ。
このメタモデル階層におけるインスタンス化の連鎖を図11に示す。これらの要素は概念を明確にするための例に過ぎず、必要な概念を全て表象している訳ではない（ゲートウェイやフローは例では言及されていない）。
図11 - ドメイン固有プロセスモデリングのためのメタモデル階層における要素の例
図11の左側に示されている例を見てみよう。言語的概念はBPMNアクティビティであり、企業が実行する何らかの業務として定義されている（OMG, 2006）。アトミックであることもそうでないこともあり、角が丸い四角で表される。最上位にある存在論的概念はBPEL呼び出しアクティビティ（"BPEL Invoke activity"）だ。表２は呼び出しアクティビティの基本的なプロパティを示している。
| プロパティ | 説明 |
| partnerLink | 呼び出すWebサービスのポイント |
| portType | Webサービスの特定のポートを示す |
| operation | もしくはWebサービス実行時に呼び出されるファンクション |
| inputVariable | 処理のための入力要素 |
| outputVariable | 処理の出力要素 |
表２ - BPEL呼び出しアクティビティのプロパティ
例でモデル化されている広範的サービスはEメール送信（"SendEmail"）アクティビティである。このアクティビティのプロパティは表3において定義されている。
| プロパティ | 説明 |
| ToAddress | Eメールが送信されるアドレス |
| FromAddress | 送信者のEメールアドレス |
| Subject | Eメールの件名 |
| Message | 送信するメッセージ |
| Attachement | Eメールと一緒に送信する添付ファイル（必須ではない） |
表３ - Eメール送信アクティビティのプロパティの例
Eメール送信アクティビティは呼び出しアクティビティのインスタンスであり、表４に示すような呼び出しプロパティとして定義された値を持つ。
| プロパティ | 値 |
| partnerLink | "CommunicationServices" |
| portType | "Email" |
| operation | "sendEmail" |
| inputVariable | Eメール送信アクティビティのプロパティを含むメッセージ： |
| outputVariable | Eメール送信リクエストからの戻りメッセージ |
表４ - Eメール呼び出しプロパティのための値の例
今やEメール送信サービスは、ドメイン固有概念をモデル化するのに使用できる。例においては通知送信（"SendNotification"）アクティビティがモデル化されている。表５に通知送信アクティビティのプロパティを示す。
| プロパティ | 説明 |
| UserId | 通知が送信されるユーザのID |
| Type | 通知タイプ（例えば、エラー、警告、情報など） |
| Message | 通知メッセージ |
表５ - 通知送信アクティビティのプロパティの例
通知送信アクティビティはEメール送信アクティビティの存在論的インスタンスであり、表６に示すようなEメール送信のために定義された値を持つ。ここで、他のモデル階層からの情報が必要となることが分かる。「ユーザ」という概念が使われているのだ。この対象について詳細には立ち入らない。しかし、ドメイン固有言語（DSL）は、他のDSLの概念を使うための、あるいは他のDSLに概念を公開するためのインタフェースを定義しなければいけないという考え方は明確にしておくべきだ。２つのDSLを一緒に使うことでアプリケーションの記述を形成できる。
| プロパティ | 値 |
| ToAddress | \\User[id=UserId]\Email |
| FromAddress | "System" |
| Subject | Type |
| Message | Message |
| Attachement | "" |
表６ - 通知送信が持つEメール送信プロパティ用の値の例
ビジネスドメインレイヤ上の概念が定義されたので、モデリングツールのユーザはプロセスのふるまいをモデル化するのにこの概念（通知送信）を使うことができる。
モデリングツールのユーザによってモデル化された概念（例では品薄通知）を現実に機能させるためにやらなければならないことは、BPELのpertnerlinkの右側に紐づくものを埋めることだけだ。この例の場合であれば、コミュニケーションサービスpertnerlinkへの紐づけが定義されねばならない。変換の定義はこのメタモデル階層を用いることで非常に容易になったのだ。
結論
モデルとは何か、どのような役割をモデルは持ち、それはどう使われるかについて明らかにしてきた。２つの異なるインスタンス化の関係がモデル要素の間には存在すると論じた。それが、言語的インスタンス化と存在論的インスタンス化である。言語的メタモデルはモデルの言語を定義する（ここには、抽象構文、型意味論、静的意味論、動的意味論が含まれる）。存在論的メタモデルはモデルの中で使用できる概念を定義する。存在論的メタモデリングは概念の意味（内在的意味論）を定義するのに用いられ、モデル内の概念について推論することを可能にする。
モデル駆動エンジニアリングの目的に基づき、MDEの方法論は言語的メタモデリングと存在論的メタモデリングの用法を活用しなければならないと結論づけた。これらの手法を組み合わせるにあたり、設計上の可能性がいくつか浮かび上がる。例えば、直線状および非直線状階層の利用、言語的要素およびライブラリ要素としての要素の定義、メタモデル階層における厳格さの定義などである。
直交する階層の方が好ましいと論じたが、これはインスタンス化の種類が異なることを強調するからだ。直線状の手法においては、言語的インスタンス化と存在論的インスタンス化が混同されやすい。両者が同一の方向において可視化されるからだ。それに加えて、存在論的階層はレシピがクラスであると同時に記事でもあるということを直接的に示す。直線状の階層においては、レシピがクラスでもあることを理解するために、深いインスタンス化を用いて推測しなければならない。
オブジェクト指向言語が示す教訓が示唆しているのは、言語的インスタンス化は最小限にすべきであり、できる限り多くの概念は存在論的分類階層に位置づけられるべきだということだ。
厳格さを緩めることは、ユーザのためにさらなる柔軟性を可能にする上で実際にとても役に立つと考えられる。
最後に、プロセスモデリングの例を用いて、私が行ったデザインの決定はドメイン固有言語（DSL）を定義する上で実に強力であることを示した。まず、結果として生じるDSLは動作するソフトウェアに簡単に変換できる。第２に、ここで示した手法により、汎用言語とドメイン固有言語の組み合わせが可能になる。例においては、汎用言語であるBPMNとBPELをDSLを構築するのに利用した。
------------------------------------------------------------
Atkinson, C., & Kühne, T. (2002). Model-Driven Development: A Metamodeling Foundation. IEEE Softw. , 20 (5), 36-41.
Atkinson, C., & Kühne, T. (2001). Processes and products in a multi-level metamodeling architecture. International Journal of Software Engineering and Knowledge Engineering , 11 (6), 761-783.
Atkinson, C., & Kühne, T. (2002). Rearchitecting the UML infrastructure. ACM Transactions on Modeling and Computer Simulation , 12 (4), 290-321.
Atkinson, C., & Kühne, T. (2000). Strict Profiles: Why and How. Proceedings of the Third International Conference on the Unified Modeling Language, Lecture Notes in Computer Science, vol. 1939, (pp. 309-322).
Baeyens, T. (2008, 02 04). Process Component Models: The Next Generation In Workflow?Opgeroepen op 04 03, 2008, van InfoQ: http://www.infoq.com/articles/process-component-models
Becker, J., Pfeiffer, D., & Räckers, M. (2007). Domain Specific Process Modelling in Public Administrations - The PICTURE-Approach. In M. Wimmer, H. Scholl, & A. Grönlund, EGOV 2007, LNCS 4656 (pp. 86-79). Heidelberg: Springer-Verlag.
Bézivin, J. (2004). In Search of a Basic Principle for Model Driven Engineering. UPGRADE , Vol. V (No. 2), 21-24.
Bézivin, J., & Gerbé, O. (2001). Towards a Precise Definition of the OMG/MDA Framework. Proceedings of Automated Software Engineering, ASE'2001. San Diego.
Braha, S., & Østerbye, K. (2006). Business Process Modeling: Defining Domain Specific Modeling Languages by Use of UML Profiles. In A. Rensink, & J. Warmer, ECMDA-FA 2006, LNCS 4066 (pp. 241-255). Heidelberg: Springer-Verlag.
Chandrasekaran, B., Josephson, B., & Benjamins, J. (1999). What are ontologies, and why do we need them?IEEE Intelligent Systems , 14 (1), 20-26.
Devedzic, V. (2002). Understanding Ontological Engineering. Communications of the ACM , Vol. 45 (No. 4), 136-144.
Duddy, K. (2002). UML2 must enable a family of languages. Communications of the ACM , Volume 45 (Issue 11), 73-75.
Geisler, R., Klar, M., & Pons, C. (1998). Dimensions and Dichotomy in Metamodeling. Proceedings of the Third BCS-FACS Northern Formal Methods Workshop. New York: Springer-Verlag.
Gitzel, R., & Hildenbrand, T. (2005). A Taxonomy of Metamodel Hierarchies. Mannheim: Research Report, department of IS.
Gitzel, R., & Korthaus, A. (2004). The Role of Metamodeling in Model-Driven Development. Proceeedings of the 8th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI2004). Orlando, USA: International Institute of Informatics and Systemics (IIIS).
Gitzel, R., & Merz, M. (2004). How a Relaxation of the Strictness Definition Can Benefit MDD Approaches With Meta Model Hierarchies. Proceedings of the 8th World Multi-Conference on Systemics, Cybernetics and Informatics (SCI2004) (pp. 62-67). Orlando, USA: International Institute of Informatics and Systemics (IIIS).
Jablonski, S., Faerber, M., Götz, M., Volz, B., Dornstauder, S., & Müller, S. (2006). Configurable Execution Environments for Medical Processes. Fourth International Conference on Business Process Management (BPM).
Karagiannis, D., & Höfferer, P. (2006). Metamodels in action: an overview. Filipe, J., Shishkov, B. and Helfert, M. eds. ICSOFT 2006 - First International Conference on Software and Data Technologies. Setúbal: Insticc Press.
Kühne, T. (2006). Matters of (meta-) modeling. Softw. Syst. Model. , 5 (4), 369-385.
Ludewig, J. (2003). Models in software engineering - an introduction. Softw Syst Model , 2 (1), 5-14.
OASIS. (2007). Web Services Business Process Execution Language Version 2.0.
OMG. (2006). Business Process Modeling Notation (BPMN) Specification v. 1.0. OMG Final Adopted Specification, Document Number dtc/06-02-01.
OMG. (2003, 06 12). MDA Guide Version 1.0.1. Retrieved from Object Management Group: http://www.omg.org/mda
OMG. (2007). OMG Unified Modeling Language (OMG UML), Infrastructure, V2.1.2. OMG Document Number: formal/2007-11-04.
OMG. (2004). UML Profile and Interchange Models for Enterprise Application Integration (EAI) Specification. OMG Formal Specification, Document number: formal/04-03-26.
Ouyang, C., Aalst, W. M., Dumas, M., & Hofstede, A. H. (2006). Translating BPMN to BPEL. Technical Report, BPM Center Report BPM-06-02.
Seidewitz, E. (2003). What models mean. IEEE Softw. , 20 (5), 26-32.
Soley, R. (2000, 11 27). Model Driven Architecture. Opgehaald van Object Management Group: http://www.omg.org/mda
Stachowiak, H. (1973). Allgemeine Modelltheorie. Wien: Springer.
