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

本稿では、ユースケース間の関係の一つである triggers（トリガ関係）を取り上げます。

triggersは、

• あるユースケースの実行や状態変化をきっかけにする
• 条件が成立した後に別のユースケースを起動する
• 同期的な手順ではなく、イベント駆動の連携として表現する

ための関係です。

triggers

• マージモード : EventDriven
• マージ点 : After condition
• 機能 : イベント駆動
• 由来 :
  • Event-driven modeling
  • Domain event
  • Reactive system
  • Workflow event handling

triggersの基本方針

triggersは、

ユースケース間のイベント駆動の起動関係を定義する関係

です。

あるユースケースの途中または完了後に、特定の条件が成立したとき、その条件をイベントとして扱い、別のユースケースを起動することを表します。

precedesが「Aの後にBを行う」という順序関係であるのに対し、triggersは「Aによって発生した事実がBを起動する」という関係です。

したがってtriggersでは、

• AとBを直列手順として密結合しない
• Bの起動条件をイベントとして明示する
• Bが同期的に起動されるか非同期に起動されるかは実行設計で決める

という整理になります。

シナリオ技術としてのtriggers

includeやextendがユースケース内部の構造を扱い、precedesがユースケース間の順序を扱うのに対し、triggersはユースケース間の反応関係を扱います。

例えば、Pieris Booksで次のような業務を考えます。

• 注文が確定する
• 在庫引当が必要になる
• 顧客へ確認メールを送る
• 配送準備を開始する

これらは「注文確定の後に必ず同じ手順で直列実行する処理」としても書けます。しかし、実際には注文確定という出来事を契機に、複数の後続処理がそれぞれ起動されると考えた方が自然な場合があります。

triggersは、このような

ある出来事に反応して別のユースケースが起動する構造

を表現します。

意味定義

UseCase A が UseCase B を triggers するとは、

A の実行中または完了後に条件 C が成立したとき、B の起動イベントが発生する

ことを意味します。

すなわち、

• A の実行により事実や状態変化が発生する
• その事実が条件 C を満たす
• 条件 C の成立をイベントとして扱う
• イベントによって B が起動候補になる

という流れになります。

ここで重要なのは、triggersが「Bを手続き的に呼び出す」関係ではないことです。

triggersは、

イベント発生とユースケース起動の関係

をモデル上で明示するための関係です。

直観的整理

• triggersは「この出来事が起きたら、このユースケースが動く」という関係
• 順序そのものではなく、起動条件を表現する
• 後続処理をイベント駆動で分離する
• 複数のユースケースが同じイベントに反応してもよい

契約との関係

triggersでは、起動元ユースケースの事後条件と、起動先ユースケースの事前条件の間に、イベント条件が入ります。

基本的には次のように整理できます。

• A の実行により Event E が発生する
• Event E が B の起動条件を満たす
• B の Pre(B) が評価される
• Pre(B) が成立すれば B が実行される

precedesでは Post(A) と Pre(B) の直接的な整合性が重要でした。一方triggersでは、

• Post(A)
• Event E
• Pre(B)

の対応を整理することが重要になります。

望ましい条件は次の通りです。

• Aの結果からイベントEが明確に導けること
• イベントEがBの起動理由として妥当であること
• Bの事前条件がイベントEまたは関連状態から満たせること

このためtriggersは、

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

を結びつける関係として扱うことができます。

記述例

usecase ConfirmOrder pre: - 注文内容が入力されている - 支払い方法が選択されている post: - 注文が確定している - OrderConfirmed が発生している

usecase ReserveStock pre: - OrderConfirmed が発生している - 注文に在庫引当対象の商品が含まれている post: - 在庫が引き当てられている

usecase SendOrderConfirmation pre: - OrderConfirmed が発生している - 顧客の連絡先が登録されている post: - 注文確認通知が送信されている

usecase ConfirmOrder triggers ReserveStock when: - OrderConfirmed

usecase ConfirmOrder triggers SendOrderConfirmation when: - OrderConfirmed

このとき、

• ConfirmOrder は ReserveStock を手続きとして直接呼び出しているわけではない
• ConfirmOrder により OrderConfirmed というイベントが発生する
• ReserveStock と SendOrderConfirmation は、そのイベントに反応して起動される

という関係になります。

precedesとの違い

triggersはprecedesと混同されやすい関係です。どちらもユースケース間の関係を扱いますが、意味は異なります。

観点	precedes	triggers
本質	順序関係	イベント駆動
マージモード	Sequence	EventDriven
マージ点	After end	After condition
起動理由	前の処理が終わったから	条件を満たすイベントが発生したから
結合度	比較的強い	比較的弱い
後続処理	直列的	反応的

precedesは、

Aが終わったらBへ進む

という関係です。

triggersは、

Aによってイベントが発生し、そのイベントにBが反応する

という関係です。

したがって、

• 業務手順としてBがAの次に必ず必要なら precedes
• Aの結果に反応してBが起動されるなら triggers
• 同じイベントに複数の後続ユースケースが反応するなら triggers

と考えると分かりやすくなります。

他の関係との違い

観点	include	extend	precedes	triggers
対象	フロー構造	フロー変形	実行順序	起動条件
本質	構造合成	条件付き拡張	シナリオ連結	イベント駆動
時間関係	なし	部分	あり	条件成立後
結合	内部合成	内部拡張	直列連結	反応連携

includeは、共通フローをユースケース内部に埋め込みます。

extendは、条件付きでユースケース内部のフローを拡張します。

precedesは、ユースケース同士を時間順に接続します。

triggersは、イベントや条件を契機として別のユースケースを起動します。

つまりtriggersは、

フローの一部を共有するための関係ではなく、出来事に対する反応を表現する関係

です。

同期実行と非同期実行

triggersはイベント駆動の関係ですが、実装上の実行形態は一つに固定されません。

典型的には次の2つがあります。

• 同期型 : イベント発生後、同じ処理の流れの中で起動先ユースケースを実行する
• 非同期型 : イベントを発行し、別のタスクやワーカーが起動先ユースケースを実行する

モデル上のtriggersは、

何が何を起動するか

を表します。

一方で、同期か非同期かは、

• 実行基盤
• トランザクション境界
• エラー処理
• 再試行
• 通知やキューの有無

といった設計で決めます。

この分離により、ユースケースモデルでは業務上の反応関係を表現し、実装設計では実行方式を選択できます。

設計上の注意点

triggersを使用する際は、次の点に注意します。

