Cozyモデル駆動開発/ユースケース/precedes

本稿では、ユースケース間の関係の一つである 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は

時間的な連続性

を扱う関係であり、

ユースケースを組み合わせて全体シナリオを構築する際の基本的な構成要素となります。

Cozyモデル駆動開発/ユースケース/generalize-syntax

本稿では、ユースケース間のgeneralization関係を前提としたCMLの記述方法について整理します。

設計の前提

generalizationはユースケース間の関係を表すものです。

ここでは、generalizationは「関係の宣言（マーク）」として扱います。

一方で、ユースケースのフローは、include や extend などの構造によって記述します。

したがって本稿では、

• generalization（関係の宣言）
• フロー構造（実行の記述）

を明確に分離して扱います。

記述方法

基本形

# UseCase
## PurchaseOnline
### GENERALIZATION
Purchase
### INCLUDE
#### Purchase

この例では、

• PurchaseOnline が Purchase と関係を持つことを宣言し
• フローは include によって記述しています

ただし、この2つの関係は現時点では直接結びつけません。

拡張を含む場合

# UseCase
## PurchaseOnline
### GENERALIZATION
Purchase
### INCLUDE
#### Purchase
### EXTEND
#### After payment
- 配送先を登録する

この場合も同様に、

• GENERALIZATION は関係の宣言
• INCLUDE / EXTEND はフロー構造

として独立に記述します。

設計の考え方

現段階ではgeneralizationとフロー構造を過度に結び付けていません。

例えば、

• generalizationしたら必ずincludeする
• 特定のフロー構造を強制する

といったルールは導入しません。

あくまで、

• GENERALIZATION は意味の手がかり
• INCLUDE / EXTEND は実際の構造

として並置します。

今後の展開

generalizationの意味（契約、状態遷移、LSPなど）や、

• どのようなフロー構造が許されるのか
• どのような実現方法が妥当なのか

といった点については、今後段階的に整理していきます。

まとめ

本稿では、generalization関係を前提としたCML記述の基本形を示しました。

現時点では、

• GENERALIZATION は関係の宣言
• INCLUDE / EXTEND はフロー構造

として扱い、両者を独立に記述するというシンプルな方針を採用します。

この段階的なアプローチにより、

• 記述のシンプルさを保ちつつ
• 将来的な意味拡張に対応できる

構造を維持することができます。

Cozyモデル駆動開発/ユースケース/generalize-realization

Pieris Books（ブックカフェ併設のセレクトショップ販売店）のシステム開発プロジェクトを進めています。

前回は、ユースケース間の generalize（汎化）を

• 契約（Pre/Post）の包含関係
• 状態遷移断片の精緻化

として定義しました。

本稿では、その generalization をどのように実現するか、すなわち「フロー設計の戦略」について整理します。

本稿の位置づけ

前回:

• generalize = 契約関係（型）

本稿:

• generalize を満たすための実現戦略（設計パターン）

つまり、重要な前提として、

• generalizationはフローを規定しない
• しかしフローは契約を満たさなければならない

という関係にあります。この実装戦略が本稿のテーマです。

generalizationの実現戦略

generalizationは「意味の包含」であり、フローはその実現手段です。

そのため、複数の実現パターンが存在します。

本稿では代表的な3つを整理します。

• Template型
• Extension型
• Replacement型

Template型（骨格共有）

• 親ユースケースがフローの骨格を提供し、子ユースケースが一部のステップを差し替える方式

これはいわゆる Template Method に相当します。

特徴

• フローの構造は親が支配する
• 子は差分のみを定義する
• 契約との対応が明確

適用場面

• 処理手順がほぼ同じ
• 一部の処理だけ差し替えたい

例

• Purchase の中の「支払い処理」を差し替える
• PurchaseOnline / PurchaseInStore の分岐

評価

• 一貫性が高い
• 再利用性が高い
• ただし柔軟性は低い

Extension型（後付け拡張）

• 親ユースケースのフローをベースとし、子が追加ステップを挿入する方式

