はじめに
ある程度以上の規模/複雑さを持つ対象をモデリングする際に、私はよく「概念モデル」「分析モデル」「設計モデル」という抽象度の異なる三種類のモデルのセットを作成します。(注１)
表 1 抽象度の異なる三種類のモデル
| モデルの種類 | 概 要 |
| 概念モデル | 問題領域に対する「理解のしやすさ」を重視したモデル。 実現手段の詳細によらない、問題領域の本質的な構造/特性を素直に表現したもの。 |
| 分析モデル | 概念モデルをベースに、抽象化/一般化を加えてドメイン・フレームワークを分離/再構成したモデル。より広い範囲での再利用性/拡張性の向上を狙う。 |
| 設計モデル | 分析モデルをベースに、特定のアーキテクチャ/ライブラリ/プログラミング言語等を想定して具体的な実現手段を組み込んで詳細化したモデル。 |
前回の記事では概念モデルのイメージについて解説しました。引き続いてGreedゲームを題材にしながら、今回は「分析モデル」のイメージと効果を解説していきます。
ドメイン・フレームワークの考え方
本記事におけるドメイン・フレームワークとは、ある特定の問題領域およびそれに類似した問題領域に共通して適用可能なドメイン・オブジェクト群のためのフレームワークの事を指します。よく見かける汎用的なメカニズム向けのフレームワーク(たとえば、UI制御用フレームワーク、データの永続化機構、分散環境でのメッセージ伝搬機構など)とは異なり、ドメイン・フレームワークは特定の問題領域毎に特有の構造/振る舞い/意図を持って構成されます。
ドメイン・フレームワークを考える場合、現在対象としているシステムそのものだけでなく、将来作られる可能性のある類似のシステムに関する想定を組み合わせ、それらのシステム群にとって共通に流用可能な部分を枠組みとして抽出/整理していきます。その際、現在対象としているシステムの概念モデルをベースに、一部を分解したり抽象化/一般化を加えたりなど変形を行い、適用範囲の広い枠組みの部分(ドメイン・フレームワーク)を抜き出し、さらに、いくつかのサブクラスを追加するなどして現在対象としているシステムのドメイン構造と同等な機能を持つ構成をその枠組の構造を使用して再構築していきます。
ドメイン・フレームワークの例
図 1 にGreedゲームの概念モデルを参考に主要な概念を整理し、Greedゲーム以外の類似のゲームも想定しながら抽象化/一般化を加えて変形しつつ、それらのゲーム群で共通に成り立つと思われる枠組み(ゲーム・フレームワーク)の部分を抜き出した概略クラス図を示します。
図1 ゲーム・フレームワークの例
この枠組はGreedゲームを含む複数プレイヤー参加の一般的な対戦型ゲームに共通すると思われる部分を表わしています。いくつかのクラスが抽象クラス(クラス名がイタリック体で表記されている)になっていることに注意してください。この枠組では、ゲームを「ある局面の順序付けされた階層構造」として認識しています。ゲームを構成する局面の種類や階層順などは具体的なゲームの種類によって変わってきます。そのため、「ゲーム局面」「複合ゲーム局面」「単純ゲーム局面」によって構成されるコンポジット・パターンで局面を抽象化し、任意種類/任意深さの局面の木構造を扱えるようにしています。この枠組は「ラウンド」「ターン」「手」「番」などの概念を持つさまざまなゲームに対して応用可能なはずです(すごろく、ポーカー、ボーリング、ビリヤード、将棋、麻雀、テニス、バレーボール、野球、などなど…)。
ドメイン・フレームワークの特殊化
抽象化/一般化されたフレームワーク層が分離/抽出されたので、今度はその枠組を用いて現在対象としているシステムの構造を再構成して表現していきます。ゲーム・フレームワークを特殊化する形で再構成したGreedゲームのモデル(分析モデル)の概略構造を 図 2 に示します。
図 2 Greedゲームの分析モデルの例 ※クリックして拡大表示
この図の中では、フレームワーク側で定義されているクラス名に「ゲーム・フレームワーク」というパッケージ名を付けて表記しています。つまり、「ゲーム・フレームワーク」というパッケージ名が表示されていないクラスはGreedゲームのために特殊化された具象クラス群であることを示しています(さらに、Greedゲーム用に特殊化されたクラス群のアイコンは、塗りつぶし色を少し濃いめの色にしてあります)。また、フレームワーク側で定義されていなかった関係線は赤色で表示して、どこが追加されたものかが目立つようにしています。
前回の記事で示したGreedゲームの概念モデルの例と上記の分析モデルの例とを見比べてみてください。できれば、両方のクラス図からそれぞれオブジェクト図を描いてみて、同等の構造を持つオブジェクト群が矛盾なく扱えることを確認してみると、さらに理解が深まるものと思います。
分析モデルの利点・欠点
Greedゲームの分析モデルでは、Greedゲームに限らず他のゲームにも適用可能な部分(ドメイン・フレームワーク部分)とGreedゲーム固有の都合に左右される具象部分とが、モジュール(クラス)としても明確に分離/整理されています。そのため、このようなモデルをベースに設計/実装されるソース・コードのうち、少なくともドメイン・フレームワーク部分については他のゲームを実装する場合にもそのまま再利用できる可能性が高くなります。まとめ方(抽象化や一般化の方法)を工夫してなるべく多くの部分をドメイン・フレームワークとして抽出できれば、それだけ再利用率を上げることができるでしょう。
一方で、抽象化/一般化による変形/分離が施された分析モデルはある意味「素直な構造」ではなくなっているので、「問題領域の構造/特性を理解する」という目的にはあまり向いていない(理解するのが難しい)モデルになります。たとえば、図 2 に示した分析モデルだけを見て、Greedゲームが「ゲーム」「ラウンド」「ターン」「ロール」の階層構造を持つということをパッと読み切るのは困難です。ドメイン・フレームワーク化はドメイン・レベルでの再利用性/拡張性を確保するために必要なのですが、抽象化/一般化と理解のしやすさはトレードオフの関係にあります。新たにモデルを見る人がそもそもの問題領域を素直に理解できるように、分析モデルの元になった概念モデルも対にして残しておく(抽象度の異なる目的別のモデルを作成する)のが良いでしょう。
第3回につづく
| (注１) | 「概念モデル」「分析モデル」「設計モデル」という用語には明確な定義が無く、人によってさまざまな意味合いで使われています。本記事でのこれらの用語の解釈/用法は著者独自のものであり、一般的に広く認識が統一されているものではないということにご注意ください。 |
関連情報：
- 豆蔵ソフト工学ラボ：誤解しがちなモデリングの技：
http://labo.mamezou.com/special/sp_002/ - 豆蔵ソフト工学ラボ：組込み開発のためのモデリングワンポイントレッスン
http://labo.mamezou.com/special/sp_006/ - 豆蔵ソフト工学ラボ：システム開発地図：
http://labo.mamezou.com/special/sp_015/