本稿では、ユースケース間の関係の一つである precedes（先行関係）を取り上げます。
precedesは、
- ユースケース同士を時間的に連結する
- シナリオを順序として構成する
ための関係です。
precedes
- マージモード : Sequence
- マージ点 : After end
- 機能 : シナリオ連結
- 由来 :
- OML（OPEN Modeling Language の precedes relationship）
- Use Case Scenario Chaining（ユースケースシナリオ連結）
- Workflow Modeling（ワークフローモデリング）
- BPMN（Sequence Flow によるプロセス連結）
- プロセス代数（逐次合成 / sequential composition）
precedesの基本方針
precedesは、
ユースケース間の実行順序を定義する関係
です。
あるユースケースの実行完了後に、別のユースケースが続いて実行されることを表します。
シナリオ技術としてのprecedes
includeやextendがユースケース内部の構造を扱うのに対し、precedesはユースケース同士を時間順に接続し、より大きなシナリオを構成するための関係です。
例えば、
- 商品を選択する
- 購入する
- 出荷する
という一連の業務シナリオは、複数のユースケースへ分割して記述できます。
precedesは、それらのユースケースを順序で接続し、シナリオ全体を構成します。
この考え方は、OMLにおける ordered use cases や use case scenario chaining の流れに位置づけられます。
したがってprecedesは、
ユースケースをシナリオ構築要素として扱うための関係
と考えることができます.
意味定義
UseCase A が UseCase B を precedes するとは、
A の完了後に B が開始される
ことを意味します。
すなわち、
- A の事後条件（Post(A)）が成立した後
- B の事前条件（Pre(B)）が評価され
- B が実行される
という流れになります。
直観的整理
- precedesは「前のユースケースが終わったら次へ進む」という関係
- フローを分割したユースケース同士をつなぐ
- ワークフロー的な連結を表現する
契約との関係
precedesはフローの関係ですが、
- Post(A) と Pre(B) の整合性
が重要になります。
望ましい条件は次の通りです。
- Post(A) が Pre(B) を満たす（または包含する）
これにより、
A の結果がそのまま B の入力条件として利用できる
という自然な連結になります。
この関係は、
- requires（事前条件）
- ensures（事後条件）
とも整合的に扱うことができます。
記述例
usecase SelectProduct pre: - 顧客がログインしている post: - 商品が選択されている
usecase Purchase pre: - 商品が選択されている post: - 注文が確定している
usecase SelectProduct precedes Purchase
このとき、
- SelectProduct の完了後に Purchase が実行される
- SelectProduct の結果（商品選択済み）が Purchase の前提条件を満たす
という関係になります。
他の関係との違い
| 観点 | include | extend | generalize | precedes |
|---|---|---|---|---|
| 対象 | フロー構造 | フロー変形 | 契約（意味） | 実行順序 |
| 本質 | 構造合成 | 条件付き拡張 | 仕様精緻化 | シナリオ連結 |
| 時間関係 | なし | 部分 | なし | あり |
precedesは、
- includeのようにフローを埋め込むのではなく
- extendのように条件分岐を行うのでもなく
- generalizeのように型関係を定義するのでもなく
ユースケース同士を時間的に直列接続する
関係です。
include / extend との使い分け
precedesとinclude / extendは混同されやすいですが、役割は明確に異なります。
基本的な整理は次の通りです。
- include / extend ：ユースケース内部の構造を扱う
- precedes ：ユースケース間の時間的関係を扱う
includeとの違い
includeは、
- フローの一部を共通化し
- ユースケースの内部に埋め込む
関係です。
したがって、
1つのユースケースの中で自然に記述される処理
に適用します。
一方precedesは、
- ユースケース同士を順序で接続する
関係であり、
処理の段階（フェーズ）として分離したい場合
に使用します。
extendとの違い
extendは、
- 条件付きでフローを追加する
- 例外やオプションを表現する
関係です。
つまり、
同一ユースケースのバリエーション
を表現するためのものです。
一方precedesは、
- 条件分岐ではなく
- 時間的な前後関係
を表現します。
使い分けの指針
次の観点で判断すると分かりやすくなります。
- 同一ユースケース内の処理か？ → include / extend
- 条件による分岐か？ → extend
- 時間的に前後する別の処理か？ → precedes
典型パターン
SelectProduct precedes Purchase
Purchase include Payment extend Coupon
Purchase precedes Shipping
このように、
- precedesで全体の流れ（段階）を構成し
- include / extendで各ユースケース内部の構造を定義する
という使い分けが自然です。
設計上の注意点
precedesを使用する際は、
- ユースケースを適切な粒度で分割すること
- PostとPreの整合性を意識すること
- 不要な細分化によってフローが分断されすぎないようにすること
が重要です。
特に、
- 1つのユースケースで表現した方が自然なもの
- 強く結合した処理
を無理に分割すると、モデルが読みにくくなります。
まとめ
precedesは、
- ユースケース同士を順序でつなぐ関係
- ワークフロー的なシナリオ連結を表現する仕組み
です。
契約（Pre/Post）と組み合わせることで、
- 状態遷移の流れ
- 処理の段階的構成
を自然に表現することができます。
include / extend / generalize とは異なり、
precedesは
時間的な連続性
を扱う関係であり、
ユースケースを組み合わせて全体シナリオを構築する際の基本的な構成要素となります。
投稿
