プログラマの思索

astahを使いながら、モデルの粒度とトレーサビリティのあるべき姿について考えたことをメモ。
以下は、最終的には、astahへの改善要望になるだろう。
ラフなメモ書き。

【参考】
astahによるモデリングのメモ: プログラマの思索

派生開発における変更指示をモデルで表現する（問題編） - Qiita

【1】個人的には、astahは好きだ。

astah* オンラインマニュアル

理由は2つある。
一つ目は、他のモデリングツールに比べて、操作が直感的でサクサク描けるから。
astahでUMLのダイアグラムを書く時に、迷うことがないし、サクサク描けるので、アイデアが無くなることも少ない。
一方、他のモデリングツールでは、UMLの各種ダイアグラムを描く時に、どうやって書けばいいんだっけ、と迷う時間が多いと、その間にアイデアは消えてしまう。
また、線を引っ張る時、保存する時にプログレスバーが出て待たされるようでは、イライラしてしまう。

二つ目は、一つのモデルを複数の観点で分析する考え方が自然に身につくことだ。
UMLでは約7種類、他にER図やDFD、マインドマップもあるので、一つのシステム像を表現したい時、静的なモデルだけでなく、動的なモデル、物理的な配置図、論理的なモデル、DOA的な視点、などでも自然に考えるようになる。
複数の観点でシステムの要件や機能を考えることによって、モデルの整合性やトレーサビリティにも気づきやすくなる。

そんな経験をしながら、モデリング技法のあるべき姿について考える時がある。
astahで色々書いていると、まだ何か足りない気がしてくるのだ。

【2】では、astahでモデルを書いていて、何が足りないと感じるのか？
不足していると感じる観点は、モデル間のトレーサビリティと粒度、変更管理に関する内容だ。

【2-1】モデル間のトレーサビリティ

たとえば、要件定義フェーズで、業務フローをアクティビティ図で描いて分析したら、その後、どこをIT化すべきか、という方向に分析が進む。
すると、業務フロー図に出てくるアクターがシステムである箇所で、アクティビティがあれば、そのアクティビティがユースケースに対応付けられる。
それらユースケースを集めると、ユースケース図になり、システムの全体像が定まる。

つまり、業務フローの各アクティビティ→ユースケースへの詳細化が後方追跡性に相当する。

また、各ユースケースは、論理モデルや実装モデルの観点で、クラス図やシーケンス図に分解されていく。
つまり、ユースケース図の各ユースケース→クラス図、シーケンス図への詳細化という後方追跡性が発生する。

しかし、アクティビティ図→ユースケース図→クラス図、シーケンス図へトレーサビリティが発生するのに、それらモデルのトレーサビリティを表現する方法がastahでは直感的に表現されていない。

モデラーの観点では、アクティビティ図のアクティビティをクリックしたら、対応するユースケースに遷移して、さらにユースケースをクリックしたら、対応するクラス図やシーケンス図を選択して表示される、という利用シーンを実現して欲しい。
そうすれば、要件定義→設計へモデルが詳細化されていく作業をトレーサビリティの機能によって補完することができる。

では、なぜそんなにトレーサビリティが必要なのか？
なぜなら、モデル間のトレーサビリティを考えることで、モデル要素の漏れや矛盾に気づきやすくなり、モデルの精度を上げられるからだ。
おそらくどのモデラーも、概要レベルのモデルを描いた後で、詳細化したモデルは別に描き、それらの整合性をどこかで考えているはず。
そういうモデル間の整合性を考える作業を支援する機能が欲しいのだ。

一方、現状のastahでトレーサビリティに相当する機能は、ハイパーリンク機能に相当するだろう。
つまり、モデル要素のリンク機能で十分だ。
モデル要素をクリックしたら、別のモデルへ遷移するように、ハイパーリンク情報を設定すればいい。

しかし、ハイパーリンク情報を設定するには、詳細画面を開き、遷移先のモデルを選択して更新する、という操作が発生し、とても面倒。
この操作を1クリックで操作できるようにしたい。
つまり、遷移元のモデル要素（ダイアグラム）を遷移先のモデル要素にドラッグ・アンド・ドロップすると、自動で相互リンクするようにハイパーリンク情報が設定される、といったイメージだ。
たとえば、アクティビティ図にあるアクティビティをドラッグして、ユースケース図へドロップすると、相互リンクが設定される、というイメージ。

すなわち、ハイパーリンク機能を流用したトレーサビリティの実現は、そんなに難しくないだろうと思うし、その効果はすごく大きいだろう、と考えている。

