ホームに戻る
出典 :
構造化プログラミング - Wikipedia トップダウン設計とボトムアップ設計 - Wikipedia モジュール - Wikipedia 「モジュール強度とモジュール結合度」の図解 – サイゼントの技術ブログ モジュール結合度について - Qiita モジュールの強度と結合度＜システムの調達＜Ｗｅｂ教材＜木暮
関連 :
Don't Repeat Yourself (DRY) SOLIDの原則 ソフトウェア開発におけるアンチパターン プロセス中心アプローチとデータ中心アプローチ ガード節 [C++]例外処理
目次 :

構造化プログラミング(構造化設計)とは

コンピュータプログラミングに「構造」の概念を導入することで、開発効率と品質の向上を図るプログラミング技法のこと。
1969年にエドガー・ダイクストラが発表した論文が初出。
それまでの、各部品を下から一つ一つ積み上げる「ボトムアップ設計」(段階的抽象)では、各部品間の依存関係を生みやすく、プログラムの正しさを検証することが困難となっていた。
(プログラム部品(モジュール)、およびそれらを組み合わせた際のプログラム正当性を証明するためのテスト回数は、モジュールが増加するごとに指数関数的に増えてゆくため。)
これを受け、部品間の不必要な依存関係を排除できる「トップダウン設計」(段階的詳細)へのパラダイムシフトの必要性を訴えた。
「トップダウン設計」(=構造化設計)が正しく行われた場合、関連の無い機能による影響を無視できるため、
機能単位で独立したモジュールごとに検証を行えばよく、テストの回数を抑制できるとともに、ソースコード自体の静的な検証も容易となる。
尚、「構造化定理」と混同されることが多いが、無関係である。

モジュール(module)とは


ソフトウェアにおける「モジュール」は、厳密にはコンパイルの単位(Cにおけるファイル)を指す。
(オブジェクト指向言語におけるクラス(およびその実体であるオブジェクト、インスタンス)も広義のモジュールである。)
同一ファイル内においてはグローバル変数を用いたデータの共有が可能であるため、データ共有が必要な(=機能的な結びつきが強い)関数群を一つのファイルにまとめることが基本となる。
段階的詳細化の過程で、一つのモジュールが複数の小機能を含む(ことでモジュールが肥大化している)場合は、小機能ごとのモジュール分割(階層化)が求められる。
(小機能ごとのサブモジュールを束ねる機能部品も同様にモジュールと呼ばれる。)

モジュールは一般に、「交換可能」であるものとされる。即ち、 ことが重要である。相互に交換可能なモジュール同士ではインタフェースは共通しながらも、内部の実装はそれぞれで独立している。
(インタフェースと実装の分離)

システムの構成要素である単一のソフトウェア(プログラム)、または単一のハードウェアデバイスは、「システム視点では」機能部品(モジュール)と見なすことができるが、
「ソフトウェア視点でのモジュール」と区別するため、「サブシステム」または「コンポーネント(component)」と呼ぶことが多い。
(「モジュール」「コンポーネント」共に原義としては「部品」「構成要素」と大きな違いは無いが、
「コンポーネント」は「全体の一部」、「モジュール」は「交換可能な機能部品」の意味合いが強い。)

モジュール強度とモジュール結合度

構造化設計(構造化プログラミング)における設計成熟度の指標。
モジュール強度が強く、モジュール結合度が弱いほど、構造的に優れている。
両者はトレードオフではなく、両立が可能である。

モジュール強度

モジュール自身の(特に変更に対する)安定性を表す。モジュール強度が強いほど、他の機能に対する変更による影響が小さい。
区分 説明 モジュール強度
暗合的強度 無関係の機能を一つのモジュールにまとめる 弱
論理的強度 論理(≠機能)的に関連のある機能を一つのモジュールにまとめ、
どの機能を使用するかを引数により決定する
時間的強度 実行時のある時点で利用される複数の機能を一つのモジュールにまとめる
(機能間の関連は不問)
手順的強度 必ず順番に実行される複数の機能を一つのモジュールにまとめる
連絡的強度 手順的強度 + モジュール内の機能間でデータの受け渡し
情報的強度 特定の同じデータを扱うための機能を一つのモジュールにまとめる 構造化設計の目標
機能的強度 モジュールが単一の機能のみを提供 強
モジュール強度はモジュール内の各機能(グローバル変数および関数)の「意味的な」結びつきの強さを表す。 即ちモジュール強度が強いほど、そのモジュールの役割が明確、かつ限定的であることを意味し、再利用がしやすくなる。 なお「暗号的」は誤り。

モジュール結合度

モジュール間の依存度を表す。モジュール結合度が弱いほど、モジュールの切り出し・再利用が容易となる。
区分 説明 モジュール結合度
内部結合 あるモジュールが別のモジュールの内容・命令を直接参照・使用する 強
共通結合 構造を持つ大域データを複数のモジュールで共用する
外部結合 構造を持たない大域データを複数のモジュールで共用する
制御結合 相手のモジュールの機能に影響を与える制御情報
(機能コード、スイッチなど)を受け渡す
スタンプ結合 モジュール間で、構造を持つ引数(構造体など)を受け渡す
(不要なデータを全く含まない場合は「データ結合」に分類される)
データ結合 モジュール間で、構造を持たない引数を受け渡す 弱 構造化設計の目標
モジュール結合度が弱いことはモジュールの独立性が高く、アクセスする対象(のデータ)がより限定されていることを意味する。 言い換えると、モジュールの内部処理とインタフェース(入出力)が明確に分離されているということで、 関連する他モジュールの内部構造を知らずとも、インタフェースさえ把握しておけば良い。 このためモジュール同士の関連がより単純かつ明確となり、プログラム構造を把握しやすくなる。

goto レスプログラミング

「構造化プログラミング」の前年にダイクストラが "Go To Statement Considered Harmful" (Go To 文は有害と見なされる)という記事を投稿したこともあり、 goto 文の排除こそが構造化プログラミングであるとの誤解も根強い。 しかし goto 文の安易な使用がプログラムの構造を破壊し、構造化の妨げとなることは事実であり、構造化と goto の排除はともにプログラム構造の明快化に寄与すると言える。 即ち、goto レスを構造化の指標(の一部)とすることは合理的であり、多くの現場では(構造化を志向していない場合も含め) goto の使用を意図的に制限している。 (深いネストからの脱出やエラー処理など一定の用途は存在するが、そもそも構造化(トップダウン)設計の下ではそのような深いネスト自体が忌避される。) goto 同様の無条件分岐である break 文、continue 文も安易に使用すると論理構造の破壊につながる。 (ただ break 、continue は適切に用いることでループをより簡潔に記述できる。これはガード節の考え方と同様である。) また、オブジェクト指向言語においては例外処理を利用できる。 例外処理は関数呼び出しを跨いだ「大域脱出」ができるため、goto よりも強力である。「去勢された goto 」と呼ばれることもあるが、例外処理の本分はジャンプではなくエラーの体系的な処理である。