シーケンス図とアクティビティ図と状態遷移図の関係
最近、「ドメイン駆動設計」を読み直しているうちに、昔のオブジェクト指向設計の本「実践UML
」「ユースケース駆動開発実践ガイド
」「オブジェクト開発の神髄
」も一緒に読み直している。
すると、今まで当たり前と思っていたUMLのテクニックについて、いくつか気づき直す点があった。
シーケンス図とアクティビティ図と状態遷移図の関係について、以下にまとめてみた。
【1】僕が開発プロセスや業務フローを分析するとき、シーケンス図とアクティビティ図と状態遷移図を書く場合が多い。
普通は、astahで、シーケンス図とアクティビティ図と状態遷移図を書く。
IT業界に初めて入った時、オブジェクト指向設計が一番、という雰囲気で育ち、Javaプログラマでずっと仕事してきたから、UMLでダイアグラムを描くのが好き。
UMLが、DFDや他の技法よりも優れている点は、一つのモデルを複数の観点のビューで表現して分析できる点だと思う。
現状の開発プロセスや業務をモデル化するとき、まずは、アクティビティ図で、アクターごとにどんな作業をやり取りしているか描く。
アクティビティ図から、どんなオブジェクトがやり取りされているか見出し、そのオブジェクトのステータスを洗い出して、ステートマシン図(状態遷移図)を描く。
オブジェクト間のメッセージのやり取りを見たいときは、シーケンス図を描く。
一つのプロセス、業務を複数の観点のビューで見ることによって、このワークフローは無駄なステータスが多い、とか、このアクター(作業者)は削除できるのではないか、とか、ここに分岐判定の別のフローが存在するのではないか、など、色んな発想を思いつくことができる。
モデリングの楽しさは、一つのモデルを徹底的に分析して、その抽象的構造から、本質を見出す所にあると思う。
「このモデルの本質は○○○という概念です」と言えればベストだと思う。
【2】「UMLによるオブジェクト指向モデリングセルフレビューノート」という本を読み直していたら、シーケンス図とアクティビティ図と状態遷移図について、次のような関係が書かれていた。
(1)ステートマシン図のイベント
⇔アクティビティ図のアクティビティ
⇔シーケンス図のメッセージ
(2)ステートマシン図のステータス
⇔シーケンス図の活性区間
(1)は、ある状態から発火して、他の状態へ移った時、イベントが生じていることを意味する。
つまり、何らかの処理が実行されたことを意味する。
すなわち、その処理は、アクティビティ図のアクティビティ、シーケンス図のメッセージに相当する。
(2)は、オブジェクトのある状態は、シーケンス図の処理の実行中に相当し、それは活性区間に相当する。
いずれも考えてみれば当たり前なのだが、こういう事実を知らずに、適当に書いていると、モデルの整合性が崩れる。
このステータスは、どうやって遷移してくるのか?
この処理は、なぜ必要なのか?
この処理は、ステートマシン図のどのイベントに対応するのか?
モデルについて自問自答すると、最初に描いていたモデルには漏れが多い。
1個のダイアグラムだけ描いただけでは、その漏れに気づきにくいが、1個のモデルを複数の観点で描いてみると、不自然さに気づきやすくなる。
【3】実際のプログラミングでは、シーケンス図がきちんと書ければ、即座にプログラムになる。
つまり、シーケンス図は昔のプログラム設計、詳細設計に相当する。
しかしながら、僕は、ステートマシン図が結構重要だと思っている。
特にオブジェクト指向でプログラミングしている時、オブジェクトの状態は何種類あるのか、その状態はどんな条件で発火して他の状態へ移るのか、を意識しなければ、If文の多いスパゲティ状態になりやすい。
なぜなら、IF文の分岐条件に普通は、オブジェクトがどの状態にあるか、という判定条件が入るからだ。
【4】UMLを書く場合、astahが個人的には使いやすい。
astahで面白そうと思った点は、シーケンス図、アクティビティ図、状態遷移図、クラス図などの要素に「図要素・モデル」を紐づける機能がある点だ。
例えば、astahの要求図に書いた要求にシーケンス図のメッセージ、アクティビティ図のアクティビティなどを紐づければ、トレーサビリティをツール上で表現できる。
astahには、トレーサビリティマトリクスを出力する機能があるので、この機能を使って、上流工程の要求から下流工程のシーケンス図へどのようの反映されているのか、を追跡することができる。
(これは後方追跡性に相当する)
逆にシーケンス図の処理は、どの要求から派生して実装されたのか、も追跡できる。
(これは前方追跡性に相当する)
RedmineとSVM連携、Git連携の運用で気づいたことは、トレーサビリティがソフトウェア開発ではとても重要であること。
トレーサビリティが保障されていれば、過去のパッチの修正理由を理解しやすくなるし、ソース修正の影響箇所を調査しやすくなるし、リバースエンジニアリングもやりやすくなる利点がある。
本来は、モデルという上流工程の成果物でトレーサビリティを実現したいのだ。
このアイデアについても考えてみる。
| 固定リンク
「モデリング」カテゴリの記事
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
- 超高速開発でアジャイル開発を実現する話に違和感がある(2022.05.06)
- 事業活動のシステム化は非差別化しない汎用ドメインや支援ドメインに注力すべき(2022.04.13)
- 「大国政治の悲劇」の感想~現代はパワーポリティクスの歴史に戻ったみたいだ(2022.03.25)
- マイクロサービスはアトミックな操作で閉じるべきシステム分割論に基づいたアーキテクチャなのか(2022.03.20)
「astahによるUMLモデリング」カテゴリの記事
- 組込みソフトウェア開発でUMLを使う手法を説明した書籍のリンク(2022.06.17)
- 知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る(2022.04.26)
- ITの地殻変動はどこで起きているのか?~今後の課題はソフトウェア事業におけるエージェンシー問題を解決すること(2022.01.01)
- チケット駆動開発のプロセスと開発基盤を再考する #Redmine(2022.01.01)
- リーダーシップの要は抽象的思考とトレードオフだ(2021.12.26)
コメント