astahで設計書とモデル、プロセスをつなぐ為の資料のリンク

astahの事例を探していた時に、設計書とモデル、プロセスをつなぐ為のアイデアが書かれた資料を見つけたのでメモ。
以下はラフなメモ書き。
間違っていたら後で直す。

【参考】
モデルへの参照を含む多様な設計情報の継続的統合ドキュメント化に向けて

【1】以前、Redmine大阪で宿口さんの講演を聞いた時、機能安全規格を満たすプロセスをRedmineで実現する話があった。
その実装方法を聞くと、Wordの要件定義書ドキュメントの目次の各タイトルに、チケット番号のリンクが貼られていて、そのリンクからRedmineチケットとWordドキュメントの整合性を取るような仕組みを実装されている、とのことだった。

第16回Redmine大阪の感想　#RedmineOsaka: プログラマの思索

その時は、なぜそんなやり方が必要なのだろうか？と不思議に思った。
確かに、WordドキュメントにRedmineのチケット構造が同期されるので、見通しは良くなるが、それはRedmineのプラグインのような一機能で実現した方が良いのではないか？と思ったからだ。

WordやExcelとRedmineを連携しようとすると、結局、VBAマクロを駆使することになり、VBAを扱うのが苦痛だから(笑)

一方、上記の資料を読むと、Wordの要件定義書やアーキテクチャ設計書でモデルや作業構造をまとめるのががなぜ必要なのか、その理由が書かれている気がした。

【2】Word文書で組込みソフトウェアのモデルの絵や説明文をまとめたとする。
しかし、モデルは改変されるので、Word文書に書いた内容やモデルの絵はどんどん古くなる。
改変のたびに、逐一、モデリングツールで描いた絵をコピペしなくてはならない。

一方、要件管理ツールにあるソフトウェアの要件もどんどん変わる。
要件、モデル、そしてそれらの正しさを保証するプロセスも影響を受けて、要件の変更のたびに、派生的に編集作業が発生してしまう。
ドキュメントの保守作業ほど、無駄なコストの発生源であるものはないだろう。

つまり、要件とモデル、設計ドキュメントのトレーサビリティと変更の同期が課題になってくる。
また、標準プロセスで必要とされる成果物やドキュメントが揃っているか、という成果物の保証も関わってくる。

これらの課題はどうやって解決すべきなのか？

【3】上記の資料のストーリーは以下のようなイメージ。

①astah製品でUMLやSysMLなどのモデルを描く

→astahのOfficeプラグインによって、astahで描かれたモデルは、ExcelやWordに埋め込まれる。
　Officeプラグインのお陰で、astah上のモデルの変更は、ExcelやWordに同期される。

Office連携 プラグイン | Astah

②astahのGSN製品で事前に、標準プロセスを描いておき、必要なドキュメントを洗い出しておく

→astahのGSN製品から、要件定義書や設計ドキュメントの雛形を出力する
　標準プロセスに必要なドキュメントは、それぞれのWordやExeclにマッピングされ、astahのGSN製品のD-caseに対応付けられている。

→WordやExcelのドキュメントに、ソフトウェアの要件や仕様を記述していく。
　ドキュメントの中のモデルは、astahのUMLやSysMLに連動されている。

すなわち、astahのGSN製品で機能安全規格が保証された標準プロセスを構築し、その標準プロセスに対応付けられたOfficeドキュメントは、astahGSNで同期されている。
さらに、Officeドキュメントに貼られたモデルの絵は、astahファイルから参照されており、astahのモデルが変更されたら自動的に同期される仕掛けになる。

以前、astahのOffice連携プラグインを使ってみた時、このプラグインのメリットがあまり感じられなかった。
しかし、上記のような使い方をするならば、Office連携プラグインはとても重要な一機能になる。

Office連携 プラグイン | Astah

Astahプラグインの資料のリンク: プログラマの思索

【4】理論的には、上記のようなやり方で、Officeファイルの設計書・UMLやSysMLやER図やDFDなどのモデル・機能安全規格を満たす標準プロセスの3つは、全てastah製品で連携・同期・統一されることになる。

平鍋さんは、たぶんそのようなイメージでastah製品シリーズを作られたのではないか。
そう考えると、非常に上手く考えられているなあ、と感じる。

但し、上記のやり方はあくまでも理想論であり、本当にうまくいくのかは分からない。
実際のソフトウェア開発の現場における要件定義、設計の作業はもっと泥臭いし、労働集約的な作業ばかりだからだ。

たとえば、プログラム開発はGitという非常に強力な構成管理ツールがあるので、大人数の共同開発がやりやすい。
そして、Jenkinsのような強力なビルド管理ツール、Redmineのような強力なチケット管理ツールを組合せた作業環境が既に一般的だ。

一方、要件定義や設計では、astahのモデルやOffice文書は、Gitのような構成管理を行う環境があまり整っていないために、差分やマージ作業、プルリクエストのような共同作業がやりにくい。
また、モデリング作業で発生するQAや課題が発生して、それを解決して、その内容をモデルに反映していく、という一連の流れとチケット管理が、まだ上手く連動できていない。

個人的には、astahのモデル自身も、SubversionだけでなくGitで構成管理できるようにするのが1つの課題ではないか、と思う。

Subversionプラグイン | Astah

astahの品質スイートプラグインとSVNプラグインが凄い: プログラマの思索

TortoiseSVNでastahファイルのリビジョン間の差分を表示する方法: プログラマの思索

また、astahのモデルに要望や課題、仕様追加を反映していく作業と、astahのモデルの変更箇所をRedmineチケットを経由してリンクさせるような仕組みも必要ではないか、と思う。

Enterprise Architectでは、RedmineやTestLinkと連携するプラグインがあるので、astahでも実現してもいいはずだ。

Enterprise ArchitectとRedmineを連携するアドオン: プログラマの思索

TestLinkとEnterprise Architectを連携する: プログラマの思索

【5】astahには、たくさんの可能性があると思っている。
astahを使ったモデル、そのモデルを保証するプロセスの連携方法は、もっといろんなアイデアがあるはずだし、色んな実装方法があるはずだ。

近々、astahの勉強会を開くので、色々議論してみたい。

astah関西 第1回勉強会 - connpass

【追記】
似たようなことは既に他の人も考えている。

Astah*GSNより、ASCEのほうが、ビジネス的には、大きく出来る・・・ - ウィリアムのいたずらの開発日記

Astah GSNが、ＵＭＬ、SysMLと連携してほしい人！　－　いっぱい！！ - ウィリアムのいたずらの開発日記

ウィリアムのいたずらの開発日記 D-caseで検索