• イベント名を業務上の事実として定義すること
• 単なるメソッド呼び出しをtriggersとして表現しないこと
• 起動条件を曖昧にしないこと
• 同じイベントに反応するユースケースが増えすぎないようにすること
• 同期実行と非同期実行の責務を混同しないこと

特に重要なのは、イベントを「命令」としてではなく「事実」として表現することです。

例えば、

• ReserveStock

というイベント名にすると「在庫を引き当てよ」という命令に見えます。

一方、

• OrderConfirmed

というイベント名にすると「注文が確定した」という事実になります。

triggersでは、この事実に対して後続ユースケースが反応する、という形にするとモデルが安定します。

まとめ

triggersは、

• ユースケース間のイベント駆動の起動関係
• 条件成立後に別のユースケースを起動する仕組み
• 後続処理を直列手順から分離するための関係

です。

precedesが

時間的な連続性

を扱う関係であるのに対し、

triggersは

出来事に対する反応

を扱う関係です。

この関係を使うことで、

• 注文確定後の在庫引当
• 通知送信
• 配送準備
• 外部システム連携

のような処理を、ユースケース間のイベント駆動の連携として表現できます。

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でのサポートの有無を含めて検討予定です。

まとめ

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

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

Cozyモデル駆動開発/ユースケース・モデルのシナリオをCMLで記述

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 に戻る。」）に展開される。これにより、読みやすさと機械可読性の両立が実現される。

1. 構造上の意味各ステップは 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文法について考えました。

次回はユースケース間の関係のモデルについて考え流予定です。

Cozyモデル駆動開発/ユースケース・モデルの拡張情報をCMLで記述

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

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

前前回にユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

前回はユースケース記述の基本情報をCML(Cozy Modeling Language)で記述する方法について考えました。

今回は拡張情報をCMLに追加します。

ユースケース拡張情報

前々回に定義したユースケースの拡張情報の構造です。

name	type	mult	description
secondary actor	name	?	セカンダリ・アクター
supporting actor	name	*	スポーティング・アクター
precondition	text	*	事前条件
postcondition	text	*	事後条件
priority	token	?	優先度
status	token	?	状態

ユースケース

CMLで記述したユースケース記述基本情報に拡張情報をを追加したものを以下に示します。

項目の内容に応じてプロパティ方式とセクション方式を混在させています。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
| Name             | 顧客の商品の予約を申請する                    |
| Id               | UC0056                                   |
| Primary Actor    | 販売担当者                                 |
| Secondary Actor  | 顧客                                      |
| Supporting Actor | よろず販売システム（在庫管理・予約管理機能）     |
| Goal             | 顧客が希望する商品の在庫を確保し、予約状態とする |
| Triger           | 顧客の予約依頼                              |
| Priority         | 高                                        |
| Status           | 設計済み・実装予定                          |
### Summary
販売担当者は、顧客からの希望商品について予約を申請し、在庫の確保を行う。予約が確定すると、顧客は商品を後日受け取ることができる。
### Precondition
- 顧客が購入意向を持ち、商品を特定している
- 商品が予約対象として登録されている
- 販売担当者がログイン済みである
### Postcondition
- 対象商品が「予約済み」状態として在庫管理に登録される
- 顧客情報と予約内容が記録される
- 確認メッセージが販売担当者および顧客に通知される

説明

基本項目中の以下の項目をセクション形式にしました。

summary

ユースケースの簡潔な説明

以下の拡張情報の項目を表に追加しました。

Secondary Actor

Primary Actorの目的を達成するための協力をするアクター。Primary Actorの相手役。

Supporting Actor

ユースケースで支援的な役割を果たすアクター

Priority

優先度

Status

ユースケースの管理状態

また、以下の拡張項目をセクションとして追加しました。

precondition

事前条件

postcondition

事後条件

まとめ

今回はユースケース記述の拡張情報をCMLで記述する方式について考えてみました。

次回はシナリオ記述についてCMLでの定義について考えていく予定です。

Cozyモデル駆動開発/ユースケース・モデルをCMLで記述

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

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

前回はユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

今回はCML(Cozy Modeling Language)での記述方法について考えます。

ユースケース基本情報

前回定義したユースケースの基本情報の構造です。

name	type	mult	description
id	identifier	1	ユースケースID
name	name	1	ユースケース名
title	i18ntitle	?	タイトル
goal	i18ntext	1	プライマリ・アクターの目的
summary	i18ntext	?
primary actor	name	1	プライマリ・アクター
trigger	text	?	トリガー

このユースケース基本情報をCMLで記述したものを以下に示します。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
| Name          | 顧客の商品の予約を申請する |
| Id            | UC0056                |
| Primary Actor | 販売担当者              |
| Goal          |                       |
| Triger        | 顧客の予約依頼           |
| Summary       |                       |

タイトル

タイトルの「ユースケース」はモデル的には特別な意味はありません。必要に応じて管理上適切なタイトルをつけることができます。

UseCase

セクション「UseCase」はユースケースの集まりを定義するセクションであることを示しています。

セクション内の各サブセクションは、それぞれユースケースの定義となっています。

上記の場合はサブセクション「顧客の商品の予約を申請する」がユースケース名となり、サブセクション内でユースケース「顧客の商品の予約を申請する」の定義を行います。

ユースケース情報

ユースケース基本情報を表で記述しました。

ユースケース基本情報は単純なプロパティの集まりなので、表形式で記述することが可能です。

プロパティをセクションで記述

CMLのメタ文法では、表の代わりにセクションの階層構造を使ってプロパティを記述することができます。

セクションを使ってプロパティを記述した場合の例を以下に示します。

ユースケース
==========
# UseCase
## 顧客の商品の予約を申請する
### Name
顧客の商品の予約を申請する
### Id
UC0056
### Primary Actor
販売担当者
### Goal
### Triger
対面販売
### Summary

サブサブセクションの名前の「Name」や「Id」がプロパティ名を示し、そのコンテンツがプロパティに対する値を記述します。

前述の表形式と記述する内容そのものは等価であることが確認できます。

ただ、表のフィールドで記述しきれない複雑な情報でもセクション形式では記述することができるので、そのような場合はセクション形式を選択するとよいでしょう。

表形式とセクション形式は混在することができるので、単純な値のプロパティを表形式で、複雑な構造を持つプロパティをセクション形式で記述することも可能です。

まとめ

今回はユースケース記述の基本情報をCMLで記述する方式について考えてみました。

次回から順次、拡張情報、シナリオ記述、ユースケース間の関係などについてCMLでの定義について考えていく予定です。

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

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

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

