WHATで考える練習

プログラムの設計を勉強していると、”WHAT” と ”HOW” という言い方を、よく見かけます。
　WHAT ： 何を　　HOW ： どうやって
プログラムのアルゴリズムを考えるのは、”HOW”。 ですから、プログラムを作ると、必ずHOWは考えます。 しかに、それが ”何を” 実現する目的で作られているか、設計者がそこに注目して思考し、アウトプットしなければ、 WHAT は 見えるモノ として残りません。

連載の2回目の「”いきなりプログラミング”は危険だ」では、　”仕様との関係性が読み取れないコードは危険” といったことを書きました。　HOWでプログラムを作ってしまうと、全体の構造が ”仕様との対応が理解し難い入り組んだ構造（≒スパゲティ状態）” になりやすく、またそうなってしまっていることも気づきにくいのです。

仕様との関係が解るプログラムにすると何が良いのか？
　・ プログラム構造が理解しやすい
　・ 後々、そのプログラムは保守しやすい
　・ 再利用できる場所を考えやすい
2番目以後は、理解しやすいからこそ、使いやすいという二次効果になります。

「イメージ的には解かるけど、本当に？」と思われるかもしれません。
HOW で作ったプログラムと、WHAT で作ったプログラムがどう違うか、システムテスト以後で何か障害が見つかった場合の対策方法を例として考えて見ましょう。

● HOWで考えると．．．

出来上がったプログラムが、HOWで考えられた構造になっている場合、設計図は実装をそのまま絵にしただけなので、「コード見たほうが確実だよ！」といったことになりがちです。そのため、障害が起きたときにも、事象から「コードのどの辺が怪しい」と、開発者は頭の中で辺りをつけて、コードを直接調べているでしょう。

それで、問題箇所が見つかった後も、コード上で修正方法を考えます。そして、他にどんな影響があるのか、工程を遡って、全体を調査するような作業が必要になります。また、修正結果を確認するためにも、修正したコードから必要なテストがどれかを調査し、沢山のテストケースを実行しなければならなくなるでしょう。
といった具合に、調査・修正・確認 のすべての工程がコード基点での考え方になってしまいます。

● WHATで考えると．．．

WHAT で考え出来上がった構造は、仕様からどうプログラム構造に展開したか、さらにどうやって詳細に実装したかが、設計図に残っています。障害が起きたときにも、仕様の中のどれに絡んでその事象が起こっているかを考えれば、自ずと原因調査としてどこにプログラムのどこに焦点を絞るかが考えやすくなっています。

また、それで原因箇所が見つかれば、それに影響を受ける箇所も、またそれらの再確認のためのテストケースがどれかも、仕様を基点として、考えられるでしょう。
それは、WHATで思考した結果、仕様と実装とのつがなりが、設計図として残してあるためです。

ただ、これは開発時にも、保守時にも WHAT で考える癖がないと、途中で破綻してしまいます。
　・ アーキテクチャ設計時に ”WHAT：何を” の塊で作るように、考える。
　・ ”WHAT” で考えた結果を、設計図（＝ 仕様との関連がわかるドキュメント） に残す。
　・ 対策考えるとき、”WHAT：何を” するところに問題があるのか、考える。
　・ 修正するとき、”WHAT：何を” しているところを、どう変更するのか、考える。
　・ 修正確認は、 ”WHAT：何に” ついて確認が必要かを考える。
っと、くどくど書きましたが．．．
伝えたかったこととしては、「常日頃 ”WHAT” 基点で考える癖をつけて、よいプログラム構造が作れるようになりましょう。」　ということでした。

連載記事のほうは、今月発売の2011年6月号から、ちょうど DFD を使って WHAT でプログラムを分析する例をご紹介しています。よかったら、こちらも書店で眺めてみてください。

※　関連記事：　Interface 2011年2月号
　　　　　　　　　　Interface 2011年6月号

掲載落ちコラム：モジュール品質

Interface連載の「モジュール品質を知る」の回、ページの関係上で載せられなかったコラムがあります。せっかくですので、ここで公開しちゃいます。

～～ コラム：馬具取のつぶやき ～～
物造くんの大講演会(モジュール品質としての凝集度・結合度の解説)へのおつきあい，野比さんも読者のみなさんもお疲れさまでした．
モジュール品質は，話を聞けばなるほどと思うものの，実際に自分の設計で考えようとすると雲をつかむようなところがあります．そういう意味で野比さんの感想『わかったような気がしますが、モヤモヤした状態で～』は，誰にでもあてはまるのでないでしょうか．

まず大切なことは，モジュールの分割や組み合わせ方には良い悪いがある，難しい言い方をすると，品質を伴うということを知ることです．そして，良さの尺度には凝集度と結合度というものがあることです．
これを知っているだけで，知らないのに比べて設計に雲泥の差が出ます．その意味で，野比さんはすでに一歩スキルアップしているのです．

次には，１テーマに絞ってモジュール品質をよくしてみることに挑戦してみましょう．
たとえば結合度において，グローバル変数で結合させている方は多いのではないでしょうか．これを次の設計では，「完全グローバル変数レス」で行ってみるのは，よいテーマです．変数へのアクセスタイムが問題になるようなことは実際にはまれですし，グローバル変数をなくす設計をすることで，副次的にモジュール分割をよりよい方向に進めることができることでしょう．
～～～～～～～～～～～～～～～～

「完全グローバル変数レス」に一気に挑むのは、少々ハードルが高いですね。最初は、自分の担当範囲で一つ、二つ、選んでグローバルからの解消を試みてみましょう。
その際は、次のことを考えてみてください。

