プログラマの思索

先日の大阪DDD勉強会に刺激を受けて、「ユースケース駆動開発実践ガイド」と「オブジェクト開発の神髄」と「アジャイルソフトウェア開発の奥義」「実践UML」を読み直している。
ラフなメモ書き。

【元ネタ】
【限定募集：第1回の申込者のみ、参加登録可能】第２回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

【１】個人的には、オブジェクト指向設計という考え方は好き。
データモデリングはDB設計でも業務の設計でも必須だが、データだけではシステムは動かない。プログラムも作る必要があるけれど、DOAにこだわると、なぜかソースの自動生成に走ってしまうように思える。

オブジェクト指向設計は、アジャイル開発と相性がよい。
また、開発チームの構造解析にもオブジェクト指向設計にある責任駆動の考え方をそのまま適用できる。
つまり、プログラミング志向だし、開発プロセスを実装する時にもオブジェクト指向設計の発想を応用できる利点がある。

また、UMLというモデリング記法も個人的には好き。
一つのモデルを静的な側面、動的な側面から複数の観点で表現できるので、モデルを徹底的に分析したい時に使える。
いわゆる４＋１ビュー。

UMLがデータモデリングよりも使いやすいと思う点は、モデルの動的側面を複数のダイアグラムで表現できることだ。
僕は、Redmineのワークフローにソフトウェア開発プロセスを実装する時に、ひとつの業務をastahを使って、アクティビティ図とステートチャート図、シーケンス図を描いている。
すると、誰がどんなタスクをして誰に渡すのか、自分が持っているタスクはどんなステータスなのか、が分かってくる。
そして描きながら、冗長なタスクやステータスを削除したりして、ワークフローを洗練させていく。

一つのモデルを複数の観点で徹底的に分析する時に、UMLは重宝する。

【２】今までオブジェクト指向設計の本はたくさん読んできた。
オブジェクト指向設計には4つの流派があるように思える。

【２－１】クラス図を重視する。

いわゆる「概念モデル」「ドメインモデル」と呼ばれるクラス図。
業務分析レベルの粗いクラス図。
ER図に近い。

「ドメイン駆動設計」では、ドメインを表すクラスが実装可能なクラスと一致するため、ドメインエキスパートと開発者が指すクラスは一致する。
すなわちユビキタス言語になっている。

実装モデルレベルのクラス設計のプラクティスとしては、下記が挙げられている。
「プログラマのためのJava設計ベストプラクティス」「アジャイルソフトウェア開発の奥義」でも紹介されている。

・単一責任の原則(SRP:The Single Responsibility Principle)
・オープン・クローズドの原則(OCP:The Open Closed Principle)
・リスコフの置換原則(LSP:The Liskov Substitution Principle)
・依存関係逆転の原則(DIP:The Dependency Inversion Principle)
・インタフェース分離の原則(ISP:The Interface Segregation Principle)

第２回【IT技術系コラム】オブジェクト指向設計原則－(1)クラス設計に関する原則｜ウェブコラム｜プライマル株式会社

【２－２】ロバストネス図を重視する。

「ユースケース駆動開発実践ガイド」が有名。
ユースケース→ロバストネス図→シーケンス図に詳細化する過程で、要件からプログラムへ変換していく。

ロバストネス図は「ユースケースをオブジェクトの絵として表現したダイアグラム」。
ユースケースという要件分析と、シーケンス図という詳細設計の間のギャップを埋めるダイアグラムがロバストネス図。

UMLを描こう - Vol.5 ICONIXロバストネス図 : アシアルブログ

UMLを描こう - Vol.6 ロバストネス図からシーケンス図を描く : アシアルブログ

ロバストネス図の利点は、手書きで書きやすいこと。
そして、バウンダリがシステムの外部I/Fに対応するように書けるので、システム間連携も表現しやすい。

「ユースケース駆動開発実践ガイド」は、EnterpriseArchitectというモデリングツールと一体化した開発プロセスとして、ICONIXプロセスが紹介されている。

個人的には、ロバストネス図は好き。
ホワイトボードの手書きの図で、画面設計やバッチ設計もロバストネス図で表現できる。
設計者が開発者に、設計の意図を伝える時に使えると思う。

ロバストネス図は素晴らしい - 檜山正幸のキマイラ飼育記

【２－３】コンポーネント図を重視する。

「オブジェクト開発の神髄」「アジャイルソフトウェア開発の奥義」が有名。
「オブジェクト開発の神髄」では、コンポーネント図はシステムのアーキテクチャを示すダイアグラムになる。