前回は要求項目のモデルを考えました。

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

ユースケース・モデル

ユースケースは、システムの利用者が目的を達成するために体験する物語を記述したモデルです。

Cozyモデル駆動開発(CMDD)ではユースケース・モデルを要求モデルの中核モデルとしています。

ユースケース・モデルの記述にはUMLのユースケース図も使用しますが、モデルの本体は自然言語で書かれたユースケース記述です。ユースケース記述の集まりによって記述されるユースケース・モデルの概要を図示したものがユースケース図です。

このためCMDDではCozy Modeling Language(CML)によって記述したユースケース記述の集まりから必要に応じてユースケース図をCozyで生成するアプローチを取ります。

ユースケース記述

ユースケース記述の内容を基本情報と拡張情報に分けて考えます。

基本情報

ユースケース記述の基本情報は以下の項目で構成されます。

name	type	mult	description
id	identifier	1	ユースケースID
name	name	1	ユースケース名
title	i18ntitle	?	タイトル
goal	i18ntext	1	プライマリ・アクターの目的
summary	i18ntext	?
primary actor	name	1	プライマリ・アクター
trigger	text	?	トリガー

id

ユースケースを一意に識別するためのIDです。

name

ユースケースの論理名です。利用者の目的をベースにソフトウェアで識別しやすい名前をつけます。

title

ユースケースを人間向けに説明するラベルです。画面や文書上に表示されます。利用者の目的をベースにしたタイトルをつけます。多国語で定義することができます。

goal

このユースケースが達成すべき、プライマリ・アクターの目的です。多国語で定義することができます。

summary

このユースケース全体の簡潔な説明です。システムやアクターの主要な振る舞いを要約します。多国語で定義することができます。

primary actor

このユースケースを開始し、利益を得る主なアクターです。

trigger

このユースケースを開始する外的な出来事や操作です。

拡張情報

ユースケースの拡張情報はユースケースを高度に使用したい場合に用いる情報です。

name	type	mult	description
secondary actor	name	?	セカンダリ・アクター
supporting actor	name	*	スポーティング・アクター
precondition	text	*	事前条件
postcondition	text	*	事後条件
priority	token	?	優先度
status	token	?	状態

secondary actor

セカンダリ・アクターはこのユースケースに関与しますが、主要な操作主体ではないアクターです。

supporting actor

サポーティング・アクターはユースケースにおいて支援的な役割を果たすシステムやアクターです。

precondition

ユースケースが正しく開始されるために、事前に満たされているべき条件です。

postcondition

ユースケースが成功裡に完了した後に成立すべきシステムやアクターの状態です。

priority

このユースケースの重要度や実装上の優先順位です。

status

ユースケース記述の完成度やレビュー状況などのステータスです。

まとめ

今回はユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

次回はCML(Cozy Modeling Language)での記述方法について考えます。

Cozyモデル駆動開発/要求項目モデル

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

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

前回はコンテキスト・モデルを作成しました。

今回から要求モデルの作成を開始します。

要求項目モデル

Cozyモデルはユースケース駆動が軸となるので、ユースケース・モデルが重要なモデルとなりますが、ユースケース・モデル以外のモデルも目的毎に併用する形になります。

要求仕様をまとめるにあたって、ユースケースのような詳細なモデルに入る前の準備モデルといった位置付けのモデルが必要になります。

この目的で用意しているのが要求項目モデルです。

要求項目は以下の属性を持つシステムで実現したい要求で、この要求項目の集まりが要求項目モデルとなります。

• 管理番号 (No)
• 名前 (Name)
• 内容 (Content)
• 優先度 (Priority)
• 作成日時 (CreatedAt)
• 更新日時 (UpdatedAt)

属性は日本語と対応する英語を定義していますが、モデル記述時にはどちらを使ってもかまいません。

優先度

要求項目の優先度は以下のMoSCoW基準で記述します。

優先度	展開形	意味	備考
M	Must have	必須	要求
S	Should have	重要	要求
C	Could have	可能であれば実現	要件
W	Want to have	将来検討	要望

フォーマット

モデル記述のフォーマットは以下のものになります。

# 要求項目
## 商品の販売
| Item       |          値 |
|------------+------------|
| No         |        001 |
| Priority   |          M |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |
### 内容
Web画面経由で商品の販売を行う。
## 商品の発送
| Item       |          値 |
|------------+------------|
| No         |        002 |
| Priority   |          S |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |
### 内容
販売した商品の発送を発送システムに依頼する。

要求項目

以下のように要求項目セクションを宣言するとその内容が要求項目モデルになります。

# 要求項目

要求項目の名前

以下のようにサブセクションのタイトルが要求項目の名前になり、サブセクション内の情報が要求項目のモデルとなります。

## 商品の販売

プロパティ

各種属性は以下のようなプロパティの表で一括して記述することができます。

| Item       |          値 |
|------------+------------|
| No         |        001 |
| Priority   |          M |
| CreateDate | 2025-06-30 |
| UpdateDate | 2025-06-30 |

内容サブサブセクション

タイトルが「内容」または「Content」のサブサブセクションにはモデルの内容を記述します。

### 内容
Web画面経由で商品の販売を行う。

管理方法

Cozyモデルの記述方法として上記のテキスト・フォーマットを定めています。このテキストをCozyが読み取って処理します。

また、同等の情報があれば要求管理システム、バグ管理システムやExcelなどの表計算ソフトのフォーマットでの管理も可能です。この場合、Cozyで処理をするためには連携アダプタが必要になります。

まとめ

今回は要求項目モデルを定義しました。

次回も引き続き要求分析を進めます。

Cozyモデル駆動開発/コンテキスト・モデル

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

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

前回はビジョン宣言を作成しました。ビジョン宣言によってシステム開発の目的やスコープがざっくりと定められたことになります。

続いて、今回はコンテキスト・モデルを作成します。

コンテキスト・モデル

コンテキスト・モデルは、開発対象の大枠についてシステムの外部とシステムとの関係を中心にモデル化したものです。コンテキスト図という形でビジュアル表現にして、全体を俯瞰することを可能にします。

ビジネス分析でビジネス・システム向けのコンテキスト・モデルであるビジネス・コンテキストを作成しました。まず、このビジネス・コンテキストを確認した後に、システム開発向けのコンテキスト・モデルを作成します。

ビジネス・コンテキスト

「Cozyモデル駆動開発/ビジネス・コンテキスト(2)」の回で、ビジネス・モデルのビジネス・コンテキストをCozy形式で作成しました。Cozyのアプローチでは、Cozyオブジェクト・モデルからコンテキスト・モデルを抽出しコンテキスト図を生成します。