　(1) その変数の意味はなに？
　　　　→ たまに、デバッグ時の確認用に作られた変数などが残っています。
　　　　　　それらは、削除してしまいましょう！

　(2) 何のためにグローバルに置かれているの？
　　　　→　どうしても、グローバルにする必要はあるのか。
　　　　　　　理由が説明できなければ、グローバルレスにチャレンジ！

　(3) その変数に、もっとも強いかかわりを持っている処理はどれ？
　　　→　強いかかわりを持つ処理があれば...　
　　　　　　　　その処理の管理下に変数を置く。
　　　　　 複数箇所から、同等のかかわりの強さで使用されていれば...
　　　　　　　　変数の管理処理を置く。

以上のようなステップで、検討し、変更をしてみましょう。

ここで一つ注意！！

変更結果が元通り動くかどうかのテストが、絶対・絶対・絶対に必要です
グローバル変数に絡んでいたモジュールのテスト方法を予め確認しておきます。それから、修正を行うようにしましょう。これは、鉄則です。「このぐらい大丈夫...」 という安易な気持ちがデグレードにつながります。このちょっとひと手間を惜しまずに、チャクチャクと改善ステップ踏みましょうね。

いいコード残して、いいソフト屋になる。
後で振り返ると、その道のりが、結構自分の自信になりますよ。きっと

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

USDMで仕様書を書いてみた

「強いプログラミングを作るテクニックを学ぶ」の連載3回目で、『要求分析の重要さと難しさ』というサブタイトルで、要求仕様の分析について取り上げました。その中で、USDM(*)という仕様書の表記をご紹介しました。
　※ LEDキューブシステムUSDM版仕様書　>> Download ： specofledcube_specusdm_v1a.xls

このUSDM版仕様書をご覧になった皆さんは、どう思われたでしょう？
私も当初は、ドキュメント形態として重くて面倒だな．．．と思っていました。その後、いろいろ試す中で、USDMを使うのも悪くないなと思うようになりました。その理由を、3つばかりご紹介しておきます。

【こんな時に、USDM作ってみてよかったと思った】

(1)　仕様理解のために使う
連載本編でもこの方法をご紹介しました。
以前から、仕様書を読んでQ&Aシートを毎回作っていましたが、それでも理解の漏れ、勘違いはあります。USDM表記法に則り、理由を考えて要求・仕様を埋める。Defaultや、異常系など、各要求項目に対して決まったルールで仕様を確認する。などにより、抜け漏れ、勘違いのフォローができました。
... 気が向いたら、Interface誌 3月号で詳細は読んでみてね。

(2)　仕様に対する確認用に使う
実は、これが一番のおすすめポイントだと思ってます。
ご紹介したUSDM仕様書、CQ出版さんのサイトからダウンロードすると、各仕様項目のところに3つのチェックボックスが点いている事に気づいた方いらっしゃいますでしょうか？　これは、後工程での確認用に作ったものなのです。

●仕様の確認で1コ目にチェック
要求元と仕様の確認ができたところで、確認済みのチェックを入れます。仕様未定の部分があれば、次工程に進めるために必要な仮仕様を書いて、チェックボックスには“未”の印をつけておきます。そうすることで、この仕様に絡む箇所は、後で仕様変更がでてくる可能性があることが見て取れます。

●設計レビューで２コ目にチェック
（基本設計などのレベルではなく、）実装目前の設計レビューでチェックを入れます。
これについては、” (3) 保守・派生開発時のベース資料 ”↓ のほうで詳しく説明します。

●テスト設計で3コ目にチェック
どの仕様に対して、テスト設計してテストケースを作成したかを確認した時点で、チェックを入れます。

(3) 保守・派生開発時の資料として使う
一旦作ったシステムも、保守・派生開発時には、システムの設計を知るための資料が必要です。それを、このUSDM仕様書に情報を付加して使えるようにしようというものです。

仕様項目の横に、設計した結果、どこでその項目が実現されているのかを、印を付けていきます。
つまり、XDDP(**)で言うところのTM（Traceability Matrix）を作ってしまうのです。設計段階でこのマトリクスを作ってしまえば、後の保守・派生開発時には、これがそのまま影響範囲分析、変更設計のための調査資料として使えます。

また、この方法で仕様と実装の関連を残していくと、凝集度の悪い設計箇所があれば、一つの機能に対し沢山の実装箇所に印が付くことになります。そういった目線で、設計結果を確認することで、設計品質を確かめるためのレビュー資料としても使えます。

USDMの仕様記述は、確かに大変です。
折角手を掛けた仕様書ですから、やはり2度、3度これを使いまわさないと、作った効果は薄いと思います。

．．．とはいえ、現状のUSDMでは、未だに気になっているところもあります。
　・EXCELはやっぱり使いにくい
　・仕様項目間の依存関係が表せない
その辺は自作でツールをつくるなど、改善策を考える必要がありそうです。

しかし、今手持ちのツールですぐに試せる方法です。設計品質をあげるにはどうしたら．．．　っと、手をこまねいて悩んでいるのだったら、お試ししてみるのもありだと思います。

最後に、
Interface誌に掲載するに当たり、USDM版仕様書の作成についてご指導いただきました清水吉男さんに感謝いたします！！　ありがとうございました。

(*) USDM ： (Universal Specification Describing Manner)　抜け漏れしにくい仕様書の表記法
　　　関連書籍　『要求を仕様化する技術・表現する技術 - 入門＋実践 仕様が書けていますか?』
(**) XDDP： （eXtreme Derivative Development Process）　派生開発に特化したプロセス
　　　関連書籍　『「派生開発」を成功させるプロセス改善の技術と極意』

※　関連記事：　Interface 2011年3月号

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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