MindmapModelingと集合知(3) - 日本語とモデルとプログラム

「MindmapModelingと集合知」では、日本語(自然言語)、モデル、プログラムの関係として以下の図を導入しました。

理想的には、日本語の世界とモデルとプログラムが完全に一致することで、日本語の仕様書を書けばそのままプログラムとして動作するというものです。もちろん、これはSFの世界になってしまい現実的ではありません。そこで、日本語、モデル、プログラムのそれぞれが部分的に重なり図のようになるわけです。

これらの重なりに対してマインドマップモデリングやSimpleModelingで、それぞれの重なりに対してどのように対処しようとしているのか説明します。

日本語の世界とモデル

日本語の世界とモデルとの共通部をつくり、これを大きくしていくことが最初の段階になります。

もちろん、自由奔放に書いた日本語の文章がモデルに変換できるわけではありません。モデルを一定の規則に則って日本語で記述するアプローチを取ります。

このために導入したのが、「MindmapModelingと集合知(2) - ユビキタス言語」で説明したマインドマップモデリングの「登場人物 (actor)」、「道具 (resource)」、「出来事 (event)」といったモデル上の役割です。マインドマップモデリングでは演劇のメタファで、こういったモデル上の役割を規定しており、これらのメタファ上でマインドマップを記述していくことで、自然にオブジェクト・モデルと相互運用できるモデルを記述できるようにしています。

マインドマップモデリングは、文書とモデルの折衷案という切り口でもありますが、この手法を洗練させ文書よりに持ってくることで、日本語の世界とモデルの共通部分をより大きくすることができるかもしれません。

モデルとプログラム

プログラムとモデルを一致させることができれば、プログラムを書くこととモデルを作ることはイコールになります。

もちろん、現時点で完全にプログラムとクラスをマッピングさせることはできませんが、静的構造に関してはほぼ100%マッピングすることが可能なので、静的構造を軸にモデルとプログラムの一元化を考えていくことになります。

モデルとして静的構造のみを扱うのであれば、Javaクラスにアノテーションやコメントでモデル上の情報や日本語による仕様を記述していくというアプローチでも十分に機能するでしょう。

しかし、振舞いをスコープに入れるとこの前提が崩れてきます。

「オブジェクト・モデリングのボトルネック」で取り上げた通り、オブジェクトモデリングでは静的構造モデルと状態機械モデルの実装技術は確立していますが、協調モデルの実装技術が未完成のため、ここは手作業でやらざるを得なくなっているからです。

関数型言語、論理型言語の導入でこの垣根は徐々に下がっていく事になるでしょうが、現時点ではうまく連携できないという前提で考えておくのが無難です。

しかし、協調モデルはユースケース技術による「物語」を使ったシナリオ分析によって、要求モデル、振舞いの外部仕様、静的構造モデルを結びつける技術が確立してます。この「物語」の部分はまさに「日本語」を使ったモデルなので、日本語による記述との親和性が高くなっています。

以上の点を踏まえて、マインドマップモデリングでは「物語」を「脚本」を通して「登場人物」や「道具」といった静的構造に結びつけるメカニズムを提供しています。モデルとプログラムの重なりで欠落する振舞いの部分、つまり協調モデルは「日本語の世界とモデル」の技術を適用することで、緩和できるわけです。

そういう意味でも、日本語の世界、モデル、プログラムを統合的に扱うアプローチは有効ではないかと考えています。

日本語の世界とモデルとプログラム

ソフトウェア開発での論点の一つは、プログラムに落とし込めない日本語で書いた仕様をいかにプログラムとリンクした形で維持していくのかという点にあります。

その解決策としてオブジェクトモデリングの王道であるユビキタス言語をハブとして、モデル化できないゆるい日本語の情報をモデルに結びつけるという手法が考えられます。さらに、ユビキタス言語からモデルやプログラムの重ならない部分もリンクしていくということもできるでしょう。

ユビキタス言語は、日本語の文書かつモデルでプログラムの自動生成付き、という形になるでしょう。マインドマップモデリングを入り口に、こういった技術へのアプローチを考えています。