なお、モデラーの観点では、トレーサビリティの制御は手動の設定で十分だ。
ラフなスケッチでモデルをたくさん描いていくので、そんなに難しい機能は必要ないから。

【2-2】モデル間のレイヤ化、モデル間の粒度

業務システムの設計を開始すると、サブシステムの観点で、作ったモデルをグルーピングして整理したくなってくる。
たとえば、ECサイトなら、注文システム、商品検索システム、バックエンドのマスタ管理システムなど。
すると、普通は、パッケージをフォルダ代わりに使ってモデルをグルーピングして、モデルをどんどん深掘りしていく。
つまり、パッケージによるグルーピングは、モデルの粒度を揃えて整理する作業に相当する。

しかし、astahではパッケージ図でモデルをまとめた時に、モデルの内容が表示されないし、モデルへリンクする機能がない。
モデラーの観点では、パッケージ図に、パッケージでまとめたモデル名(ダイアグラム)が表示され、表示されたモデル名をクリックすると遷移する、という機能が欲しい。
そうすれば、モデルの粒度を揃えながら、モデルのトレーサビリティ機能を使って、モデルの漏れや整合性を考えやすくなる。

なぜ、モデルのグルーピング後のリンク機能が必要なのか？
なぜなら、モデルの粒度を揃えながら、モデルをレイヤ化する作業を行い、各レイヤ間のモデルのトレーサビリティを考えることで、モデルの精度を上げようとしているからだ。
こういうレイヤ化の作業は、設計作業だけでなく、プログラミングにおいても普通に行われている。
レイヤを一つ増やすことで、絡み合った仕様を整理し、ソフトウェアの複雑さを軽減していく手法は非常に重要だし、モデリングツールがそういう作業を支援するようにして欲しい。

しかし、astahではパッケージ図があるものの、EnterpriseArchitectのように、パッケージにモデル要素を表示してリンクする機能がないので、レイヤ化や粒度による整理がやりにくい。
逐一、構造ツリーでポチポチ開いて確認するしかない。
こんなイメージ。

ビュー

なお、現状のastahでは、パッケージやパッケージ図そのものにもハイパーリンク機能があるので、相互リンクさせることは可能だ。
但し、トレーサビリティの相互リンクと同じく、操作回数が多いので、イライラしてしまう時がある。

Enterprise Architectにはこの機能はあるので、astahにあともう少し機能があれば、という所だろう。

追跡(トレーサビリティ) - Enterprise Architect 13.5 日本語版 ヘルプ

ダイアグラムのトレーサビリティについて　スパークスシステムズジャパン フォーラム - ユーザー掲示板

【2-3】モデルの変更管理と構成管理

要件定義では、顧客打合せをしながら、要件や仕様をモデルに反映していく。
その反映作業は、ソースにパッチを当てていく感覚と同じだ。
そして、モデルへのパッチ当ての作業は、行ったり来たりする場合も多い。
顧客の要望、実現すべき機能、実装可能な技術の選択、スコープと納期・コストとのトレードオフを考慮しながら、要件を固めていくので、手戻りはよく発生する。

この作業中に、当初作られたモデルはたくさんのパッチが当てられて、どんどん変化していく。
これがソースコードならば、Gitで構成管理されるので、変更理由のRedmineチケットと相互リンクされてどんどんコミットされていく。
そのコミット履歴から、ソースコードの変更箇所が特定できるし、どういう変更の経緯から発生したのか、という変更理由もチケットから辿ることができる。

しかし、モデルは普通は構成管理されていないので、変更履歴が残っていない。
モデルをGitで管理したとしても、差分箇所を表示できないので、日次バックアップにしか過ぎない。

また、各モデルが変更された時に、どんな変更理由で変わったのか、というRedmineチケットとモデルが相互リンクされていない。
よって、なぜモデルのこの部分が変わったのか、という理由を、後から辿ることが難しい。

本来は、モデルであろうとも、Git等の構成管理ツールの配下におき、変更履歴を管理し、チケット経由でトレーサビリティを実現したい。
しかし、その手法が現実的でないならば、せめて、モデルのメタ情報に、変更が発生したチケットNoを埋め込んでリンクする機能が欲しい。

そういう機能がないと、モデルに数多くのノートが作られて、いつどんな理由で変更された、というコメントがたくさん混じりこんでしまう。
この症状は、ソースコードにガラクタのコメントがたくさん残っている状況と同じだ。
残骸となったコメントは後からリファクタリングするのが難しくなるから、そういうコメントは不要。