ビジネス・モデルではBusiness.mdとして以下のモデルを記述しました。このモデルから必要に応じてコンテキスト・モデルを記述するコンテキスト図を生成しました。

# Business
## System
### Pieris Books
Pieris Booksビジネス。
- composition :: 店舗, ECサイト
- use :: 店舗販売プロセス
- use :: EC販売プロセス
- use :: 在庫管理プロセス
店舗とECサイトで商品販売を行う。
店舗には売れ筋商品のみ実商品を在庫として保管し、その場で販売を行う。
通常の商品は見本品のみ展示し、注文があった場合はEC販売プロセスで決済と配送を行う。
EC販売プロセスでは外部ECサービスを用い、決済や在庫管理、配送処理を外部ECサービスが
提供するものを利用する。
ただし、店舗顧客には通常の店舗での購入と同様にレジによるオペレーションで販売処理を行う。
### 店舗
Pieris Booksの実店舗。
### ECサイト
Pieris BooksのECサイト。
## Process
### 店舗販売プロセス
店舗で商品販売を行う。
- actor :: 店舗顧客
- actor :: 店舗販売者
- use :: 在庫管理プロセス
- use :: 店舗
- use :: EC販売プロセス
- use :: 決済サービス
### EC販売プロセス
ECサイトで商品販売を行う。
- use :: 在庫管理プロセス
- use :: 外部ECサービス
### 在庫管理プロセス
実店舗での在庫管理を行う。
- actor :: 販売管理者
- use :: 配送サービス
在庫管理の延長で配送サービスへの受け渡しも行う。
## Actor
### 店舗顧客
店舗の利用者。
店舗に在庫がある場合は直接購入することができる。
店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。
### EC顧客
ECサイトの利用者。
### 外部ECサービス
見本品を購入する際に使用する外部のECサービス。
### 決済サービス
ECまたは店舗での商品販売に使用する決済サービス。
### 配送サービス
ECでの商品販売を依頼する配送サービス。
### 店舗販売者
店舗で商品の販売を行う。
店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。
### 店舗運営者
ビジネス上の店舗運営を行う。
ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。
### 販売管理者
店舗での商品管理などを行う。
### システム管理者
Pieris BooksのITシステムの管理を行う。

オブジェクト・モデル

ビジネス・コンテキスでは、コンテキスト・モデルとしてコンテキスト図を作成するのではなく、オブジェクト・モデルを作成し、このオブジェクト・モデルからコンテキスト・モデルを記述するコンテキスト図を生成するアプローチをとっています。

システム開発向けのコンテキスト・モデルでも同様のアプローチを取ります。

このアプローチの元、作成したオブジェクト・モデルが以下のものです。

Pieris Book Store System
========================
# System
## Pieris Book Store System
Pieris Books StoreのECシステム。開発対象のシステム。
# SubSystem
## EC
ECサイトからの販売を管理するサブシステム。
販売管理処理はCommerceに移譲する。
- use :: Commerce
## Store
店舗からの販売を管理するサブシステム。
販売管理処理はCommerceに移譲する。
- use :: Commerce
## Commerce
販売管理を行うサブシステム。
外部ECサービスと決済サービスを使用する。
- use :: 外部ECサービス
- use :: 決済サービス
## StockManagement
在庫管理を行うサブシステム。
- use :: 配送サービス
# Actor
## 店舗顧客
店舗の利用者。
店舗に在庫がある場合は直接購入することができる。
店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。
- use :: 店舗販売者
## EC顧客
ECサイトの利用者。
- use :: EC
## 店舗販売者
店舗で商品の販売を行う。
店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。
- use :: Store
## 店舗運営者
ビジネス上の店舗運営を行う。
ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。
- use :: Commerce
## 販売管理者
店舗での商品管理などを行う。
- use :: Commerce
## システム管理者
Pieris BooksのITシステムの管理を行う。
- use :: Pieris Book Store System
# External Service
## 外部ECサービス
見本品を購入する際に使用する外部のECサービス。
## 決済サービス
ECまたは店舗での商品販売に使用する決済サービス。
## 配送サービス
ECでの商品販売を依頼する配送サービス。

大きく以下の4つのセクションから構成されています。

• System
• SubSystem
• Actor
• External System

System

Systemセクションには、サブセクションのタイトルにシステム名とシステムの説明を記述します。

SubSystem

SubSystemセクションでは、サブセクション毎に1つのサブシステムを表します。サブセクション名がサブシステム名、サブセクション内にサブシステムの説明を記述します。

上記のモデルでは以下のサブシステムを定義しています。

EC

EC運営システム

Store

店舗運営システム

Commerce

販売システム

StockManagement

在庫管理システム

それぞれの説明文の中に以下のような形で、他オブジェクトへの参照を記述しています。

- use :: Commerce

この参照の記述がモデルとして解釈されます。

Actor

Actorセクションでは、サブセクション毎に1つのアクターを表します。オブジェクト・モデル的には外部サービスもアクターの一種ですが、CozyモデルではExternal Serviceとして別セクションで定義するようになっています。

上記のモデルでは以下のサブシステムを定義しています。

• 店舗顧客
• 店舗販売者
• EC顧客
• 販売管理者
• 店舗運営者
• システム管理者

それぞれの説明文の中に以下のような形で、他オブジェクトへの参照を記述しています。

- use :: EC

External Service

External Serviceセクションでは、サブセクション毎に1つの外部サービスを表します。

上記のモデルでは以下のサブシステムを定義しています。

• 外部ECサービス
• 決済サービス
• 配送サービス

コンテキスト図

今回作成したオブジェクト・モデルからCozy以下のコンテキスト図が生成される想定です。

まとめ

今回はコンテキスト・モデルの作成を行いました。

実際に作成したのはオブジェクト・モデルで、このオブジェクト・モデルからコンテキスト・モデルの記述に必要な要素だけ取得して、コンテキスト図を生成しました。

このコンテキスト図により開発対象のシステムの全体像を俯瞰することができるようになります。

次回も引き続き要求分析を進めます。

Cozyモデル駆動開発/ビジョン宣言

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

前回から要求分析に入っています。要求モデルをCozyモデルとして定義する方法について考えます。

今回はビジョン宣言を取り上げます。

ビジネス・ビジョン宣言

「Cozyモデル駆動開発/ビジネス・ビジョン」の回で、ビジネスのビジョンを記述するフォーマットとして以下のものを導入しました。

