astahでモデルを整理するにはクラスやユースケースの配下にモデルを置く

知人と議論しながら、astahでモデルを整理する方法について、考えたことをメモ。

astahのようなモデリングツールでモデルを書いていると、1個のファイルに何十個ものダイアグラムをたくさん書いて残したくなる。
たとえば、案件で分析フェーズのモデルと、詳細フェーズのモデルは観点や粒度が違うので、それぞれのモデルを区別して管理したい。
さらに、分析モデルと実装モデルをリンクするなどして、関連付けもしたい。

あるいは、複数個の案件を並行で担当していたら、それぞれの案件のモデルを区別して管理し、場面ごとに書き分けたい。
あるいは、過去の案件のモデルを参考にして、別のモデルを描くこともやりたい時もある。

今までの僕は、astahのパッケージを使って、Windowsのエクスプローラみたいに、フォルダ構造でツリー化してモデルを分けていた。
だから、詳細フェーズのモデルはツリー構造が深くなり、探しにくくなったり、分析モデルとの関連付けがやりにくいデメリットを感じていた。

モデリングツールで、たくさんのモデルをどのように管理していくべきなのか、色々考えていた。

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

知人から教わったことは、astahのクラスの配下に、クラス図やシーケンス図、ステートマシン図を置けること。
同様に、アクター、ユースケース、インターフェイスの配下にも、各種ダイアグラムを置くことができる。
最も驚いたのは、クラスのメソッドの配下にシーケンス図やアクティビティ図を配置できたことだ。

この機能の意味は直感的に分かる。
たとえば、ステートマシン図は、1つのオブジェクトがどのような状態に移るのか、を表しているので、1つのクラスに関連付けられる。
よって、ステートマシン図は、クラスの配下に置くべきだし、その方が直感的に理解しやすい。

たとえば、1個のユースケースに対し、ユースケース記述で業務フローを書くだけでなく、アクティビティ図で描いた場合、ユースケースの配下にアクティビティ図を配置すべきだし、その方が直感的に理解しやすい。

同様に、シーケンス図はクラスの１メソッドの流れを書いたものだから、クラス＞操作の配下に置くべきだ。

そういう考え方を徹底すると、下記のようなモデル操作ルールが出来上がるだろう。

(1)分析フェーズでは、ユースケース図を描いて、登場人物とその利用シーンを洗い出す。
　ユースケース１個に対し、業務フローをアクティビティ図で描いて、そのアクティビティ図はユースケースの配下に置く。

(2)分析フェーズでは、概念モデルのクラス図を描いて、必要なクラスを洗い出す。
　クラス１個に対し、オブジェクトの状態遷移はステートマシン図で描いて、そのステートマシン図はクラスの配下に置く。
　クラスのメソッド１個に対し、メソッドの詳細はシーケンス図で描いて、そのシーケンス図はクラスのメソッドの配下に置く。

これにより、ユースケース図＞アクティビティ図、クラス図＞ステートマシン図・シーケンス図、というモデルの構造が全て階層化できることになる。
この階層化は、各ダイアグラムがどのオブジェクト（ユースケース）の詳細を示しているのか、を明示しているので、一貫した意味でモデルを整理できていることになる。

できれば、astah上で、こういう階層構造とともに、クラス（ユースケース）とダイアグラムの間で相互リンクできれば、要件からモデルまでのトレーサビリティが実現されるので、モデルの意味がより理解しやすくなるはずだ。

モデリングツールの新機能が、モデラーの設計技術を支援するだけでなく、モデラーの思考を刺激して新たな発想を生み出す。
そういう刺激を求めて、モデリングツールのあるべき姿を色々考えてみる。