Tweet

会社のPCの入れ替えでDoxygenとGraphvizを再設定する機会があったので、メモメモφ(・ω・ )

本記事のカテゴリーをプログラミングにしましたが、プログラミング手法に関する話はありません。

ざっくり、どんなものか言っちゃいますと、

Doxygenはコメント（javadocまたはDoxyヘッダー、XML ドキュメント コメント）をHTMLベースで読みやすくしてくれるツールです。

GraphvizはDOT言語というスクリプトの一種を用いてグラフを生成してくれるツールです。

この二つを組み合わせることで、詳細設計書が作れちゃいます。

私としては、今後の開発はTDD（テスト駆動開発）を行っていくべきだと思っています。
そのためにも工数を削減できる箇所は削減してテスト関連の作業に工数を割り振るべきです。

今回は詳細設計書をDoxygenベースで作成することで、詳細設計の工程を簡略化することが狙いです。
なんと今なら、オマケで単体テスト仕様書まで作れちゃいます！

まず、下記URLからDoxygenとGraphvizをDLしてください。
最新版は、Doxygenが1.8.6、Graphvizが2.36でした。

Doxygen: http://www.doxygen.jp/

Graphviz: http://www.graphviz.org/

私の記憶だと、何かの理由でGraphvizを先に入れたほうが良かった記憶があるので、Graphviz ⇒ Doxygenの順にインストールしました。

インストールして、Doxygenを立ち上げると、以下の画面が出てきます。

ステップ1 – Doxygenの設定

ステップ1として、設定を登録したDoxyfileを作成しましょう。

まずは設定です。
Wizardタブを開き、プロジェクト名とバージョン番号を入れましょう。

残りの項目は任意で良いと思います。

次にExportタブを開きます。
TopicsからProjectを選択し、出力言語： 日本語に設定します。

次はBuildを選択し、以下の3つにチェックを入れます。

EXTRACT_ALL
EXTRACT_PRIVATE
EXTRACT_STATIC

これで全てのメンバが表示されるようになります。

 次にTopicsの一番下にあるDotを選択し、以下にチェックを入れます。

HAVE_DOT
UML_LOOK
CALL_GRAPH

あとはDOT_PATHにGraphvizの実行ファイルがあるパスを入れれば設定は完了です。
私の場合は、「C:/Program Files/Graphviz2.36/bin」でした。

最後に設定をファイルに保存です。
[File] → [Save]でDoxyfileを書き出します。

以降、設定を呼び出す場合は、[File] → [Open]（または[Open recent]）からDoxyfileを開くことで設定を読み込めます。

次はコメントコーディングをしてみましょう。

ステップ2　コメントコーディング

ここでは、詳細設計で行うフローチャートを作る感じですね。

ただ、Doxygenではフローチャートは作成することができませんので、代わりにコメントで処理の流れを決めてしまいます。

たとえば、

//! Aの処理
//! ＜IF＞Aの処理が成功した場合
//! -->フラグを立てる
//! ＜ELSE＞
//! -->フラグを下ろす

というような感じです。

アクティビティ図で書くとこんなイメージ。

Visual Studioでの開発だと関数ヘッダーコメントにコメントタグが利用できるので、関数の解説はこのコメントタグを利用して書きます。
以下のような感じ。

/// <summary>
/// 計算に使用する入力値を全てチェック
/// </summary>
/// <param name="inputData">入力データ(in)</param>
/// <returns>正常：true</returns>
/// <returns>エラー：false</returns>
/// <exception cref="System.Exception"/>

コメントタグが利用できない場合は、doxyタグを利用することで代替可能です。
VisualStudioだと自動入力機能があるので、今回はコメントタグを利用しています。

また、ifやswitchでの条件分岐、forやwhileでのループは＜if＞や＜for＞という形で表現しています。
＜＞が全角になっているのは、半角にしてしまうとDoxygenでのhtml生成時にタグと誤認識してしまうので、これを回避するためです。

スコープは–>という形で表現しています。ひとつ深くなると—->となり、さらに深くなると——>という感じです。

try-catch-finallyは、[try][catch][finally]という感じで括りを分かるように記述しています。

これでコメントコーディングは完了。あとはコメントに沿って実装をするだけです。
これなら設計者と実装者が異なっていても簡単にコードに落とせますね。

この方法を導入して、詳細設計にかかるコストをかなり削減することができました。
単体テストもCUnitやNUnitを使う場合は、同じ方法でテスト仕様書を作成することができます。
設計コストを抑えてテストをちゃんとやって品質を向上させましょー！

もっと効果的でコストを抑えられるやり方や、このやり方の改良点などがあれば、ぜひぜひ教えてください！

Tweet

Mask_Siva

北の試される大地に生息しているSEです。
楽しみながらプログラムを作ったり、ゲームで遊んだりしています。