ソースコードからモデルの絵を自動生成する
ソースコードからモデルの絵を自動生成するツール(Graphviz、PlantUML)についてメモ。
アイデアをラフなメモ書き。
【元ネタ】
Graphvizの簡単なサンプル
Graphvizメモ(Hishidama's Graphviz Memo)
AsakusaFW グラフ可視化メモ(Hishidama's Asakusa Framework Graphviz Memo)
【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 »
「プロジェクトマネジメント」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart2~プロセスのレイヤと達成目標のレイヤが異なる(2023.02.18)
- ストラテジストとプロジェクトマネージャの役割の違いは何なのかpart1~CSFはWBSみたいなものと捉える(2023.02.14)
- PM理論では課業志向の方が関係志向よりも生産性が高いことを主張しているのではないか(2023.01.22)
「ソフトウェア工学」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- Redmineは組織のナレッジ基盤として実現可能なのか~島津製作所の事例を読み解く #redmineT(2024.12.29)
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「システムアーキテクチャ構築の原理」の感想(2024.05.06)
「Agile」カテゴリの記事
- チームトポロジーの感想~大規模アジャイル開発でも組織構造は大きく変化する(2025.01.01)
- 「世界一流エンジニアの思考法」の感想(2024.12.08)
- 「システムアーキテクチャ構築の原理」の感想part2~非機能要件がシステムのアーキテクチャに影響を与える観点をプロセス化する(2024.05.06)
- 「スクラムの拡張による組織づくり」のScrum@Scaleの感想(2024.03.31)
- ソフトウェア工学の根本問題から最近のソフトウェア設計を考えてみる(2024.03.03)
「パターン言語」カテゴリの記事
- アーキテクチャ設計はベストプラクティスを参照するプロセスに過ぎないのか?~Software Processes are Software, Too(ソフトウェアプロセスもまたソフトウェアである)(2024.09.22)
- パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai(2023.06.24)
- XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた(2022.11.16)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
コメント