« 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集 | トップページ | Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date »

2014/03/25

ソースコードからモデルの絵を自動生成する

ソースコードからモデルの絵を自動生成するツール(Graphviz、PlantUML)についてメモ。
アイデアをラフなメモ書き。

【元ネタ】
Graphvizの簡単なサンプル

Graphvizメモ(Hishidama's Graphviz Memo)

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)

PlantUML の使い方 | プログラマーズ雑記帳

PlantUML

【1】クラス図、あるいは単なるネットワーク図を手書きではなく、ツール上のGUIでもなく、ソースで書きたい時がある。
ちょうど僕は、「アイデアを組織に広めるための48のパターン」の本を読んでいて、その内容にすごく惹かれて、それらパターンの一覧であるナビゲーションマップが欲しくなった。
ナビゲーションマップがあれば、パターンの間でどのような関連があり、どのようにパターンが生成されていく(generative)のかを見ることができると考えたからだ。

アイデアを組織に広めるための48のパターン」には、48個のパターンと、それらパターンの関係は本文に書かれている。
「パターンA→パターンB」というデータを本文から抜粋すれば、ナビゲーションマップを作ることができる。

つまり、パターン一覧があり、パターンの関連も決定されているので、それらの仕様をソースコードに落とし込めばいい。
そこで、Graphviz の dot コマンドを使って、簡単な有向グラフを生成できるのではないか、と考えた。

アイデアはこんな感じ。
但し、作成途中なので中途半端な絵になっている。

「アイデアを組織に広めるための48のパターン」のナビゲーションマップ(作成中)

デザインパターン、ドメイン駆動設計、組織パターン、XPのプラクティスなどのナビゲーションマップは、Graphviz の dot コマンドで描けるソースコードに落とし込めば、すぐに生成できるはず。

【2】他にも、ソースコードで有向グラフを生成したい時がある。
例えば、バッチのジョブフロー図もそうだ。

AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)によれば、Javaで書かれたオープンソースのHadoopのフレームワークであり、業務系バッチに特化しているものだが、バッチソースだけでなく、そのジョブフロー図も自動生成してくれるらしい。

バッチ処理は汎用機+Cobol時代からずっとあるけれど、その設計技法の中で、ジョブフロー図が一番重要な成果物だ。
ジョブフロー図がなければ、本番障害が起きた時に、どのジョブからリランして復旧すればよいか、などが分からなくなる。
しかし、お金のないSIや技術力のないSIでは、ジョブフロー図をExcelで書いているものの、その最新化を怠っている所も多い。
普通のお金のあるSIは、Visioでジョブフロー図を書いて都度更新しているが、バイナリファイルなのでバージョン管理もやりにくい。

しかし、バッチ処理のソースからジョブフロー図を自動生成できれば、ジョブフロー図を最新化する必要もない。
それができなくても、ジョブフロー図の元ネタをテキストファイルで書いておき、自動生成できるようにしておけば、そのテキストファイルをバージョン管理することで、変更管理の配下に置くこともできる。

ソースと設計書のトレーサビリティにもつながる。

【3】PlantUML の使い方 | プログラマーズ雑記帳によれば、UMLのクラス図やシーケンス図なども、テキストファイルから自動生成できるようだ。
JavaDoc上に書いておくようにしておけば、ソースコードに設計書が埋め込まれているので、ソースコードからUMLの各種ダイアグラムを自動生成する手法も選択できる。

【4】他にも、ガントチャートをRubyソースから自動生成するツールもある。

Rubyのガントチャート生成ツールTaskJuggler: プログラマの思索

【5】本来やりたいことは、ソースと設計書、報告書とのトレーサビリティだ。
ソースはバージョン管理にあり、チケットの作業履歴と紐づけている。
しかし、設計書や報告書はExcel、WordなどのOfficeファイルであり、バージョン管理したとしても、ソースの変更に追いつけていない。
本来なら、ソースコードを直せば、ソースコードから設計書を作り出すべき。

要件定義書、設計書、ソース、テストケース、障害などの間のトレーサビリティは、今後のソフトウェア開発で重要になってくる。
アジャイル開発でやっているとしても、その背後では、SCMやITSなどでトレーサビリティを確保できるようにしたいのだ。

時間に余裕ができたら、色々試してみたい。

|

« 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集 | トップページ | Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date »

Agile」カテゴリの記事

ソフトウェア工学」カテゴリの記事

パターン言語」カテゴリの記事

プロジェクトマネジメント」カテゴリの記事

コメント

コメントを書く



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


コメントは記事投稿者が公開するまで表示されません。



« 「アジャイルに効く アイデアを組織に広めるための48のパターン」の感想~エバンジェリストが自分のアイデアを組織に導入する時に役立つパターン集 | トップページ | Redmineのガントチャート画面に暦週や日付を表示するプラグイン redmine_gantt_with_date »