« 九州が、あつい!! ~SPL&MDDセミナー受講記~ (続き) | トップページ | USDMで仕様書を書いてみた »

2011年4月 4日 (月)

気にしてみて! 凝集度・結合度

Interface誌の強いプログラム... の連載記事、4月号5月号の2ヶ月に渡り『モジュール品質を知る』というネタで書きました。

モジュール品質についての皆さんの認知度は、どんな感じでしょう?
SESSAME初級セミナー(*)の講師など担当した際に、何度か聞いてみました。
 「モジュールの凝集度・結合度を知っていますか?」と聞くと、パラッと手が上がる程度。
 「モジュール強度、結合度なら聞いたことありませんか?」と聞くと、割と多くの方がうなずいていました。
そうなんです。
モジュール強度・結合度は、情報処理試験の午前問題では定番といってよい出題です。このモジュール強度・結合度は、モジュール凝集度・結合度と同義のことを言っています。
凝集度・結合度は、試験の定番問題になるほど、プログラマが知っていてほしい、大切な基礎知識なのです。


さて、このモジュール凝集度・結合度、ソフトウェアの設計としてどのようなものがよいか? その指標は頭に入っていますでしょうか?
簡単に言ってしまえば、
  「単機能で、インタフェースも疎なモジュールが望ましい」
ということです。

しかし...
実際のシステムは、凝集度の高いモジュールばかりでつくることは、ムリ
そこは、そのモジュールの役割や、パフォーマンスなどの制約、その他さまざまな開発事情なども踏まえて、緩急調整してモジュール品質を考えなければなりません。

また、モジュール品質として良い(妥当)かどうかは、定量的に数値化できるものではなく、人がレビューによって判断するしかありません。その判断には、どうしてもその人の経験値や、プロとしてのセンスが効きます。 これを身に着けるには、モデリングと同様にトレーニングが必要です。自分の作ったコードや、人の作ったコードの凝集度・結合度を見て、「扱いやすいモジュールか」、「保守していて堅牢なモジュールか」など、考えてみるようにしましょう。


モジュールの凝集度・結合度を身に着けるトレーニングとしては、コードレビューするときにもチェックしてみると良いと思います。
結合度は、入出力パラメタや、外部データ参照などの有無で、すぐ確認できます。
凝集度は、コメントを見てチェックしましょう。

コメントには、処理のそのものを書くのではなく、その処理の目的(意味)を書くようにします。
すると、

 ・単機能なモジュールならば、
   → その目的は簡潔に1、2行のコメントに書ききれるでしょう。

 ・複数機能のモジュールならば、
   → 「 xxxして、xxx 」 とか、 「xxxと、xxxする」 など
      順接の接続詞でコメントが書かれます。

 ・論理凝集や、時間的凝集度など低い方のモジュールになると...
  → 「 xxxか、xxxする 」 とか、「 xxxだったら、xxxする 」といった、
      何らかの条件判断による挙動説明が現れます。

さらに、コメントにモジュールの目的が書かれず、「xxxxタイマ割込みによる処理」 だとか、「xxx状態から、xxx状態になった時の処理」というように、いつモジュールが呼ばれるかなどの実装手段だけが、コメントに書かれているモジュールは要注意です。 (目的視点で示せないモジュールは、往々にして怪しいです)


※ ただし、コードレビューで凝集度が確認できるのは、ちゃんと意味のあるコメントがかかれていなければなりません。コードでわかる処理そのままをコメントに書いていたり、コードと乖離したコメントでは、意味を成しません。設計を気にする前に、コーディング作法として、コメントの書き方には気を配りましょう。


こういったコードレビュー目線ならば、手持ちのコードの凝集度・結合度がどうなっているか、割と簡単にチェックできると思います。
普段から多くのコードのモジュール品質を気にかけることで、 『良い設計ができる』 力を磨いてみてはいかがでしょう。


(*) SESSAME初級セミナー
「組込みソフトウェア管理者・技術者育成研究会」(SESSAME: Society of Embedded Software Skill Acquisition for Managers and Engineers)が作成した、組込みソフトウェア初級向けコース。
組込み特有のプログラミング知識や、ソフトウェアの分析・設計~テストまで、各工程で必要となる基礎技術について概略を網羅したセミナーです。


※ 関連記事: Interface 2011年4月号
          Interface 2011年5月号

« 九州が、あつい!! ~SPL&MDDセミナー受講記~ (続き) | トップページ | USDMで仕様書を書いてみた »

ソフトウェア開発」カテゴリの記事

Interface記事」カテゴリの記事

コメント

「パフォーマンスなどの制約」とあり、そのこと自体は是とするものの、実際にどれだけ本当にパフォーマンス見積りや測定がなされた上で「パフォーマンスのための」設計・実装が行なわれているか、疑問があります。きれいな設計をして、分析をして、どこがパフォーマンスのボトルネックとなりうるのかを特定し、そこのパフォーマンスの見積もりをし、その結果を基に実装形態を決めたり、シミュレーションや実装後の実測によって絞り込んだりするのであれば、納得できます。

YoshiWooodsさんの仰ること、もっともです。
パフォーマンスを理由に凝集度を落とす場合は、より具体的・定量的な事実を示すべきだと思います。
パフォーマンスを出すために「なんとなく...」で、理解しにくいモノを作ってしまうと、時間を経るとそれ自体がバグの温床になる可能性が出てきます。

パフォーマンスを出すために、チューニングするようなモジュールは、実はシステムの心臓部だったりすると思うのです。そういう箇所だからこそ、しっかり分析・設計し、実測データも取ってモジュールをFIXする。その上で、保守資料としてそれらを添えておかないと、後々手が入れられないものとなってしまうと思います。

ご返答ありがとうございます。ちょうど、Robert Martin が関連記事を呟いていたので紹介します。 http://alarmingdevelopment.org/?p=571 「パフォーマンスは測定できるし客観的。設計は主観的だし正解がない。だからと言ってパフォーマンスにばかりかまけていたら、それは落とした鍵を明るいところでだけ探すのと同じこと。」

すみません、Robert Martin ではなく Martin Fowler でした。

コメントを書く

(ウェブ上には掲載しません)

トラックバック


この記事へのトラックバック一覧です: 気にしてみて! 凝集度・結合度:

« 九州が、あつい!! ~SPL&MDDセミナー受講記~ (続き) | トップページ | USDMで仕様書を書いてみた »