構造化/クラス指向/オブジェクト指向/サービス指向Map Methods to the Abstraction Plane

先日のとある雑談のまとめ。その２。

前回の抽象化の基本２軸と照らし合わせながら
ソフトウェアの設計手法について、少し考えてみます。

1. フローチャート
2. 構造化設計/構造化プログラミング
3. クラス指向
4. オブジェクト指向
5. サービス指向

1. フローチャート
　「フロー」という名前の通り、
　動的な振る舞いを記述する手法です。
　条件分岐や繰り返し等もありますが、
　基本的に上から下に流れる１本道です。
　小さなバッチ処理であれば、これで十分ですが、
　構造の記述が容易ではないため　(つまり設計者に構造について考えることを促さないため)

　ソフトウェアの規模が少し大きくなると、
　使い辛い手法になってしまいます。

2. 構造化設計/構造化プログラミング
　階層的に抽象化されたプログラムの組み合わせとして
　プログラミングを記述する手法です。
　簡単に言えば「本の目次」のように
　プログラムを設計/実装することです。
　鳥の目から虫の目に段階的に変化していくということです。
　但し、「本の目次」であるため、前から順に読んでいくという
　フロー(=振る舞い)の記述も含んでいますが、
　１本道であるという点ではフローチャートと変わりません。

3. クラス指向
　さしあったって、クラス指向では
　　構造化プログラミングでの構造化を助けるために、
　　クラスという枠組み(箱)を提供している
　と考えれば良いでしょう。
　オブジェクト指向言語を導入したバッチプログラムで、
　よく見かける形態です。

4. オブジェクト指向
　バッチ処理の場合、振る舞いはほとんど１本道のため
　設計上は余り問題にはなりませんが、
　ユーザー対話型のイベントドリブン処理の場合、そうはいきません。
　様々な状態での様々なイベントに対して、
　適切な振る舞いを提供するというのが、
　大きな設計課題となります。
　そこで、構造とともに振る舞いをモデル化する
　オブジェクト指向設計が、もてはやされているわけです。
　とはいえ、イベントドリブン処理といえども
　一度振る舞いが決定されれれば、
　そこから先は(比較的短い)１本道です。
　構造化が重要なことに変わりはありません。

5. サービス指向
　鳥の目で、静的な構造を決定するときの手法の一つです。
　業務全体を鳥の目で見て、業務上の一処理を基本粒度として
　ソフトウェア群を構造化するという手法です。
　ソフトウェアの大規模化とクラウドコンピューティングの台頭により
　全体の構造がどうあるべきかということが、
　昨今のホットな話題になっているのでしょう。

ということで、雑談のまとめはこれで終わりです。