さらに、メリットとして、Redmine上でモデルの変更履歴を全文検索できるので、保守フェーズで別の開発者が過去の要件や仕様を探しやすくなる。
また、Redmineにモデルの変更履歴が一元管理されるので、そこから、たとえば、レビュー指摘事項の修正件数や手戻りの設計工数などのメトリクスを集計して分析することもできる。

なお、現実的な機能としては、モデルを描いた後で、astah画面右下(拡張ビュー)でチケット登録できて、登録したチケット一覧が表示される機能があればよい。
そして、拡張ビューのチケット一覧で、チケットNoを押下すると、Redmineチケットへ遷移する機能があれば十分。
実際は、RedmineのREST APIキーとURLをastahで保持しておき、astahのモデル上でチケット情報を入力したら、Redmineでチケットが新規作成されて、拡張ビューに新規チケットが表示される、という流れになるだろう。

この機能が実現できれば、モデルの変更理由の一覧がRedmineチケット一覧と同一視できるので、開発工程以後でモデルの変更理由を探す時に役立つだろう。

Enterprise ArchitectにもRedmine連携プラグインがあるので、astahでも同様に実現できるはず。

Enterprise Architect-Redmine連携アドイン

あるいは、Backlogのastahプラグインがあるので、同様にRedmineプラグインをastahで作れるはず。

Backlog Connector for astah

【3】以上をまとめると、幅・深さのトレーサビリティと変更管理という要望にまとめられる。

1)幅のトレーサビリティ→同じ粒度のモデル間のトレーサビリティ

たとえば、1つのユースケースに含まれるクラス図、シーケンス図、ステートマシン図は相互リンクで行き来できる。

2)深さのトレーサビリティ→別レイヤのモデル間のトレーサビリティ

たとえば、パッケージ図において、グループ化されたパッケージに含まれるモデルへ深掘りしながら、リンクして行き来できる。

3)モデルの変更履歴

たとえば、モデルの変更履歴は、外部サーバーにあるRedmineチケットへリンクして確認する。
つまり、モデルの変更履歴の内容は、astahのモデルそのものに書くのではなく、メタ情報として外部サーバーのRedmineへ蓄積され、参照されるようにして、モデルから分離できる。
変更履歴がモデルから分離されることで、モデルは常に最新版の状態だけ保持すればよく、シンプルなモデルになる。

【4】レイヤ化されたモデル間のトレーサビリティが強化されれば、一つの全体的なモデルとして網の目状に紐付けられた成果物になる。
そして、astahのトレーサビリティマップの機能を使えば、相互リンクで紐付けられた状況を一目で見ることも可能なはずだ。

トレーサビリティマップ 【p】

[pro] トレーサビリティマップ

最終的には、さらに、トレーサビリティマトリクスが生成できるといい。
つまり、全てのモデル間で相互リンクがあるか否かを一目で確認できるクロス集計表が出力できればいい。
この機能は、XDDPのトレーサビリティマトリクスに相当するものだろう。

ソフトウエア改造力 - 第6回　改造の影響を調べる：ドキュメントをまとめ作業計画をレビューする：ITpro

XDDP成果物：USDM、トレーサビリティマトリクス、変更設計書

『XDDP』では｢トレーサビリティマトリクス(TM)｣で変更箇所を特定

このトレーサビリティマトリクスを生成できれば、特に派生開発やソフトウェア保守で、影響箇所の調査にすごく役立つだろう。
設計フェーズの事前調査で、あらかじめ仕様変更によるモデルの影響箇所を即座に把握できるようになるからだ。

また、モデルの変更履歴がRedmineに蓄積されることで、モデルから不要なコメントがなくなり、モデルは常に最新版だけ保持されるようになる。
残骸となった変更履歴のコメントはモデルには不要。
変更履歴の内容は本来、構成管理ツールで管理すべきだからだ。

なお、トレーサビリティの設定はモデラー自身が手動で設定すればいい。
実際、RedmineとGitなどの構成管理ツール連携によるトレーサビリティも、手動でチケットNoを入力することで対応しているので、違和感はないから。

【5】以上のような事を考えると、モデリングツールはまだまだ改善の余地があるし、換言すれば、数多くの可能性を秘めているのだろうと思う。
Redmineのように、ツールを使いながらプロセスを改善していくアイデアが思いつくように、モデリングツールを使いながら設計技法を改善するアイデアは、もっとたくさん出てくると思う。