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モデルで記述する方法について説明しました。

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