設計と抽象化The 2 Axises for Abstraction

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

そもそも(ソフトウェアの)設計とは何でしょうか？
広辞苑によれば、設計とは

　　…或る製作・工事などに当たり、その目的に則して、
　　工費、敷地、材料および構造上の諸点などの計画を立て
　　図面その他の方式で明示すること。…

とのことです。
「その目的」とは、何らかの問題解決でしょう。
「図面その他の方式」とは、実物を作るのではなく、
モデルを作るということでしょう。
「設計」のインスタンスが「実装」という考えです。
そこで、ここでは設計を
　「問題を解決する解(案)のモデルを作ること」
と定義して、
少し考えてみることにします。

1. 解(案)
2. 抽象化
3. 解はどこから来るのか？

1. 解(案)
　「解」ではなく「解(案)」としたのは、
　実際に作ってみるまでは、それでうまくいくのか
　わからないことも多いからです。
　なお、問題にはいくつもの説明が可能であり、
　そのため、解もいくつでも存在しえます。
　もちろん、解の良し悪しはありますが、
　最終的にはそれも価値判断でしかありません。

2. 抽象化
　実物を作るのではなくモデルを作るということは、
　抽象化するということです。
　抽象化とは、思考方法の一種で、
　　対象から注目すべき要素を重点的に抽出し、他は捨て去る方法
　です。
　そこで、何に着目し、何を捨てるかが問題になります。
　決まった答えはありませんが、ソフトウェア設計に限らず、
　抽象化に以下の２つの軸が広く使用されています。

　(1)鳥の目 <-> 虫の目
　(2)静的 <-> 動的

　(1)鳥の目 <-> 虫の目
　　鳥の目は、全体像に着目し、細部を捨て去ります。
　　虫の目は、細部に着目し、全体像を捨て去ります。
　　巨視的／微視的、マクロ／ミクロ、等呼び方は色々です。

　(2)静的 <-> 動的
　　静的な視点は、構造に着目し、振る舞いを捨て去ります。
　　動的な視点は、振る舞いに着目し、構造を捨て去ります。
　　データ構造とアルゴリズム、と言った方が判りが良いかもしれません。
　　会計でのストック／フロー分析も同じ手法です。

3. 解はどこから来るのか？
　これが一番問題なのですが、
　設計解を得るプロセスは明確ではなく、
　設計者の思いつきや閃きといっても過言ではありません。
　とはいえ、ゼロからでは思いつきや閃きは生まれません。

　設計中は、虫の目 <-> 鳥の目  静的<->動的 を
　行ったり来たりしならが、
　知識と経験を基にしたパターンマッチングや
　演繹／帰納／アブダクションを行っているのだと思います。

ということで、続きはまた明日。