extendに近いが、契約レベルで整合している点が異なります。

特徴

• 親のフローをベースにする
• 子は追加責務を持つ
• 契約は強化される

適用場面

• 追加機能（ログ、通知、配送など）
• オプション的な振る舞い

例

• Purchase に対して配送登録を追加する PurchaseOnline

評価

• 柔軟性が高い
• ただしフローの一貫性は弱くなりやすい

Replacement型（全面再定義）

• 子ユースケースがフローを完全に再定義する方式

契約だけを共有し、実装は独立します。

特徴

• フローは完全に独立
• 契約のみ共通
• 最も自由度が高い

適用場面

• 実現方式が大きく異なる
• UIやチャネルが異なる（オンライン / 店頭など）

例

• Purchase と PurchaseOnline が全く異なる手順で実行される

評価

• 柔軟性が最大
• 再利用性は低い
• 設計の一貫性維持が難しい

3つの戦略の整理

観点	Template型	Extension型	Replacement型
フロー共有	高い	中程度	なし
柔軟性	低い	中	高い
契約整合	明確	明確	明確
再利用性	高い	中	低い

重要なのは、

• どの方式でも generalizationの契約制約は守られる必要がある

という点です。

まとめ

generalizationは

• 契約の関係

であり、

その実現は

• フロー設計の戦略

として分離されます。

この分離により、

• 型安全な意味定義
• 柔軟な実行設計

を両立することができます。

• Template型をDSLとしてどう表現するか
• 差分記述（override）の記法設計
• フロー合成の形式化

といった点は、

• aggregatebehavior や内部DSL

と関連しますが、具体的なアプローチを次回に取り上げる予定です。

Cozyモデル駆動開発/ユースケース/generalize

Pieris Books（ブックカフェ併設のセレクトショップ販売店）のシステム開発プロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法を検討しています。

現在はユースケース間の関係をCML（Cozy Modeling Language）でどのように記述するかという観点で整理を進めています。前回は extend を検討しました。

今回は generalize（汎化） を取り上げます。

generalize

• マージモード : TypeRefinement
• マージ点 : N/A（フロー非依存）
• 機能 : 契約包含（仕様精緻化）
• 由来 : UML generalization

generalizeの基本方針

Cozyモデルでは、ユースケース間のgeneralizationを

• ユースケース間の型的関係（契約関係）

として定義します。

具体的なフロー継承方法やsuper展開規則は、generalizationの仕様外とします。

ユースケースの意味定義

Cozyモデルでは、ユースケースを

• 状態遷移モデルの断片

とみなします。

その意味は、主に次の契約によって定義されます。

• 事前条件（Pre）
• 事後条件（Post）

ユースケース U は、

• ある状態が Pre(U) を満たすとき実行可能であり
• 実行後の状態は Post(U) を満たす

という仕様を持つものとします。

抽象状態機械は明示的には定義しませんが、

• 暗黙の抽象状態機械 ＝ ユースケース集合

という位置付けを取ります。

generalizationの定義

UseCase C が UseCase P を generalize するとは、

• C が P の契約を包含し、意味を精緻化する関係

と定義します。

具体的には、LSP（リスコフの置換原則）的に次を満たすことを要件とします。

事前条件の包含

親の事前条件を満たす状態では、子も実行可能でなければならない。

すなわち、

• C は P の事前条件を弱めない
• 子は親より実行可能範囲を狭めてはならない

事後条件の保存

子は、親が保証する結果を壊してはならない。

• C の事後条件は P の事後条件を包含するか、より強い保証を与える

直観的整理

• 親が約束することは、子でも必ず成り立つ
• 子は親より具体的であってよいが、意味を破壊してはならない

このとき、

• generalization ＝ 状態遷移断片の refinement（仕様精緻化）

とみなすことができます。

フローとの関係

前述した通りCozyモデルでは「generalizationはフローの継承方法を規定しない」というアプローチを取ります。