FOR ターゲット顧客
WHO 利用者
THE 製品名 is a 製品カテゴリ
THAT キーとなるメリット、製品を買う理由
UNLIKE 競合商品
OUR PRODUCT 競合商品との違い

このフォーマットを使用して以下のビジネス・ビジョンを定義しました。

FOR セレクトショップ販売店
WHO 本を読みながらカフェでのんびりしたい人
THE BCwSG is a ブックカフェ併設のセレクトショップ
THAT カフェの利用者にセレクト商品の紹介と販売を行うことができる
UNLIKE 通常のセレクト・ショップ
OUR PRODUCT ブック・カフェを併設することで商品の販売機会を増やすことができる

ビジョン宣言

ビジネス・ビジョン宣言に使用したフォーマットをシステム開発にも使用します。

ビジネス・ビジョンではセレクトショップ販売店のビジネス全体のビジョンを定義しましたが、システム開発におけるビジョン宣言は今回開発するシステムの意図と目標を定めるビジョンを定義します。

「ビジネス・ビジョン」の回で説明した通り現在はインセプション・フェーズなので、BCwSGのセレクトショップ販売店の基盤となるソフトウェア・システムの核となる構造を試行することが目的となります。

このような点を考慮して、インセプション・フェーズの開発ビジョンとして以下のものを定義しました。

FOR カフェ併設セレクトショップ販売店BCwSG
WHO カフェの利用者
THE BCwSGシステム is a ブックカフェ併設のセレクトショップ
THAT カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる
UNLIKE 通常のセレクト・ショップ
OUR PRODUCT 在庫を持たずに商品販売ができる

「カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる」点を軸に実証性の検証と実現するためのメカニズムの試行を目的に開発を進めます。

保存

作成したビジョン宣言をCozyモデルとして保存します。

以下のようにVisionセクションにビジョン宣言を記述します。

# Vision
FOR カフェ併設セレクトショップ販売店BCwSG
WHO カフェの利用者
THE BCwSGシステム is a ブックカフェ併設のセレクトショップ
THAT カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる
UNLIKE 通常のセレクト・ショップ
OUR PRODUCT 在庫を持たずに商品販売ができる

作成したビジョン宣言のCozyモデルはsrc/main/cozy/requrement配下にvision.doxとして格納します。

まとめ

今回からブックカフェ併設のセレクトショップBCwSGのシステム開発に入ってきました。

まずシステムの意図と目標を定めるビジョン宣言を作成しました。

次回も引き続き要求分析を進めます。

Cozyモデル駆動開発/要求モデル

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

前回までビジネス・モデルの作成を行いました。

ビジネス・モデルを作成することで開発対象のシステムが動作するビジネス上の文脈を明確化しました。このビジネス文脈を前提に、要求モデルの作成を進めることになります。

今回から要求モデルのモデルの定義とCozy上での取り扱いついて検討していきます。

要求モデル

要求モデルは以下のサブ・モデルで構成されます。

• スコープ・モデル
• 機能要求モデル
• 非機能要求モデル

スコープ・モデル

スコープ・モデルは開発対象システムのスコープを定めます。ビジネス・モデルの文脈の中で、システムの置かれる立ち位置、システムの責務を考えていきます。

スコープ・モデルは以下の2つのモデルで構成されます。

• ビジョン宣言
• システム・コンテキスト

ビジョン宣言

ビジョン宣言は、システム開発のビジョンを定義します。

ビジネス・モデルで今回のシステム開発に関わるビジネス上のビジョンをビジネス・ビジョン宣言として定義しました。このビジネス・ビジョン宣言を参考に、システム開発のビジョンを定義します。

システム・コンテキスト

システム・コンテキストは開発対象のシステムをコンテキスト図を使って記述します。

システムの利用者や外部システムなどのアクターとシステムの境界を明確にするのが目的です。

ビジネス・モデルで作成したビジネス・コンテキストをベースにシステム開発に関係する部分を詳細化したものになります。

機能要求モデル

機能要求モデルはシステムの提供する機能に関する要求仕様を記述するモデルです。

機能要求モデルは以下の2つのモデルで構成されます。

• ユースケース・モデル
• フィーチャ・モデル

ユースケース・モデル

ユースケース・モデルはアクターの目標と達成するための物語であるユースケースを軸とした要求モデルです。

ユースケース駆動開発は、ユースケースを軸に要求分析からシステム分析、ドキュメント、テストなどの各作業分野を駆動していく開発方式です。

ユースケースを開発の単位として開発管理を行っていきます。ただし、ユースケースだと開発の粒度が大きい場合には、一回のイテレーションにフィットするサイズにユースケースを分割したユースケース・スライスを使用してます。

フィーチャ・モデル

フィーチャ・モデルはユースケースに向かない開発項目をフィーチャとして定義したモデルです。

フィーチャ単独で定義するケースとユースケースのシナリオ内で使用するシステム機能をフィーチャとしてモデル化する場合があります。

ユースケースを補完するモデルとして使用します。

非機能要求モデル

非機能要求モデルは機能要求モデルで記述できない、機能を横断した要求項目を記述するモデルです。

非機能要求モデルは以下のようなモデルで構成されます。

• 品質属性
• コスト
• 技術上の制約

品質属性

品質属性は性能、スケーラビリティ、セキュリティなど機能に対して横断的な関心事の品質要件を定義したものです。

コスト

コストはシステムの開発費やハードウェアの調達費、運用コストなどです。

技術上の制約

技術上の制約は使用することが求められているハードウェア、OS、ミドルウェアなどが代表的なものになります。

まとめ

今回は要求モデルの全体像について説明しました。

次回はスコープ・モデルのビジョン宣言について説明します。

Cozyモデル駆動開発/ビジネス・フロー

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

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図
• ビジネス・プロセス
• ビジネス・ユースケース
• ビジネス情報モデル

ビジネス・プロセスの具体的な動きをモデル化するしたい場合には、ビジネス・フロー図が有効です。UMLではアクティビティ図で記述しますが、CozyではCML(Cozy Modeling Language)で記述して必要に応じてアクティビティ図に変換します。

ビジネス・フロー

以下のドキュメントは商品購入のビジネス・フローをCML(Cozy Modeling Language)で記述したものです。

# ACTIVITY
## SalesOrder
顧客の購入処理
### CreateSalesOrder
顧客が購入依頼を行う
### DECISION: StockAvailable
在庫の確認を行う
- Yes :: ProcessOrder
- No :: NotifyCustomer
### ProcessOrder
購入処理を進める
### ShipOrder
配送処理を進める
#### TRANSITION
- FINAL
### NotifyCustomer
在庫の不足により購入が失敗したことを顧客に通知
### CancelOrder
購入処理をキャンセルする

