技術とか戦略とか

証券レガシーシステムを8年間いじった普通のSEによるブログ。技術のみではなく趣味の戦略考察についても。

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

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
テストについては一通り書いたので、今度は製造・単体テスト工程以前の工程に戻ります。

今回は、内部設計について、試験頻出のモジュール強度・モジュール結合度について書きます。
 
モジュール強度・モジュール結合度は構造化分析の結果が妥当であるかを判断するための指標です。
(主に手続き型言語で開発する場合に構造化分析を使用します。構造化分析については参考書以上のことが書けないのでここでは取り扱いません。)
ここで言う「妥当」とは、「モジュールを修正した際に、他のモジュールに影響を与えず、影響範囲を限定できる」という意味です。
修正による影響範囲を限定することは、結合テストシステムテストの手戻り工数を削減したり、リリース後の保守工数を削減したりする上で重要になります。
影響範囲を限定することができないと、修正にかかる工数が跳ね上がり、最悪の場合リリースできなくなったりリリース後の保守をしきれずにサービス撤退することにもなりかねません。
 
モジュール強度・モジュール結合度の話は以下のようなものです。
参考書では文書だけで説明されているケースが多いと思うのですがイメージがわかないと思うので、例(イメージ図)を付記しています。

f:id:akira2kun:20180707143901j:plain

  • モジュール強度が弱いと困る例
    遅延証明書のフォーマットが変更され、気の利いた一言欄が追加になった。「言い訳機能」「勤怠入力機能」に気の利いた一言欄を用いた処理を追加する。連絡的強度よりモジュール強度が弱いと、「言い訳機能」「勤怠入力機能」の変更が同一モジュール内の別の機能に影響を及ぼす可能性があり、影響調査や修正の工数が増大する。

f:id:akira2kun:20180707144005j:plain

  • モジュール結合度が強いと困る例
    遅刻して言い訳したことで上司に怒られ、叱られフラグが立ち、叱られ文字列が更新された。これを受けて反省モジュール(反省機能)により反省するのが正しい挙動だが、制御結合より結合度が強いと叱られ文字列更新により他の機能が影響を受ける可能性があり、影響調査や修正の工数が増大する。

なお、影響範囲を限定するという視点はシステム開発を担う者として欠かすことができない視点であると共に今なお追い求められているテーマの一つで、データ中心アプローチや、今流行りのオブジェクト志向言語のフレームワークデザインパターンというのも、影響範囲を限定する考え方を突き詰めたものです。