• MainFlowは契約を実現するシナリオである
• 契約が保持される限り、フロー構造は自由である

したがって、

• super展開の位置
• テンプレート的骨格継承
• 差分オーバーライド

といったgeneralization関係にあるユースケース間のフローの関係は仕様としては定めておらず自由な構造を選択することができます。

include / extendとの違い

観点	include	extend	generalize
対象	フロー構造	フロー変形	契約（意味）
本質	構造合成	条件付き拡張	仕様精緻化
型関係	なし	なし	あり
LSP制約	なし	なし	あり

include や extend が

• シナリオ構造の操作

であるのに対し、generalize は

• 意味（契約）の包含関係

です。

記述例

usecase Purchase pre: - 顧客が商品を選択している post: - 注文が確定している - 支払いが登録されている

usecase PurchaseOnline generalize Purchase pre: - 顧客が商品を選択している - 顧客がログインしている post: - 注文が確定している - 支払いが登録されている - 配送先が登録されている

このとき、

• 子は親の事前条件を包含し
• 親の事後条件を壊していない

ため、generalization関係が成立します。

まとめ

本稿では、generalizeを

• ユースケース間の型的関係 ＝ 契約包含関係 ＝ 状態遷移断片の精緻化

として定義しました。

generalizationは、

• フロー構造の継承を規定するものではなく
• 契約レベルでの意味関係を定義するもの

と位置付けます。

具体的なフロー実現方法（テンプレート的継承、差分オーバーライドなど）は、

• generalizationを実現するための設計戦略

として、次回検討します。

Cozyモデル駆動開発/ユースケース/extend

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

現在はユースケース間の関係のモデルについて、ユースケース間の関係のどのようにCMLで記述するか、という観点で具体的な記述方式を検討しています。前回はincludeの検討を行いました。

今回はextendを取り上げます。

extend

• マージモード : Extend
• マージ点 : 条件付きStep
• 機能 : 例外的・追加的振る舞いの付与
• UML extend

extendの意味

extendは、あるユースケースの実行中に、

• 特定の条件が成立した場合にのみ
• 追加の振る舞いが挿入される

ことを表す関係です。

UMLにおけるextendは、

• 基本ユースケースの振る舞いを前提とし
• 条件付きで拡張ユースケースが実行される

という意味を持ちます。

典型的な例としては、次のようなものがあります。

• 「商品を購入する」を拡張する「クーポン適用」
• 「会員登録」を拡張する「年齢確認」
• 「注文処理」を拡張する「高額購入時の本人確認」

extendされる側のユースケースは、

• 常に実行されるわけではなく
• 基本ユースケースの一部を補足する

という性質を持ちます。

includeとの違い

includeとextendの違いを整理すると次のようになります。

観点	include	extend
実行条件	常に実行	条件付き
主目的	共通処理の再利用	例外・オプションの追加
基本フロー	前提	独立して完結
位置づけ	合成	拡張

includeは「分解と再利用」、extendは「基本フローを壊さない条件付き拡張」と整理できます。

Cozyモデルにおけるextendの位置づけ

Cozyモデルでは、extendを

• 図上の関係指定

ではなく、

• ユースケース・シナリオ内における
• 条件付きステップ合成

として扱います。

この観点からextendは、

• 基本ユースケースを中心に据え
• 例外や追加要件を独立したユースケースとして定義し
• 条件に応じて合成する

ための仕組みと位置づけられます。

Cozyモデルにおけるextendは、

• 条件付きでステップ列を合成する関係

として捉えることができます。

記述方式

シナリオ中のextendの記述方式は以下の通りです。

- extend <UseCaseName> when <Condition>

• extendディレクティブで拡張であることを示します
• when句で拡張が発生する条件を明示します

条件は、業務ルールや状態など、要求レベルで意味を持つ表現を用います。

記述例

- 顧客: 商品を選択する。
- 顧客: 支払い方法を指定する。
- extend ApplyCoupon when クーポンが指定されている
- 顧客: 注文を確定する。