CMLでアクティビティ・モデルを記述する文法を以下で説明します。

ACTIVITY

最初のセクションのタイトルがACTIVITYとなっています。これはこのセクションの内容がアクティビティ・モデルということを示しています。

# ACTIVITY

アクティビティ・モデル名

ACTIVITYセクション直下のサブセクションではアクティビティ名を指定します。

ここではSalesOrderを指定しているので、アクティビティ・モデルSalesOrderの定義ということになります。

## SalesOrder

アクティビティ・ノード

サブサブセクションは以下の項目が並んでいます。

• CreateSalesOrder
• DECISION: StockAvailable
• ProcessOrder
• ShipOrder
• NotifyCustomer
• CancelOrder

これらはアクティビティ・ノードを構成するアクティビティ・ノードです。アクティビティ・ノードはそれぞれ実行する処理が定義されています。処理内容は日本語で記述しています。

処理が終わると接続された次のアクティビティ・ノードに制御が移ります。

アクティビティ・ノードの制御の移動は後述するTRANSITIONサブサブサブセクションに記述します。このTRANSITIONサブサブセクションが定義されていない場合は、すぐ下のアクティビティ・ノードに遷移します。

DECISION

サブサブセクション「DECISION: StockAvailable」は「DECISION: 」で始まるのでデシジョン・ノードとなります。ノード名はStockAvailableです。

デシジョンノードでは条件ごとの分岐を記述します。

条件の内容として日本語で「在庫の確認を行う」と定義しています。この条件に対して以下の定義が行われています。

- Yes :: Process order
- No :: Notify customer

条件がYesの場合はProcessOrderノードに、Noの場合はNotifyCustomerノードに遷移します。

TRANSITION

各ノードのデフォルトの定義は、処理終了後直下のノードに遷移しますが、他のノードに遷移させる場合はサブサブサブセクション「TRANSITION」で遷移先を指定します。

アクティビティ・ノードShipOrderでは以下の定義をしているので、処理終了後FINALに遷移します。FINALはアクティビティの終了を示すので、ShipOrder終了後にアクテビティ全体が終了します。

アクティビティ図を生成

このCMLモデルからCozyによってアクティビティ図を生成したものが以下の図です。

モデル記述はCMLにしておき、必要に応じて参照用のアクティビティ図を生成する開発スタイルになります。

まとめ

今回はビジネス・モデルにおけるビジネス・フローについて説明しました。

今回でビジネス・モデルは終了です。次回から要求モデルに入っていきます。

Cozyモデル駆動開発/ビジネス情報モデル

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

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図
• ビジネス・プロセス
• ビジネス・ユースケース

今回はこれらのモデルの作成過程で同時に作成される情報モデルについて考えます。

ビジネス・オブジェクト

ビジネス・コンテキスト

ビジネス・コンテキストの作成時に以下の用語集を作成しました。

用語	種別	意味
Pieris Books	BS	Pieris Booksビジネス全体
EC	BS	Pieris BooksのEC機能
店舗	BS	Pieris Booksの実店舗
在庫管理	BS	実店舗での在庫管理
EC利用者	BA	ECサイトの利用者
店舗利用者	BA	店舗の利用者
外部ECサービス	BA	見本品を購入する際に使用する外部のECサービス
決済サービス	BA	ECまたは店舗での商品販売に使用する決済サービス
配送サービス	BA	ECでの商品販売を依頼する配送サービス
店舗運営者	BA	ビジネス上の店舗運営を行う
販売管理者	BA	店舗での商品管理などを行う
システム管理者	BA	Pieris BooksのITシステムの管理を行う

ビジネス・プロセス

ビジネス・ユースケースを記述するモデルとしてBusiness.mdを作成しました。

ここでは以下の用語が定義されています。ビジネス・コンテキストで抽出した用語をベースにビジネス・プロセスを定義しながら作成したものです。一部用語はより適切と思われるものに改良しています。

• 店舗販売プロセス
• EC販売プロセス
• 在庫管理プロセス
• ECサイト
• 店舗顧客
• EC顧客
• 外部ECサービス
• 決済サービス
• 配送サービス
• 店舗販売者
• 店舗運営者
• 販売管理者
• システム管理者

ビジネス・ユースケース

ビジネス・ユースケースを記述するモデルとしてBusinessUseCase.mdを作成しました。

ビジネス・ユースケースの作成時に以下のビジネス・アクターを使用しました。

• 店舗顧客
• 店舗販売者
• 店舗販売システム

またユースケースの脚本に登場するモノは以下になります。

• 商品
• 商品情報
• 在庫数

情報モデル

Business.mdとBusinessUseCase.meから情報モデルに対応するモデル群を抽出してまとめると以下になります。この抽出作業はCozyで行うことができます。

# Overview
- cope :: business
# Actor
## 店舗顧客
店舗の利用者。
店舗に在庫がある場合は直接購入することができる。
店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。
## EC顧客
ECサイトの利用者。
## 外部ECサービス
見本品を購入する際に使用する外部のECサービス。
## 決済サービス
ECまたは店舗での商品販売に使用する決済サービス。
## 配送サービス
ECでの商品販売を依頼する配送サービス。
## 店舗販売者
店舗で商品の販売を行う。
店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。
## 店舗運営者
ビジネス上の店舗運営を行う。
ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。
## 販売管理者
店舗での商品管理などを行う。
## システム管理者
Pieris BooksのITシステムの管理を行う。
# Entity
## 商品
Pieris Booksが販売する商品。
## 在庫
商品の在庫。
# Value
## 商品情報
商品の内容を確認するために参照する情報。

この情報モデルはドメイン・モデルの雛形となります。ただ、ITシステムの文脈で構築するドメイン・モデルとは連続性があるものの完全にマッチするわけではないので、この段階では参考情報という扱いになります。

まとめ

今回はビジネス・モデルにおける情報モデルについて説明しました。

次回はビジネス・フローについて取り上げる予定です。

Cozyモデル駆動開発/ビジネス・ユースケース

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

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図
• ビジネス・プロセス

前回からBusiness.mdを使ってPieris Booksのビジネス・モデルを記述しています。

前回はビジネス・プロセスをざっくり記述しました。

今回はビジネス・プロセスの構成要素の一つであるビジネス・ユースケースについて考えていきます。

ビジネス・ユースケース

