†ソフトウェア設計は、ソフトウェアの要求定義ができた次の段階の作業として行われるものである。†ソフトウェア設計について、いくつかの考え方がある。†ソフトウェアは分割して設計して、統合することによって開発を行うというアプローチである。設計の工程で、ソフトウェアの機能をいくつかの単位に分割していく考え方。分割した単位は、さらに小さな単位へと分割して構成していく。一般的には、「システム→サブシステム→プログラム→モジュール」といったように階層的に分割される。解決しなければならない問題に対するアプローチの方法として、まず全体を考える。次に、これをいくつかの部分に分ける。分けた部分を、さらにいくつかの部分に分けるといったようにして、段階的に分けながら曖昧な部分を徐々に明確にして、詳しくしていく。問題を小さな部分に分けることによって、複雑な問題の複雑さを減らすという発送に基づくものである。これを段階的詳細化(段階的洗練)と呼ぶ。抽象化とは、対象の中から最も特徴的な点だけを取り出して、他の部分を無視して捨てることである。抽象化することによって、その対象が持っている曖昧さを減らして、特性を明らかにすることができる。手続き型のプログラムで、モジュール、サブルーチン、関数のようにある程度まとまった単位の処理を、ひとつにまとめてしまうことである。まとめることで、そのモジュールや関数を使うときには、引数などについてだけ知っていれば、その処理の内容について知らなくても済む。処理内容に関しては隠すことができる。手続き型のプログラムで、プログラムの制御の流れ(時間の経過によって変化する処理の状態:プログラムの動的構造)と原始プログラムの命令の配置(プログラムの静的構造)を一致させることである。制御を抽象化すると、原始プログラムを追跡することによって、制御の流れを読み取ることができる。このため、わかりやすく、修正しやすいプログラムを作ることができるようになる。制御を抽象化するために、連結(順次)・選択・繰り返しの3つの基本制御構造だけを組合せてプログラムを作ればよいとされている。構造化プログラミングは、この考え方に基づいている。データの抽象化まとまったデータの構造を、それを操作する手順と共にひとつにまとめてしまうこと。抽象データを使うときには、その内容のデータ構造や操作を知らなくてもよい。それらはずべて抽象データの中に隠されている(情報隠蔽)。データの抽象化を行ったものが抽象データ型であり、オブジェクト指向プログラミングはこの考え方に基づいている。凝集度を強めて、結合度を弱める。凝集度と結合度はOOPが主流になる以前の1970年代に構造化設計手法の中で提唱された、ソフトウェア部品の独立性を評価する尺度の1つである。・ソフトウェア部品が提供する機能のまとめり度合いを評価する尺度。&br・まとめりが強いほどよい設計とされる。・複数のソフトウェア部品間の結びつき度合いを評価する尺度。&br・結びつきが弱いほどよい設計とされる。一言で表現する名前を付ける。適当な名前をつけにくい場合は、まとめりの悪い機能がクラスに集められている可能性が高い。わかりやすい名前を付けることで別の人がソースを読むときも理解しやすい。秘密をたくさん作るなるべく外に中を見せないようにする。小さく作る部品の独立性を高めようとすると機能が限定されるため、メソッドやクラスは自然と小さくなる。†ソフトウェアに秩序を持ち込むために、パッケージやクラスの依存関係を循環させない。保守性や再利用性を高めるために部品の依存関係を循環させないことが重要である。依存関係の考え方は構造化言語の時代にはあまり必要がなかった。サブルーチンを循環して呼び出すように作ると無限ループになりやすいため、循環構造にするケースを避けていたからである。OOPでは複数のメソッドをまとめるクラスや、クラスをまとめるパッケージの仕組みが導入されたため、クラス間やパッケージ間で依存関係の循環が起こりやすくなったのである。単独でコンパイルできないために、これらの部品を単独で再利用できない。再利用するためには部品をまとめて利用する必要になってしまう。ある部品に対して依存関係があるということは、その部品を何らかの形で利用しているわけであるため、部品のどれかに手を加えた場合、利用する側に影響がないことを確認する必要がある。部品Cは独立しているため、部品Cを単独で再利用できる。部品Aは部品Bと部品Cに依存しているが、どこからも利用されていないため、部品Aを修正した場合は他の部品への影響を心配する必要がない。コンピュータ講座(1598d)。