この記述は、

• ApplyCouponユースケースのMainFlowに定義された
• ステップ列を
• 「クーポンが指定されている」場合にのみ
• この位置に合成する

ことを意味します。

基本フロー自体はクーポンを前提とせず、拡張として自然に切り出されています。

基本方針

CMLにおけるextendは、

• 基本ユースケースの理解を妨げない
• 例外やオプションを明示的に分離する

ことを重視します。

そのため、以下の方針を取ります。

• extendは必ず条件を伴う
• 基本ユースケースは単体で完結できる
• 拡張ユースケースは意味的に独立した要求単位とする
• マージ点をステップとして明示する

これにより、

• 読めば分かる基本フロー
• 必要に応じて追える拡張

という二層構造の要求モデルを実現します。

UML extendとの対応

UML	Cozy / CML
extend関係	条件付きステップ合成
拡張ポイント	シナリオ内の明示的マージ点
条件	when句
図表現	テキストによる構造表現

UMLでは拡張ポイントという概念が図中に現れますが、Cozy/CMLではそれをステップ位置と条件として直接記述できます。

これにより、

• 抽象的な関係指定に留まらず
• 実行順・条件・意味を同時に表現できる

点が特徴です。

まとめ

今回は、ユースケース間の関係の一つであるextendについて、

• UMLにおける意味
• includeとの違い
• Cozyモデルとしての解釈
• CMLによる記述方針と具体例

を整理しました。

extendは、

• 基本ユースケースを安定させたまま
• 例外やオプション要求を切り出し
• 条件付きで合成する

ための仕組みです。

includeとextendを使い分けることで、ユースケースの振る舞いを過不足なく・構造的に記述でき、図に依存しない、意味的に明確な要求モデルを構築できます。

Cozyモデル駆動開発/ユースケース/include

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

前回はユースケース間の関係のモデルについて整理しました。

今回からユースケース間の関係のどのようにCMLで記述するか、という観点で具体的な記述方式を検討していきます。

今回はincludeを取り上げます。

include

• マージモード : Include
• マージ点 : 任意Step
• 機能 : 共通動作の再利用
• UML include

includeの意味

include は、あるユースケースが実行される際に、必ず別のユースケースの振る舞いを含めて実行することを表す関係です。

UML における include は、

• 元ユースケースの処理の途中に
• 常に同一の共通処理が組み込まれる

という意味を持ちます。

典型的な例としては、次のようなものがあります。

• 「商品を購入する」が「在庫確認」を含む
• 「会員購入」が「ログイン処理」を含む
• 「注文処理」が「本人確認」を含む

include される側のユースケースは、単独で完結する利用を想定しない点が重要です。共通処理を再利用するための、意味的に独立した単位として定義されます。

Cozyモデルにおける include の位置づけ

Cozyモデルでは、ユースケースを単なる図形要素ではなく、

• 構造化された要求
• ステップ列として表現される振る舞い
• 再利用可能な意味単位

として扱います。

この観点から include は、

• 共通処理をコピーするのではなく
• 振る舞いを独立したユースケースとして切り出し
• 必要な箇所に合成する

ための仕組みと位置づけられます。

Cozyモデルにおける include は、

• ユースケースのステップ列を、別のユースケースのステップ列に合成する関係

として捉えることができます。

記述方式

シナリオ中のincludeの記述方式は以下の通りです。

- include <UseCaseName>

includeディレクティブを指定してincludeステップであることを示します。includeの次にあるのがincludeするユースケース名です。

記述例

- [select] 社員: 希望する日時と会議室を選択する。
- include CheckAvailability
- 社員: 会議の目的を入力する。

この記述は、

• CheckAvailability ユースケースの MainFlow に定義された
• ステップ列を
• この位置に展開・合成する

ことを意味します。

基本方針

CML において include は、ユースケース間の外部的な関連としてではなく、

• ユースケース定義の内部に
• 明示的な合成指示として

記述する方針を取ります。

このとき、以下の点を重視します。

