要求分析とプログラミングの間には設計という段階があります。 その過程で記述される仕様は、顧客の視点から実装の視点へ質的な転換が行われます。
仕様書を作る 2 つの目的。
後者は見落とされがちですが重要です。 第2回で見たとおりソフトウェアは目に見えません。 仕様書は、見えないものをチームで共有するための唯一の手段です。
| 外部設計 | 内部設計 | |
|---|---|---|
| 入力 | ソフトウェア要求仕様書 | 外部設計で定めた方式の記述 |
| やること | システムに関する設計知識を用いて、方式的記述を作る。 外部インタフェースを再定義し、サブシステムへ分解して、 サブシステム間のデータと制御の流れを決める | 方式の記述を詳細化して、プログラムの仕様書を作る。 各サブシステムをプログラムモジュールレベルの記述まで詳細化する |
| 視点 | 外から見た仕様 | 中の作り |
| 粒度 | サブシステム | モジュール |
外部設計は「外から見えるところ」を決めます。
機能、操作方法、ユーザインタフェース、コード設計など。
ここで決めたことはユーザに見えるので、後から変えると影響が大きい。
内部設計は「中の作り」なので、外から見た振る舞いさえ同じなら、
後から変えても影響は閉じます。この違いが、次回の結合度の話につながります。
良い設計とは、簡単にいえば 「要求品質を満たすシステム構造を作る」ことです。
ひとつの指標だけを最大にするのではなく、 バランスのとれた最善解を見つけることが良い設計につながります。
速度を上げれば保守性が下がることがあります。柔軟にすれば複雑になります。 設計とはトレードオフ（相反する要求の折り合い）を決める仕事だ、と言えます。
設計でもっとも重要なのは、システムが持つ複雑さをいかに克服するかです。 複雑なシステムほど、設計時に品質とコストに関わる問題の所在や原因がつかみづらく、 後工程で大きな問題や欠陥となって、再設計・再作業の原因になります。
| 戦略 | 中身 |
|---|---|
| 1. 抽象化とモデルの利用 | 検討すべき性質だけを浮かび上がらせるために、適切なモデルを使ってその性質を正確に捉え、
同時に関係のない事項をそぎ落とす。 例：振る舞いの記述 ⇒ 状態遷移図、ペトリネット |
| 2. 分割（モジュール化） | 大きな問題を、扱える大きさの部分に分ける。 ひとつのモジュールを理解するのに、他をすべて理解しなくてよい状態を作る |
| 3. 段階的詳細化 | はじめから細部に入らず、粗い記述から順に細かくしていく。 外部設計 → 内部設計 の流れそのもの |
3 つに共通しているのは、 「一度に考えることを減らす」という一点です。 人間が同時に把握できる事柄の数には限りがあります。 設計技法の多くは、その限界に合わせて問題を刻む工夫だと言えます。
モジュールとは、それ自体でひとつのまとまりを持つプログラムの単位です。 分割の目的は次のとおりです。
ただし、分ければよいというものではありません。
細かく分けすぎると、モジュール間のやりとりが増えて、かえって複雑になります。
「どう分けたか」の良し悪しを測る物差しが必要です。
それが次回扱う結合度と強度（凝集度）です。