Pieris Books(ブックカフェ併設のセレクトショップ販売店)のシステム開発のプロジェクトを進めています。
要求モデルをCozyモデルとして定義する方法について考えています。
ユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行い、CML(Cozy Modeling Language)で記述する方法について考えました。
今回からシナリオ記述のCML文法について考えていきます。
今回はtユースケース記述の基本フォーマットです。
ユースケース記述の基本フォーマット
ユースケース記述では、シナリオを時系列のステップとして記述するシナリオ記述が必要となります。
この目的のシナリオ記述のCMLは以下のものになります。「会議室を予約する」の節には基本情報、拡張方法などが定義されますが省略しています。
# UseCase ## 会議室を予約する ### MainFlow - [open] 社員: システムを開き、「会議室予約」メニューを選択する。 - システム: 予約可能な会議室一覧を表示する。 - [select] 社員: 希望する日時と会議室を選択する。 - [check] システム: 選択された会議室の空き状況を確認する。 - 社員: 会議の目的と参加者を入力し、予約を確定する。 - [confirm] システム: 予約を登録し、確認メッセージを表示する。 - end ### AlternateFlow A1. [check] 会議室が満室の場合 - システム: 「選択された時間帯は満室です」と表示する。 - 社員: 別の会議室または時間帯を選択する。 - システム: 新しい候補を再表示する。 - goto select A2. [select] 日時が未指定の場合 - システム: 「日時を入力してください」とメッセージを表示する。 - 社員: 日時を入力し、再度会議室を選択する。 - goto select A3. [confirm] 予約完了後に内容を変更したい場合 - 社員: 「予約一覧」から対象の予約を開く。 - call ModifyReservation ### ExceptionFlow E1. [confirm] データベースエラーが発生した場合 - システム: エラーログを記録する。 - システム: 「予約を登録できませんでした」とエラーメッセージを表示する。 - abort E2. [open] セッションがタイムアウトしていた場合 - システム: ログイン画面にリダイレクトする。 - 社員: 再度ログインしてから操作を続行する。 - goto open
文法の説明
ステップの文法
| 要素 | 説明 | 例 |
|---|---|---|
- | ステップを表すリストマーカー。1行に1ステップを記述する。 | - [open] 社員: システムを開く。 |
[id] | ステップの識別子（省略可）。他のフローから参照可能。 | [select], [check] |
actor: | ステップの実行者（省略可）。主に「社員」「システム」など。 | 社員:, システム: |
action | 自然言語による行動・応答の記述。 | 会議室一覧を表示する。 |
directive | フロー制御のための命令文。整形時に自然文化される。 | goto select, abort, end |
- ステップはユースケースの基本的な単位である。各行の
-から始まる文は、ユースケースの中で行われる一つの行動または反応 を表す。それは「誰が何を行うか」を記述するための最小構成要素である。
[id]はステップの恒久的識別子である。ステップに付与された[id]は、他のフロー（AlternateFlowやExceptionFlow）から参照するための安定した論理的ラベルとして扱われる。ステップ番号ではなく識別子を用いることで、将来的な編集（挿入・削除）に強くなる。
actor:は行為主体を示す。これはシナリオの主語に相当し、通常は「ユーザ」または「システム」である。省略された場合は、文脈（前のステップやUseCase全体のactor）から推定される。
actionは自然言語での行動・応答の記述である。行動（Actorの操作）と応答（Systemの出力）を同一形式で表現できる。文体は「〜する」「〜を表示する」といった手続的な叙述形式で統一するのが望ましい。
directiveは制御的命令として扱う。goto,call,end,abortなどはシナリオの制御フローを明示する命令であり、整形段階で自然文（例：「処理は id に戻る。」）に展開される。これにより、読みやすさと機械可読性の両立が実現される。
- 構造上の意味各ステップは
UseCaseScenarioの中で順序を持つ要素であり、Cozyモデル上ではUseCaseStepエンティティとして表現される。この構造により、シーケンス図生成やテストケース展開などへの転用が可能となる。
代替フローの文法
| 要素 | 説明 | 例 |
|---|---|---|
### AlternateFlow | セクション見出し。代替フローの開始を示す。 | ### AlternateFlow |
A1. | 代替フローの識別子（A＋番号）。 | A1. |
[ref] | 分岐元となるMainFlowステップの識別子。 | [check], [select] |
| 条件文 | 代替フローが発生する条件を自然文で記述する。 | 会議室が満室の場合 |
| ステップ列 | 代替フロー内での処理をステップ構文で記述する。 | - システム: ... |
directive | 復帰や呼出しを示す制御命令。整形時に自然文化される。 | goto select, call ModifyReservation |
- 分岐元ステップ（ref）
AlternateFlowは、指定されたMainFlowステップを起点として分岐する。例：A1. [check]はMainFlowの[check]ステップから派生。
- 条件（Condition）分岐が発生する具体的な状況を自然言語で記述する。書式上は
[ref] 条件の形をとる。
- 代替処理（ScenarioStep群）代替フロー内での詳細な行動をステップ構文で記述する。各ステップは
- [id] actor: action形式。
- 復帰点（Directive）フローの末尾で、通常
gotoディレクティブを使い MainFlow に戻る。整形時には「処理は id に戻る。」と自然文化される。
例外フローの文法
| 要素 | 説明 | 例 |
|---|---|---|
### ExceptionFlow | セクション見出し。例外フローの開始を示す。 | ### ExceptionFlow |
E1. | 例外フローの識別子（E＋番号）。 | E1., E2. |
[ref] | 対応するMainFlowステップの識別子。 | [confirm], [open] |
| 条件文 | 発生する例外やエラーの内容を自然文で記述。 | データベースエラーが発生した場合 |
| ステップ列 | 異常処理の流れをステップ構文で記述。 | - システム: エラーログを記録する。 |
directive | 終了・復帰を指示する制御命令。整形時に自然文化される。 | abort, goto open, end |
- 発生元ステップ（ref）ExceptionFlowは、指定されたMainFlowステップに対応する異常時処理を定義する。例：
E1. [confirm]は、MainFlowの[confirm]ステップでエラーが起きた場合の処理を表す。
- 条件（Condition）例外が発生する具体的な原因や状況を自然文で記述する。例：「データベースエラーが発生した場合」「認証が失敗した場合」など。
- 異常処理ステップ（ScenarioStep群）エラー検出後に実施される一連の処理（通知・再試行・停止など）を
- [id] actor: action形式で記述する。
- 終了／復帰（Directive）処理終了や再試行を示す命令を用いて、制御の戻り先または中断を明示する。整形時には「処理を中断する。」「処理は id に戻る。」などに展開される。
整形規則
シナリオ内で使用したdirectiveの整形規則です。
| 原文 | 整形出力 |
|---|---|
goto select | 処理は select に戻る。 |
call ModifyReservation | 処理は ModifyReservation を呼び出す。 |
end | 処理を終了する。 |
abort | 処理を中断する。 |
repeat open | open から繰り返す。 |
まとめ
今回はシナリオ記述の基本的なCML文法について考えました。
次回はユースケース間の関係のモデルについて考え流予定です。
投稿