• include は方向を持つ
• include されるユースケースは再利用単位である
• マージ点（どのステップに含めるか）を明確にできる

UML include との対応

UML	Cozy / CML
include 関係	ステップ合成
共通処理	再利用ユースケース
図による表現	テキストによる構造表現
実行時に必須	常に合成される振る舞い

UML で矢印として表現されていた include 関係を、CML ではユースケース内部の構造として記述する点が特徴です。

UMLの場合、概念的に指定されたユースケースを取り込むというところまでの指定になりますが、その具体的な実現をCozy/CMLではユースケース・シナリオで行うことができる分けです。

まとめ

今回は、ユースケース間の関係の一つである include について、

• UML における意味
• Cozyモデルとしての解釈
• CML による記述方針と表現方法

を整理しました。

include は、共通動作の再利用を目的とし、ユースケースのステップ列を合成する関係として扱うことで、図に依存しない、意味的に明確な要求モデルを記述できます。

次回も引き続いてユースケース間の関係について具体的な記述方式について考えます。

Cozyモデル駆動開発/ユースケース・モデル間の関係

Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。

要求モデルをCozyモデルとして定義する方法について考えています。

ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。

前回はユースケース記述の基本フォーマットについて考えました。

今回からユースケース間の関係のモデルについて考えていきます。

ユースケース間の関係の候補

CMLに取り入れるユースケース間の関係の候補を表にまとめました。表中のREはRequirement Engineeringを示します。

関係	マージモード	マージ点	機能	由来
include	Inline	任意Step	共通動作の再利用	UML include
extend	ConditionalInline	After指定	条件付き拡張	UML extend
generalize	Inherit/Override	Override	シナリオ継承	UML generalization
precedes	Sequence	After end	シナリオ連結	Workflow / BPMN
triggers	EventDriven	After condition	イベント駆動	Event-driven modeling
requires	Prepend	Before start	事前条件統合	RE preconditions
ensures	Append	After end	事後条件統合	RE postconditions
collaborates	Parallel	同期点	並行・協調動作	Workflow patterns
conflicts	Branch	条件分岐	排他シナリオ	Goal/Feature modeling
supersedes	Replace	Full	上書き置換	Scenario evolution
references	ReferenceOnly	N/A	ドキュメント参照	Traceability

伝統的な手続き型の処理に加えて、イベント駆動による処理についてもモデル化できることを目標にしています。

ユースケース関係の由来

候補としてまとめたユースケース間の関係の、意味上のマージ方式・シナリオ統合のふるまい・歴史的な由来に基づき関係を分類します。

UML系統

• include
• extend
• generalize

UMLユースケースの主要関係に由来します。SimpleModelingではより厳密な意味統合として再解釈する予定です。

Workflow / BPMN 系統

• precedes（順次）
• collaborates（並行・同期）

ワークフローパターンおよびBPMNゲートウェイの意味モデルに対応します。

Event-driven 系統

• triggers

外部イベントや条件成立によってシナリオが起動する関係を示します。

Requirements Engineering 系統

• requires（事前条件）
• ensures（事後条件）

要求工学の前後条件モデルを、流れとして統合できるよう拡張します。ユースケース記述の項目とユースケース図の2つの観点で検討を進める予定です。

Goal / Feature モデリング系統

• conflicts（排他・競合）

KAOS(要求工学の代表的なゴール指向モデリング手法)などのゴール競合、Feature ModelのXOR制約への対応について検討します。

シナリオ進化系統

• supersedes（置換）

シナリオの置換は要求工学やUPでも出てくる概念ですが、ユースケース・モデルにおけるユースケース関係として定義されていません。CMLでのサポートの有無を含めて検討予定です。

トレーサビリティ系統

• references

モデルの管理上、使用する可能性のある関係です。CMLでのサポートの有無を含めて検討予定です。

まとめ

今回はユースケース間の関係について整理しました。

次回から、それぞれの関係についてユースケース記述やシナリオでの記述方式について検討します。