コンポーネント図は、そのコンポーネントのインターフェイスをモデリングしたダイアグラム。
コンポーネント図はアーキテクチャレベルの成果物である。

ここで、コンポーネントは何か？
実際は、DLLやJar、Exeなどのバイナリの部品に相当する。
外部へのI/Fは公開されているが、その中身は隠蔽されている。

コンポーネント設計は、大規模システムにおいて、数多くの共通部品を再利用できるように使い回すためにとても重要。
インターフェイスが公開されることで、中身は空実装でも、インターフェイスを利用する他チームはモックオブジェクトとして代用して、開発を先に進めることができる。

コンポーネント設計のベストプラクティスとしては、「オブジェクト開発の神髄」では「コンポーネントの設計原則」、「アジャイルソフトウェア開発の奥義」では「パッケージ凝縮度に関する原則」「パッケージ結合度に関する原則」として、６つの原則が挙げられている。

・再利用・リリース等価の原則（REP:Reuse-Release Equivalency Principle）
・全再利用の原則（CRP:Common Reuse Principle）
・閉鎖性共通の原則（CCP:Common Closure Principle）

・非循環依存関係の原則（ADP:Acyclic Dependencies Principle）
・安定依存の原則（SDP:Stable Dependencies Principle）
・安定度・抽象度等価の原則（SAP:Stable Absstractions Principle）

随分昔の話だが、Javaプログラムで、複数のJarをキックする時に、クラスパスのJarファイルの順番を入れ替えると正常動作しなくなる時があった。
その原因は、Jarに依存関係があったために、Jarを読み込む順序に依存していたからだ。
つまり、非循環依存関係の原則に反していたのだろうと想像する。

パッケージ設計の原則 - Strategic Choice

オブジェクト指向設計の原則 - パッケージ設計の原則 - brfrn169の日記

第３回【IT技術系コラム】オブジェクト指向設計原則－(2)パッケージ凝縮度に関する原則｜ウェブコラム｜プライマル株式会社

第４回【IT技術系コラム】オブジェクト指向設計原則－(3)パッケージ結合度に関する原則｜ウェブコラム｜プライマル株式会社

【２－４】コラボレーション図（UML2.0ではコミュニケーション図）を重視する。

「実践UML」が有名。
コラボレーション図は、オブジェクト同士の相互作用を表した図。
シーケンス図と同等。

コラボレーション図がオブジェクト指向設計で最も重要なダイアグラムであるという主張の理由は、クラスに責務を割り当て、オブジェクトの協調を設計することが重要であると認識させてくれるから。
つまり、クラス設計で最も重要な責務駆動設計を実践できるから。

駄目なクラス設計の例として、太ったクラス(Fat Class)というアンチパターンがある。
太ったクラスは数多くのメソッドや属性を持ち、他のクラスと関係していて、複雑なソースになっている状況。
普通は、太ったクラスは「メソッドの抽出」「メソッドの移動」「インターフェイスの抽出」「メソッドの引き上げ」「クラスの移動」などでリファクタリングして、スマートなクラスにする。

僕がオブジェクト指向設計に初めて触れた時、RUPを教える先生から「実践UML」が最もオブジェクト指向設計らしい書籍であると教わった記憶がある。
「実践UML」も初版から第３版まで長く出版されたから、愛された書籍だったのだろう。

【３】クラス図、ロバストネス図、コンポーネント図、コミュニケーション図のいずれも、どれがオブジェクト指向設計として正しいわけではないけれど、どの流派にもそれなりの理由があり、その考え方が面白い。

クラス設計のベストプラクティスはC++の頃から有名だった。

コミュニケーション図を使う人は、CRCカードやクラス設計が好きな人には有用だろう。
責務という処理をどのクラスに割り当てるべきか、という責任駆動設計を考える時に使えるから。
ただし、シーケンス図でも代用できる。

パッケージの凝集度・結合度のベストプラクティスは、コンポーネント設計に今でも使える。
今なら、リリース対象のモジュールであるWar、Ear、Jar、Exe、DLLをどんな粒度で、どんなインターフェイスで作るべきか、という指針として使えるだろう。

ロバストネス図は、ユースケースをラフな絵として描く時に使える。
画面設計、バッチ設計で、画面や処理を通じて、オブジェクトがどのように協調されるのか、がラフな絵を通じて分かる。

「ドメイン駆動設計」を読んでいると、過去のオブジェクト指向設計のベストプラクティスを全て踏まえた上で、得られたノウハウをうまく蒸留している気がする。
同じような概念なのに、別の名前を付与して、新たな意味を付与している気がする。
その観点を持ちながら「ドメイン駆動設計」を読み直そうと思う。