ビジネス・ユースケースはビジネス・システムの外部の利用者がその目的を達成するために、ビジネス・システムとの対話を通じて構成される物語です。

ITシステムに対するユースケースはシステム・ユースケースとも呼ばれますが、それに対してビジネス・システムに対するユースケースがビジネス・ユースケースとなります。

目的

ビジネス・ユースケースを作成する目的の一つは、ビジネス・システムを利用するビジネス・アクターとその目的を把握することです。ビジネス・システムに求められる機能の輪郭をは明確にすることができます。

ビジネスアクターの物語を作ることで、ビジネスを遂行するためのメカニズムを抽出していくことができます。この物語ではITシステムの提供する機能が重要な構成要素になります。この部分がITシステム開発の入力情報になるわけです。

ITシステムが提供すべき機能が明らかになりますし、ITシステム開発時には利用される文脈が明確になっているのは非常に重要なことです。

ビジネス・モデリングで抽出したビジネス・アクターの中で、ITシステムを使用するビジネス・アクターがITシステムのアクターの候補となります。

また、ビジネス・システムを構成するビジネス・アクターの中でビジネスやITシステムの動作状況を把握したいものは、ステークホルダーとしてITシステムのアクターとなります。

ビジネス・ユースケース

Pieris Booksのビジネス・ユースケース(の一部)を作成し、BusinessUseCase.mdに保存しました。

このユースケースに沿って説明をしていきます。

# Overview
- Scope :: Business
- Process :: 店舗販売プロセス
# Use Case
## 商品を購入する
### Actor
- Primary :: 店舗顧客
- Secondary :: 店舗販売者
- Supporting :: 店舗販売システム
### Story
店舗顧客が来店して、店舗販売者のアドバイスを得て、商品を購入する。
### Scenario
#### Main
1. 店舗顧客が来店する
2. 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
   - 商品情報
   - 在庫数
3. 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って販売する。
#### Alternate
2.a. 店舗販売者は自分の知識で販売のアドバイスをする。
#### Exception
3.a. 店舗顧客は商品を購入しない。
## 欠品の商品の予約をし、入荷後に購入する
### Actor
- Primary :: 店舗顧客
- Secondary :: 店舗販売者
- Supporting :: 店舗販売システム
### Story
店舗顧客が来店して、店舗販売者のアドバイスで商品を選定するが、在庫が欠品のため
予約して帰宅する。
予約後、連絡を受けて再来店し、購入する。
### Scenario
#### Main
1. 店舗顧客が来店する。
2. 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
   - 商品情報
   - 在庫数
3. 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って予約する。
4. 店舗販売システムはメールで商品の入荷を店舗顧客に通知する。
5. 店舗顧客が再来店する。
6. 店舗販売者は入荷済みの予約商品を店舗販売システムを使って販売する。
#### Alternate
2.a. 店舗販売者は自分の知識で販売のアドバイスをする。
4.a.1. 店舗販売システムは商品の入荷を
#### Exception
3.a. 店舗顧客は商品を購入しない。
6.a. 店舗顧客は商品をキャンセルする。

構造

Overview節でBusinessUseCase.mdの文脈を以下のように設定しています。

# Overview
- Scope :: Business
- Process :: 店舗販売プロセス

ScopeはBusinessなので、ビジネス・モデルということになります。

Processに「店舗販売プロセス」を指定しているで、本ファイル内のモデルは「店舗販売プロセス」に所属します。

続けて、以下に示すようにユースケースの記述が始まります。上記の設定により、ビジネス・プロセス「店舗販売プロセス」に所属するビジネス・ユースケースの記述となります。

# Use Case
## 商品を購入する

今回の例では以下のビジネス・ユースケースを記述しています。

• 商品を購入する
• 欠品の商品の予約をし、入荷後に購入する

まず「商品を購入する」を通してビジネス・ユースケースの記述方法についてみていきます。

商品を購入する

ビジネス・ユースケース「商品を購入する」を以下に再掲します。

節名「商品を購入する」がユースケースのタイトルです。

## 商品を購入する
### Actor
- Primary :: 店舗顧客
- Secondary :: 店舗販売者
- Supporting :: 店舗販売システム
### Story
店舗顧客が来店して、店舗販売者のアドバイスを得て、商品を購入する。
### Scenario
#### Main
1. 店舗顧客が来店する
2. 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
   - 商品情報
   - 在庫数
3. 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って販売する。
#### Alternate
2.a. 店舗販売者は自分の知識で販売のアドバイスをする。
#### Exception
3.a. 店舗顧客は商品を購入しない。

アクター

Actor節で、アクターの定義を行っています。

### Actor
- Primary :: 店舗顧客
- Secondary :: 店舗販売者
- Supporting :: 店舗販売システム

主役であるプライマリ・アクターは店舗顧客です。ユースケースは主役であるプライマリ・アクターの目的を達成するための物語をモデル化します。そしてこのプライマリ・アクターの目的がユースケースのタイトルとなります。

セカンダリ・アクターは店舗販売者です。プライマリ・アクターの店舗顧客が目的である「商品を購入する」を助ける役割です。

サポーティング・アクターは店舗販売システムです。物語の達成に協力するアクターです。

あらすじ

Story節にはあらすじを散文で記述します。

### Story
店舗顧客が来店して、店舗販売者のアドバイスを得て、商品を購入する。

場合によっては後述のシナリオは定義せず、あらすじの情報だけで先に進むことも可能です。

シナリオ

Scenario節にシナリオを記述します。ユースケースは「物語」をモデル化して、これに対してシナリオ分析をかけていくことが主眼ですから、シナリオはユースケースの核となるモデル要素です。

### Scenario
#### Main
1. 店舗顧客が来店する
2. 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
   - 商品情報
   - 在庫数
3. 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って販売する。
#### Alternate
2.a. 店舗販売者は自分の知識で販売のアドバイスをする。
#### Exception
3.a. 店舗顧客は商品を購入しない。

Scenario節の中には以下の節が格納されています。

Main

メインのシナリオ

Alternate

代替シナリオ

Exception

例外シナリオ

メインのシナリオはユースケースが正常に終了する流れを記述します。

代替シナリオはユースケースの結果は同じで、処理の一部が異なる箇所を記述します。代替シナリオを使用しないと、ちょっとした処理の違い毎にユースケースを作成しなければならなくなります。

例外シナリオはユースケースが失敗する条件とその場合の流れを記述します。メインシナリオ中の各ステップでユースケースが失敗して異常終了するような分岐を設定する形になります。

