カラーUMLによるモデリング

ちょっと古い本（かつ絶版・・）だけど、

Javaエンタープライズ・コンポーネント―カラーUMLによるJavaモデリング

を読みながら、まとめ＆考えたことをメモ。（※「考えたこと」は、【コメント】タグ等で表記。）
ちなみに、本のタイトルは内容を正確に表していないように思う。アーキテクチャとその表現について説明し、それらを活用したコンポーネントのカタログを示した本という理解。

アーキタイプの種類

• 瞬間ー時間間隔(moment-interval)アーキタイプ（カラー：ピンク）
  • ビジネスまたは法的な理由から、取り扱いと追跡を必要とし、瞬間か時間間隔の中で発生する
  • 例えば、販売、貸し出しなど
• 役割(role)アーキタイプ（カラー：黄色）
  • 人、場所、物による参加の方法
• 説明(description)アーキタイプ（カラー：青）
  • 何度でも適用できる値のまとまりである、カタログ的な説明
• パーティ／場所／物（party/place/thing）アーキタイプ（カラー：緑）
  • 別個の役割を果たす誰かまたは何か
  • 【コメント】「資源」と言えばよいかな

クラス図とシーケンス図の動的な側面

• クラス図は、暗黙的に動的である
  • アーキタイプには、典型的な相互作用が含まれる
• シーケンス図は、明示的に動的である

【コメント】

■クラス図は暗黙的に動的である
「クラス図が暗黙的に動的」とは、クラス図を指でなぞって、シナリオに沿って説明する状況を思い起こせばイメージしやすい。これは以下の状況で有効。

• モデル作成時（「瞬間-時間間隔」からモデリングを始める）
• モデルの検証／合意時（クラスをシナリオに沿って読んでいくことで検証し、関係者で合意する）

なお、関連名により相互作用を簡易に（？）表現できる。

■詳細な相互作用の表現には限界がある
ただし、相互作用の表現が暗黙であるため、

• 何をトリガー（＝ユースケース）にするのか
• どこから開始し、どう辿っていくのか

等の詳細は表現しづらいため、ロバストネス図やシーケンス図で補完する。ただし、クラス図が完成したらロバストネス図やシーケンス図は捨てるという選択肢あってもよい。

■相互作用を意識することにより、クラス図が生気を帯びてくる
そう、クラス図は生きているし、分かり易い。エンドユーザとクラス図で会話するのは難しいと思っていたけど、アプローチを誤っていたのかも。