構造化開発

📢 この記事は gemini-2.5-flash によって翻訳されました

システム設計の基本原則

抽象化、モジュール化、情報隠蔽、モジュール独立性

モジュール化

ソフトウェアのアーキテクチャでは、モジュールは組み合わせたり、分解したり、交換したりできる単位なんだ。

モジュール化ってのは、開発するソフトウェアをいくつかの小さくてシンプルな部分、つまりモジュールに分解することだよ。各モジュールは独立して開発・テストできて、最後に完全なプログラムとして組み立てられるんだ。これは複雑な問題を「分割統治」するっていう考え方だね。モジュール化の目的は、プログラムの構造を明確にして、読みやすく、理解しやすく、テストしやすく、修正しやすくすることなんだ。

モジュール独立性

モジュール独立性っていうのは、各モジュールが比較的独立した特定のサブ機能を果たして、他のモジュールとの連携がシンプルであることだよ。モジュール独立性の度合いを測る基準は二つあるんだ。それは結合度と凝集度だね。

結合度

結合度ってのは、モジュール間の相対的な独立性（互いの繋がりがどれだけ密接か）を測る尺度だよ。結合度は、各モジュール間のインターフェースの複雑さ、モジュールの呼び出し方、インターフェースを介して渡される情報タイプなんかで決まるんだ。一般的に、モジュール間の結合方式は7種類あるよ。

結合度の種類

直接結合なし。これは、二つのモジュール間に直接的な関係がなく、それぞれ異なるモジュールの制御や呼び出しに属していて、互いに情報をやり取りしない場合のことだね。
データ結合。これは、二つのモジュール間に呼び出し関係があって、シンプルなデータ値をやり取りする場合のこと。高級言語の値渡しみたいなもんだね。
スタンプ結合。これは、二つのモジュール間でデータ構造が渡される場合だね。
制御結合。これは、あるモジュールが別のモジュールを呼び出して、制御変数を渡す場合のこと。呼び出されたモジュールは、その制御変数の値によってモジュール内の特定機能を選択的に実行するんだ。
外部結合。これは、モジュールがソフトウェア外部の環境（例えば、I/Oによってモジュールが特定のデバイス、フォーマット、通信プロトコルに結合される場合とか）を介して連携する場合のことだよ。
共通結合。これは、共通のデータ環境を介して相互作用するモジュール間の結合のことだね。
内容結合。これは、あるモジュールが別のモジュールの内部データを直接使ったり、非正常な入り口から別のモジュール内部に入り込んだりする場合のこと。こういうモジュール間の結合を内容結合って呼ぶんだ。

凝集度

凝集度ってのは、モジュール内部の各要素がどれだけ密接に結びついているかを測る尺度だよ。凝集度の高いモジュール（理想的には）は、一つのことだけをすべきなんだ。一般的にモジュールの凝集度は7種類に分けられるよ。

凝集度の種類

偶然的凝集（偶発的凝集）。これは、モジュール内の各処理要素間に何の関連性もない場合のことだね。
論理的凝集。これは、モジュール内で論理的に類似した複数の機能を実行して、パラメータによってどの機能を実行するかを決める場合だよ。
時間的凝集。これは、同時に実行する必要があるアクションをまとめて形成されたモジュールを指すんだ。
手順的凝集。これは、あるモジュールが複数のタスクをこなすんだけど、それらのタスクが指定された手順で実行される必要がある場合のことだよ。
情報的凝集（通信的凝集）。これは、モジュール内のすべての処理要素が同じデータ構造を操作するか、あるいは各処理が同じ入力データを使ったり同じ出力データを生成したりする場合を言うんだ。
連続的凝集。これは、モジュール内の各処理要素が同じ機能に密接に関連していて、しかも順序通りに実行される必要がある場合のこと。前の機能要素の出力が次の機能要素の入力になるんだ。
機能的凝集。これは最も強い凝集で、モジュール内のすべての要素が協力して一つの機能を完成させること。どれか一つでも欠けたらダメなんだ。

結合度と凝集度は、モジュール独立性の二つの定性的な基準なんだ。ソフトウェアシステムをモジュールに分割するときは、できるだけ高凝集・低結合になるようにして、モジュールの独立性を高めるようにしようね。

システム構造設計の原則

全体の構造設計をスムーズに完了させるために、以下の原則に従うべきだよ。

