井上 研一 オブジェクト指向分析・設計（OOAD）講座の第5回です。
今回で最終回。ここまでの分析の成果を設計・実装につなげていきましょう。
Diorama d’usine à l’ancienne / zigazou76
5回の連載にずっと登場してきた工場のジオラマ。
オブジェクト指向でのソフトウェア開発は、エンジニアが創造主となって、コンピュータの中に小宇宙を作るプロセスです。だから、ジオラマ作りと一緒なんですね。
オブジェクト指向分析では、ジオラマから遠ざかって全体を眺めたり、顔を寄せて一部をじっくり眺めたりする、色々な視点からの観察が大切です。
上空数千メートルからの飛行機の視点とか、数十メートル程度の鳥の視点とか言ったりもします。
MVC Model2
この連載を始めるきっかけとなったTech Garden Schoolのプログラミング講座では、CakePHPを使っています。そこでは、口が酸っぱくなるほどMVCモデルだ！という話がされていると思います。CakePHPなどのWebフレームワークが採用するのは、厳密にはMVC Model2と言われるものなのですが、下図のような構造ですね。
MVCモデルは、Model、Controller、View（CakePHPではctpファイル）の3つのオブジェクトタイプで構成されます。
ところで、前回詳しく説明したロバストネス図に登場したのは、エンティティ、コントロール、バウンダリの3つでした（これをBCEモデルと言ったりもします）。どちらも3つですから、このように紐付くのだと言って良いでしょうか。
Model ＝ エンティティ
Controller ＝ コントロール
View ＝ バウンダリ
そのような考察が働くのは良いことですが、ただ、これは正解ではありません。
MVCモデルとBCEモデルでは、分析の理由が異なるので、担当範囲が一致するわけではないのです。MVCモデルは実装のためのモデル、BCEモデルは設計のためのモデルと言えば良いでしょうか。
MVCとBCEを正しくマッピングする
MVCとBCEの正しいマッピングは、上図のようなものです。
Model ＝ エンティティとコントロールの一部
Controller ＝ コントロールの一部とバウンダリの一部
View ＝ バウンダリの一部
MVCのControllerは、前画面からのリクエストからパラメータを受け取ってModelに渡したり、Modelから受け取った値を次画面を作るためにViewに渡したりします。
BCEのバウンダリは、アクターとシステムの境界にあるオブジェクトですから、画面はまさにバウンダリですが、ここには画面を作る処理も当然に内包されています。よって、MVCのControllerがやるべきことも、バウンダリには含まれていると言えます。
一方、BCEのコントロールは画面を作るために必要なロジックやビジネスロジックですが、特にビジネスロジックはMVCのModelで実装した方が良いことです。よって、コントロールの一部はMVCのControllerで実現されますが、Modelでも実現されることになります。
（ビジネスロジックをMVCのControllerで実装することも多いのですが、Controllerは画面とも密接に紐付いているので、画面の変更がビジネスロジックのコードに影響したり、同一のビジネスロジックを用いる画面が複数あった場合にそれぞれのControllerに同じコードが書かれることになるため、推奨されません。）
ドメインモデル（分析モデル）を設計モデルへ
ロバストネス図とMVCモデルのマッピングが分かったところで、早速、実装に向けて設計を進めていきましょう。
先に示した「記事を投稿する」ユースケースのロバストネス図から、静的側面の分析で作成したクラス図（ドメインモデル）の一部を洗練させ、設計モデルにしてみました。
「投稿者」、「記事」、「カテゴリ」の3つのクラスは、ドメインモデルに登場したクラスであり、ロバストネス図ではエンティティでした。これは、MVCモデルではModelとして実装されます。
記事モデルには3つのメソッド（クラスの一番下にある区画）、カテゴリモデルには1つのメソッドが追加されています。これは、ロバストネス図のコントロールが転化したものです。先に示したロバストネス図にある3つのコントロールは、すべてModelのメソッドとなりました。（「記事に投稿者をセットする」は、ロバストネス図で漏れていたので追加しました。）
記事Controllerは、設計モデルで初めて追加されたクラスです。ControllerクラスはあくまでWebシステムを作るため（それをCakePHPで作るため）に必要になったクラスなので、ビジネス（システム化対象領域）自体の分析であるドメインモデルには登場しないので、ここで追加するのです。
CakePHPのControllerは、原則として1Model：1Controllerの関係で作り、そのModelを操作する画面を集めるので、ここでは「記事Controller」が登場します。また、そのControllerの配下にある画面や機能の単位でメソッドを作るので、ここでは「記事投稿画面の表示」と「記事の投稿」の2つをメソッドとして追加しました。（ロバストネス分析で登場した「記事投稿画面」と記事投稿画面に含まれる「投稿ボタン」という2つのバウンダリに関連付いていることに注目してください。）
ControllerとModelの間に引かれている点線の矢印は、クラス間の依存関係があることを示します。例えば、記事Controllerは「記事投稿画面の表示」や「記事の投稿」のために、「投稿者」、「記事」、「カテゴリ」の3つのModelクラスを使う関係にあるということです。
まとめ
どうにかここまで来れば、CakePHPなどのWebフレームワークでの実装を始められそうな段階になったのではないかと思います。
ブログシステムで記事を投稿するだけという、簡単なように思える機能のために、ここまでの分析・設計が必要なのか！と感じたかもしれません。ただ、これは簡単な機能を、さらに簡略化した上で例示しているのでそう感じるだけで、実際に作りたいサービス、システムはもっと複雑でしょう。ならば、やはり必要なことなのです。
「エリック・エヴァンスのドメイン駆動設計」というオブジェクト指向分析・設計に関する名著がありますが、その序文にこのようなことが書いてあります。
ソフトウェア開発を複雑にする要因は数多く存在する。しかし、この複雑さの核心にあるのは、問題ドメイン自体が本質的に複雑であるという事実だ。人間の行う入り組んだ仕事を何らかのかたちで自動化しようとすれば、ソフトウェアはそこにある複雑さを避けて通ることはできない。できるのは、コントロールすることだけだ。
この文章は、さらに「複雑さをコントロールする秘訣は、優れたドメインモデルにある」と続くのですが、私がこの連載やTech Garden Schoolでの講義でお伝えしたかったのは、まさにこのことなのです。
ソフトウェアが取り扱うサービス、ビジネスは、それが起業や経営変革につながるほど重要なもので、おそらく複雑なものです。その複雑さに立ち向かい、その重要事項を成功に導くために、分析・設計の重要さを強調して、し過ぎることはないと考えます。
＜参考文献＞
