ソースコードからモデルの絵を自動生成する
ソースコードからモデルの絵を自動生成するツール(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 »
「プロジェクトマネジメント」カテゴリの記事
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- プロジェクト管理の基本はテーラリング、Redmineはプロセスをテーラリングするツール(2022.04.21)
- 初中級プロマネはIPAデータ白書の統計情報を見積り、生産性、品質の観点で活用せよ(2022.04.17)
- タスク分割は親子チケットにすべきか、それともチェックリストにすべきか #redmine(2022.03.04)
「ソフトウェア工学」カテゴリの記事
- Javaのラムダ式の考え方(2022.08.10)
- テスト管理ツールTestRail、CAT、QualityForwardの感想(2022.07.30)
- メトリクス分析のコツは良いIssueを見つけること(2022.06.29)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
「Agile」カテゴリの記事
- 組織を芯からアジャイルにする対談の感想~今のアジャイルは先カンブリア時代なので何でもいい、アジャイル警察はいらない(2022.08.05)
- 製造業の業務にスクラムを適用できるのかという疑問~全てのビジネスモデルにスクラムを適用できるのか?(2022.07.31)
- 認定スクラムプロダクトオーナー研修の感想(2022.07.28)
- プロセス設計はどの範囲を指すのか?~プロマネの仕事はテーラリングにある(2022.06.19)
- 小説活動にプルリクエスト駆動が必要になってきた(2022.05.08)
「パターン言語」カテゴリの記事
- 「大人の学びパターン・ランゲージ」の感想~知識と経験を行ったり来たりするタイミングを大切にする(2022.06.05)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- 「ハリウッドリライティングバイブル」のマインドマップ(2022.01.23)
- 【資料公開】チケット駆動開発の解説~タスク管理からプロセス改善へ #redmine(2022.01.14)
- チケット駆動開発のプロセスとチケット管理システムの全体像 #Redmine(2021.12.28)
コメント