ITシステムとの関係

シナリオ内で店舗販売システムを使用するのは以下の2箇所です。

• 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
• 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って販売する。

ビジネス・ユースケースでのそれぞれのステップが、分析段階でのシステム・ユースケースとなります。それぞれのシステム・ユースケースでの分析時には、ビジネス・ユースケース上どのような形で使用されるのかという文脈を定めることができ、ユースケース分析時の精度を高めることに寄与します。

欠品の商品を予約し、入荷後に購入する

ビジネス・ユースケース「欠品の商品を予約し、入荷後に購入する」の構造についても、前出のビジネス・ユースケース「商品を購入する」と同様の構造です。

物語の特徴としては、在庫がないため予約をして退店し、在庫入荷の通知を受けて再来店するという流れになっていることです。

このためアクターは物語の流れの中で間欠的にITシステムを使用していくことになります。

具体的には、店舗販売システムを使用するのは以下の4箇所です。

• 店舗販売者は店舗販売システムから以下のような情報を得ながら販売のアドバイスをする。
• 店舗販売者は店舗顧客が選んだ商品を店舗販売システムを使って予約する。
• 店舗販売システムはメールで商品の入荷を店舗顧客に通知する。
• 店舗販売者は入荷済みの予約商品を店舗販売システムを使って販売する。

それぞれの場所で、それぞれのシステム・ユースケースによる分析が行われることになります。

まとめ

今回は、ビジネス・プロセスの構成要素の一つであるビジネス・ユースケースをCozyモデルで記述する方法について説明しました。

次回は情報モデルについて説明する予定です。

Cozyモデル駆動開発/ビジネス・プロセス(4)

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

現在はビジネス・モデルの作成中で以下のモデルを定義してきました。

• ビジネス・ビジョン
• ビジネス・ゴール
• ビジネス・コンテキスト図

続けてBusiness.md内に以下のビジネス・オブジェクトから構成されるビジネス・モデルの核になる部分を作成しました。

• ビジネス・システム
• ビジネス・プロセス
• ビジネス・アクター

このビジネス・モデルをビジネス・プロセスを中心に肉付けしていきます。

ビジネス・プロセスの構成要素

ビジネス・プロセスはビジネス・システム内で行われる活動を抽象化したモデルで、様々なビジネス・オブジェクトから構成されます。

ビジネス・プロセスを構成する主なビジネス・オブジェクトは以下になります。

ビジネス・オブジェクトの種類

ビジネス・オブジェクトの種類は以下になります。括弧内はステレオタイプです。

• ゴール (goal)
• 情報 (information)
• 抽象 (abstract)
• 物理 (physical)
• 人 (people)

リソースは「情報(information)」または「コト(things)」に分類されます。「コト(things)」は「抽象(abstract)」または「物理(physical)」に分類されます。そして「物理(pysical)」の中で人を「人(people)」とします。

ビジネス・オブジェクトとの関係

ビジネス・プロセスとビジネス・オブジェクト間の関係の種類は以下になります。括弧内はステレオタイプです。

• 入力
• 出力
• 達成 (achieve)
• 制御 (control)
• 提供 (supply)

入力と出力はビジネス・プロセスに対する入力と出力です。

「達成(achieve）」はゴール(goal)を関連付けます。

「制御(control)」はビジネス・プロセスを制御するリソースを関連付けます。ビジネス・プロセスに対して能動的に参加するリソースということになります。

「提供(supply)」はビジネス・プロセスから利用されるリソースを関連付けます。ビジネス・プロセスに対して受動的に参加するリソースということになります。

ビジネス・プロセス図

上記のビジネス・オブジェクトとビジネス・プロセスの関係をビジネス・プロセス図では以下のように記述します。

これと同等の情報をCozyモデルの記述方式でBusiness.mdに記述します。このモデルからビジネス・プロセス図が自動生成することを想定しています。

ビジネス・プロセスの振る舞い

ビジネス・プロセスの振る舞いモデルとして以下のモデルを作成します。

• ビジネス・ユースケース
• ビジネス・フロー

ビジネス・ユースケース

ビジネス・プロセス内でビジネス・アクターの目標を達成するために実行される物語です。

ビジネス・ユースケースを作成することでビジネス・プロセスに参加するビジネス・アクターを抽出することができます。

ユースケース・シナリオによって、このビジネス・アクターが対話するITシステムと、その対話内容を抽出することができ、ここからシステムの利用方法が分かります。

また、ユースケース・シナリオの中で以下のビジネス・オブジェクトを抽出することができます。

• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・フロー

ビジネス・プロセスの振る舞いをアクティビティ図などを使ったフローとして記述したものです。

ビジネス・ユースケースの物語を実現する業務の流れをモデル化します。

ビジネス・ユースケースと同様にビジネス・フローによって以下のビジネス・オブジェクトを抽出することができます。

• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・プロセスを実現するビジネス・オブジェクト

ビジネス・プロセスを実現するために使用するビジネス・オブジェクトの中で、ITシステム内で管理する候補となるものは以下になります。

いずれもビジネス・ユースケース、ビジネス・フローで抽出しています。

• ビジネス・アクター
• ビジネス・イベント
• ビジネス・エンティティ
• ビジネス・ルール

ビジネス・アクター

ビジネス・アクターはビジネス・システムの活動に参加する人や外部システムです。

人の場合は前述のビジネス・オブジェクトの種類では「人(information)」に分類されます。

ビジネス・プロセスに人として参加している場合、必ずしもITシステムと接点があるわけではありません。このためビジネス・アクターの中でITシステムと接点のあるものがITシステムのアクターの候補となります。

ビジネス・イベント

ビジネスの活動の中で発行されるイベントです。ビジネス・ユースケースまたはビジネス・フローで抽出します。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・イベントの候補となります。

ビジネス・エンティティ

ビジネスの活動の中で管理して更新するエンティティ(永続オブジェクト)です。

ビジネス・ユースケースまたはビジネス・フローで抽出します。

ビジネス・プロセスの動的モデルはエンティティの状態遷移が基本となります。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・エンティティの候補となります。

ビジネス・ルール

ビジネス・プロセスの振る舞いを規制したり、各種計算を行う規則です。

ビジネス・オブジェクトの種類では「情報(information)」に分類されます。

ドメイン・ルールの候補となります。

まとめ

今回はビジネス・プロセスの構成要素について整理しました。

次回からビジネス・プロセスを構成する個々のビジネス・オブジェクトの検討に入っていきます。

次回はビジネス・ユースケースについて検討します。