分解・協調の原則。システム全体は一つのまとまりで、全体的な目的と機能を持っているけど、これらの目的や機能の実現は、互いに関連し合う各構成要素が協力して働く結果なんだ。複雑な問題を解決するためのすごく重要な原則の一つは、それを複数の小さな問題に分解してそれぞれ処理すること。その処理の過程で、システム全体の要求に基づいて各部門の関係を調整するんだ。
トップダウンの原則。まずシステム全体の機能目的を捉えて、それから段階的に分解していくんだ。つまり、まず上位モジュールの機能を決めて、それから下位モジュールの機能を決めていくってことだね。
情報隠蔽・抽象化の原則。上位モジュールは、下位モジュールが何をすべきか、そして所属モジュール間の調整関係だけを規定するんだ。どうやるかは規定しない。これは各モジュールの相対的な独立性と内部構造の合理性を保証するためで、モジュール間の階層を明確にして、理解しやすく、実装しやすく、保守しやすくするんだよ。
一貫性の原則。ソフトウェア設計プロセス全体を通じて、統一された規範、統一された標準、統一されたドキュメント形式なんかを確保する必要があるよ。
明確性の原則。各モジュールは機能が明確で、インターフェースが正しくなければいけないんだ。複数の機能や無用なインターフェースは排除しよう。
モジュール間の結合はできるだけ小さく、モジュールの凝集度はできるだけ高くしようね。
モジュールのファンインとファンアウトは適切であるべきだよ。あるモジュールが直接呼び出す他のモジュールの数をファンアウト係数って呼ぶんだ。逆に、あるモジュールが他のモジュールに呼び出されるとき、それを直接呼び出すモジュールの数をファンイン係数って呼ぶんだよ。モジュールのファンイン、ファンアウト係数は適切でなければいけないね。経験上、うまく設計されたシステムの平均ファンイン、ファンアウト係数は通常3か4で、一般的には7を超えないようにするべきだ。そうしないと、エラーの発生確率が上がっちゃうからね。ただ、メニュー呼び出し型のモジュールや共通モジュールのファンイン係数は大きくても大丈夫だよ。
モジュールの規模は適切であるべきだよ。大きすぎるモジュールは、システムの分解が不十分になりがちで、内部に複数の機能が含まれている可能性があるんだ。だから、元のモジュールをさらに、できるだけ機能が単一なモジュールに分解する必要があるんだよ。でも、分解も適度にするべきだね。なぜなら、小さすぎるモジュールはモジュールの独立性を下げてしまって、システムインターフェースを複雑にする可能性があるからさ。
モジュールの作用範囲は、その制御範囲内であるべきなんだ。

システムドキュメント

情報システムのドキュメントは、システム構築プロセスの「足跡」であり、システム保守担当者の指針であり、開発者とユーザーのコミュニケーションツールなんだ。規範に沿ったドキュメントがあるってことは、システムが工学的に開発されたってことで、情報システムの品質が形式的に保証されてるってことだよね。ドキュメントが不足したり、適当だったり、規範に沿ってなかったりすると、元の開発者が異動した後、システムが保守もアップグレードもできなくなって、拡張性も生命力もないシステムになっちゃう可能性がすごく高いんだ。

システム開発者、プロジェクト管理者、システム保守担当者、システム評価者、そしてユーザー間のドキュメントの様々な役割を以下にまとめるね。

ユーザーとシステムアナリストは、システム企画とシステム分析の段階でドキュメントを介してコミュニケーションを取るんだ。ここでのドキュメントは主に、実現可能性調査報告書、全体計画報告書、システム開発契約書、システム提案書などがあるよ。
システム開発者とプロジェクト管理者は、プロジェクト期間中にドキュメントを介してコミュニケーションを取るんだ。ここでのドキュメントは主に、システム開発計画（作業分解表、PERT図、ガントチャート、予算配分表などを含む）、システム開発月報、システム開発完了報告書などのプロジェクト管理書類だね。
システムテスト担当者とシステム開発者は、ドキュメントを介してコミュニケーションを取るんだ。システムテスト担当者は、システム提案書、システム開発契約書、システム設計書、テスト計画書などのドキュメントに基づいて、システム開発者が開発したシステムをテストできるんだよ。そして、システムテスト担当者は評価結果をシステムテスト報告書としてまとめるんだ。
システム開発者とユーザーは、システム稼働中にドキュメントを介してコミュニケーションを取るんだ。ユーザーは、システム開発者が作成したドキュメントを参考にシステムを運用するよ。ここでのドキュメントは主に、ユーザーマニュアルと操作ガイドだね。
システム開発者とシステム保守担当者は、ドキュメントを介してコミュニケーションを取るんだ。ここでのドキュメントは主に、システム設計書とシステム開発完了報告書だよ。
ユーザーと保守担当者は、運用保守期間中にドキュメントを介してコミュニケーションを取るんだ。ユーザーは情報システムを使っている間に、運用中の問題を記録して、システム運用報告書や保守修正提案書を作成するんだよ。システム保守担当者は、その保守修正提案書やシステム開発者が残した技術マニュアルなどのドキュメントに基づいて、システムを保守・アップグレードするんだ。