シーケンス図とアクティビティ図と状態遷移図の関係

最近、「ドメイン駆動設計」を読み直しているうちに、昔のオブジェクト指向設計の本「実践UML」「ユースケース駆動開発実践ガイド」「オブジェクト開発の神髄」も一緒に読み直している。
すると、今まで当たり前と思っていたUMLのテクニックについて、いくつか気づき直す点があった。
シーケンス図とアクティビティ図と状態遷移図の関係について、以下にまとめてみた。

シーケンス図とアクティビティ図と状態遷移図 from akipii Oga

【1】僕が開発プロセスや業務フローを分析するとき、シーケンス図とアクティビティ図と状態遷移図を書く場合が多い。
普通は、astahで、シーケンス図とアクティビティ図と状態遷移図を書く。

IT業界に初めて入った時、オブジェクト指向設計が一番、という雰囲気で育ち、Javaプログラマでずっと仕事してきたから、UMLでダイアグラムを描くのが好き。

UMLが、DFDや他の技法よりも優れている点は、一つのモデルを複数の観点のビューで表現して分析できる点だと思う。

現状の開発プロセスや業務をモデル化するとき、まずは、アクティビティ図で、アクターごとにどんな作業をやり取りしているか描く。
アクティビティ図から、どんなオブジェクトがやり取りされているか見出し、そのオブジェクトのステータスを洗い出して、ステートマシン図(状態遷移図)を描く。
オブジェクト間のメッセージのやり取りを見たいときは、シーケンス図を描く。

一つのプロセス、業務を複数の観点のビューで見ることによって、このワークフローは無駄なステータスが多い、とか、このアクター(作業者)は削除できるのではないか、とか、ここに分岐判定の別のフローが存在するのではないか、など、色んな発想を思いつくことができる。
モデリングの楽しさは、一つのモデルを徹底的に分析して、その抽象的構造から、本質を見出す所にあると思う。
「このモデルの本質は○○○という概念です」と言えればベストだと思う。

【2】「UMLによるオブジェクト指向モデリングセルフレビューノート」という本を読み直していたら、シーケンス図とアクティビティ図と状態遷移図について、次のような関係が書かれていた。

(1)ステートマシン図のイベント
⇔アクティビティ図のアクティビティ
⇔シーケンス図のメッセージ

(2)ステートマシン図のステータス
⇔シーケンス図の活性区間

(1)は、ある状態から発火して、他の状態へ移った時、イベントが生じていることを意味する。
つまり、何らかの処理が実行されたことを意味する。
すなわち、その処理は、アクティビティ図のアクティビティ、シーケンス図のメッセージに相当する。

(2)は、オブジェクトのある状態は、シーケンス図の処理の実行中に相当し、それは活性区間に相当する。

いずれも考えてみれば当たり前なのだが、こういう事実を知らずに、適当に書いていると、モデルの整合性が崩れる。

このステータスは、どうやって遷移してくるのか？
この処理は、なぜ必要なのか？
この処理は、ステートマシン図のどのイベントに対応するのか？

モデルについて自問自答すると、最初に描いていたモデルには漏れが多い。
1個のダイアグラムだけ描いただけでは、その漏れに気づきにくいが、1個のモデルを複数の観点で描いてみると、不自然さに気づきやすくなる。

【3】実際のプログラミングでは、シーケンス図がきちんと書ければ、即座にプログラムになる。
つまり、シーケンス図は昔のプログラム設計、詳細設計に相当する。

しかしながら、僕は、ステートマシン図が結構重要だと思っている。
特にオブジェクト指向でプログラミングしている時、オブジェクトの状態は何種類あるのか、その状態はどんな条件で発火して他の状態へ移るのか、を意識しなければ、If文の多いスパゲティ状態になりやすい。
なぜなら、IF文の分岐条件に普通は、オブジェクトがどの状態にあるか、という判定条件が入るからだ。

【4】UMLを書く場合、astahが個人的には使いやすい。

astah* UMLモデリングツール | Astah

astahで面白そうと思った点は、シーケンス図、アクティビティ図、状態遷移図、クラス図などの要素に「図要素・モデル」を紐づける機能がある点だ。
例えば、astahの要求図に書いた要求にシーケンス図のメッセージ、アクティビティ図のアクティビティなどを紐づければ、トレーサビリティをツール上で表現できる。

astahには、トレーサビリティマトリクスを出力する機能があるので、この機能を使って、上流工程の要求から下流工程のシーケンス図へどのようの反映されているのか、を追跡することができる。
(これは後方追跡性に相当する)

逆にシーケンス図の処理は、どの要求から派生して実装されたのか、も追跡できる。
(これは前方追跡性に相当する)

RedmineとSVM連携、Git連携の運用で気づいたことは、トレーサビリティがソフトウェア開発ではとても重要であること。
トレーサビリティが保障されていれば、過去のパッチの修正理由を理解しやすくなるし、ソース修正の影響箇所を調査しやすくなるし、リバースエンジニアリングもやりやすくなる利点がある。
本来は、モデルという上流工程の成果物でトレーサビリティを実現したいのだ。

このアイデアについても考えてみる。