Modegramming Style

2024年12月31日火曜日

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

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

2024年11月30日土曜日

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)」に分類されます。

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

まとめ

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

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

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

2024年10月31日木曜日

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

今回はビジネス・モデルを記述するBusiness.mdの構造についてみていきます。

Business.mdの基本構造はCozyのオブジェクト・モデル記述に則っています。Cozyのオブジェクト・モデルを使ってビジネス・モデル用のモデル要素を導入することでオブジェクト・モデルを記述しています。

基本文法

Cozyモデルの文法はMarkdown文法の基本部を使用しており、ニッチな機能を使わなければ基本的にはMarkdownとして記述して大丈夫です。またMarkdownにない文法を必要に応じて追加しています。

基本構造

セクションの階層でモデルの基本構造を記述します。

第1階層であるセクションでは、セクション内に記述するモデルの種類を記述します。

ビジネス・モデルでは以下のモデル種別を使用しました。

Overview : 概要
System : ビジネス・システム
Process : ビジネス・プロセス
Actor : ビジネス・アクター

第2階層であるサブセクションでは、サブセクション名にモデル名を記述します。

オブジェクトの定義

オブジェクトの定義はオブジェクト用のサブセクションの中で行います。

クラス名

オブジェクトのクラス名はサブセクション名で記述します。

特性

特性(property)は以下の3つの形式で記述することができます。

表
リスト
プロパティ

オブジェクトに関する特性をプロパティとして記述します。

属性

属性(attribute)は以下の3つの形式で記述することができます。

表
リスト

表

表で属性情報を記述する場合、以下のように名前(Name)、Type(型)、Multiplicity(多重度)のカラムにそれぞれのデータを記述します。

| Name  | Type   | Multiplicity |
|-------+--------+--------------|
| id    | token  |            1 |
| name  | string |            1 |
| price | int    |            1 |

型(Type)の対象はデータ型またはValueです。

属性の情報を記述した表と判定する方法は以下のとおりです。

まず以下のようにキャプション名Attributesの表が属性の対象となります。

: Attributes
| Name  | Type   | Multiplicity |
|-------+--------+--------------|
| id    | token  |            1 |
| name  | string |            1 |
| price | int    |            ? |

キャプション名がない場合は以下のルールで属性対象の表を特定します。

サブサブセクションAttributesがある場合は、その配下から属性の情報を特定します。

サブサブセクションAttributesがない場合、サブセクション直下に最初に現れた表またはリストが属性用の情報と判断されます。

ビジネス・モデルの場合

今回のモデルでは、前述のモデル記述方法がどのように使われているかを確認します。

ビジネス・モデルでは以下のモデル種別を使用しました。

Overview : 概要
System : ビジネス・システム
Process : ビジネス・プロセス
Actor : ビジネス・アクター

Overview

Overviewセクションではモデルのスコープをリストによるプロパティ形式で記述しています。

- scope : business

System

以下の3つのシステムを定義しています。

Pieris Books
店舗
ECサイト

Pieris Booksシステムでは、Pierisシステムの説明文とともにシステムを構成する関連を定義しています。

店舗システムとECサイトシステムは現段階では文章のみです。

Process

以下の3つのビジネス・プロセスを定義しています。

店舗販売プロセス
EC販売プロセス
在庫管理プロセス

各ビジネス・プロセスの詳細は現段階では文章のみです。

Actor

以下の9個のビジネス・アクターを定義しています。

店舗顧客
EC顧客
外部ECサービス
決済サービス
配送サービス
店舗販売者
店舗運営者
販売管理者
システム管理者

各ビジネス・アクターの詳細は現段階では文章のみです。

まとめ

今回はCozyモデル記述言語の基本的な文法とビジネス・モデルでの適用について説明しました。

次回はCozyモデル記述言語を使ってビジネス・プロセスの定義を行っていきます。

2024年9月30日月曜日

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

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

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

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

この中でビジネス・コンテキスト図はビジネス・モデルを記述したBusiness.mdから生成するアプローチをとっています。

前回はビジネス・モデルを記述するBusiness.mdのフォーマットについて説明しました。

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

Business.md

作成したBusiness.mdは次のものです。以下で各項目について説明します。

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

Overview

モデルの先頭のセクションはOverviewとなっています。ここにこのモデルの全体情報を記述します。

以下のようにscopeにbusinessが指定されているので、このモデルのスコープがビジネス・スコープであることを示しています。

- scope : business

System

最初のセクションはSystemです。このセクションはビジネス・システムを構成するシステムを記述します。システムはそれぞれ子セクションに記述します。子セクションの名前がシステム名です。

本モデルでは以下の3つのシステムが記述されています。

Pieris Books
店舗
ECサイト

それぞれのシステムの内容を自然言語(日本語)で記述しています。

システム「Pieris Books」には以下の記述があります。

- 店舗
- ECサイト
- 店舗販売プロセス
- EC販売プロセス
- 在庫管理プロセス

これはPieris Booksの構造を記述した箇所です。

より正確に書く場合は以下のようになります。これはUMLの属性記述の文法に準拠しています。

- <<composition>> 店舗:店舗 [1..*]
- <<composition>> ECサイト:ECサイト 1
- <<participant>> 店舗販売プロセス:店舗販売プロセス
- <<participant>> EC販売プロセス:EC販売プロセス
- <<participant>> 在庫管理プロセス:在庫管理プロセス

ビジネス・オブジェクト間の関係の種類はステレオタイプによって指定します。ターゲットのビジネス・オブジェクトによってデフォルトが変わります。

システムからシステムの場合はcomposition、システムからプロセスの場合はparticipantがデフォルト値です。

Process

次のセクションはProcessです。このセクションではビジネス・プロセスを記述します。

本モデルでは以下の3つのビジネス・プロセスが記述されています。

店舗販売プロセス
EC販売プロセス
在庫管理プロセス

店舗販売プロセス

ビジネス・プロセスの店舗販売プロセスでは以下の記述があります。

- 店舗
- 店舗顧客
- 店舗販売者
- EC販売プロセス
- 在庫管理プロセス
- 決済サービス

これらは店舗販売プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

ビジネス・システム「店舗」の提供するサービスを利用する
参加するビジネス・アクターは「店舗顧客」、「店舗販売者」
連携するビジネス・プロセスは「EC販売プロセス」、「在庫管理プロセス」
使用する外部サービスは「決済サービス」

EC販売プロセス

ビジネス・プロセスのEC販売プロセスでは以下の記述があります。

- 在庫管理プロセス
- 外部ECサービス

これらはC販売プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

連携するビジネス・プロセスは「在庫管理プロセス」
使用する外部サービスは「外部ECサービス」

在庫管理プロセス

ビジネス・プロセスの在庫管理プロセスでは以下の記述があります。

- 販売管理者
- 配送サービス

これらは在庫管理プロセスを構成するビジネス・オブジェクトです。以下の情報が分かります。

参加するビジネス・アクターは「販売管理者」
使用する外部サービスは「配送サービス」

Actor

次のセクションはActorです。このセクションではビジネス・アクターを記述します。

アクターごとにサブセクションを設けます。サブセクション名がアクター名、サブセクションの内容がアクターの説明になります。

本モデルでは以下の9つのビジネス・アクターが記述されています。

店舗顧客
EC顧客
外部ECサービス
決済サービス
配送サービス
店舗販売者
店舗運営者
販売管理者
システム管理者

アクターについて、構造化した情報を記述できるようになっていますが、現段階では自然言語による説明文のみとなっています。

モデルの完成度

ビジネス・プロセスの定義はより詳細化していくことも可能ですが、今回はITシステムを開発する上での補完的な予備モデルという位置づけなので一旦ここまでにしておきます。

まとめ

今回はコンテキスト図を描くのに十分な情報量を持ったビジネス・モデルをBusiness.mdに記述しました。

次回はBusiness.mdの構造をもう少し掘り下げてみます。

2024年8月31日土曜日

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

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

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

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

この中でビジネス・コンテキスト図はビジネス・モデルを記述したBusiness.mdから生成するアプローチをとっています。

Business.md

Business.mdはPieris Booksのビジネス・モデルをMarkdown形式で記述したものです。

前回作成したモデルは以下のモデル要素で構成されていました。

System: ビジネス・システム
Process: ビジネス・プロセス
Actor: ビジネス・アクター

ビジネス・コンテキスト図を描くために必要なモデル要素はビジネス・システムとビジネス・アクターですが、これに加えてビジネス・プロセスを記述しています。

ビジネス・プロセスを使用しないモデルも可能ですが、ビジネス・プロセスはビジネス・モデルを束ねる重要なモデル要素なので使ってみました。

今回はこのビジネス・プロセスについて説明します。

ビジネス・プロセス

ビジネス・プロセスはアクティビティを拡張したモデル要素でビジネスの構成を記述します。

ビジネス・モデルの具体的な振る舞いを記述するのではなく、ビジネスの構造を各種ビジネス・オブジェクトとの関係を中心に記述します。

ビジネス・プロセスの基本形は以下になります。

ビジネス・プロセスに対する入力オブジェクトがありビジネス・プロセスが実行された結果、出力オブジェクトが出力されます。

ビジネス・プロセスの実行の過程で様々なビジネス・オブジェクトが関係してきます。

ビジネス・プロセスがどのように実行されるのかは、さらにモデリングを進めて明確にしていきます。

今回の開発はITシステム開発に必要な文脈を確定するためにビジネス・モデルを作成するので、必要最小限のざっくりとしたモデルの作成を目指します。

ビジネス・オブジェクト

ビジネス・プロセスは以下のビジネス・オブジェクトを束ねます。

Goal: ビジネス・ゴール
Actor: ビジネス・アクター
Entity: ビジネス・エンティティ
Event: ビジネス・イベント
Rule: ビジネス・ルール
Information: ビジネス・インフォメーション
Physical: 物理的なもの
UseCase: ビジネス・ユースケース
BusinessFlow: ビジネス・フロー

Goal

Goalはビジネス・ゴールを記述します。

Actor

Actorはビジネス・アクターを記述します。

Entity

Entityはビジネス・エンティティを記述します。

Event

Eventはビジネス・イベントを記述します。

Rule

Ruleはビジネス・ルールを記述します。

Information

Informationはビジネス・プロセスの遂行に必要な情報を記述します。

Physical

Informationはビジネス・プロセスの遂行で使用される物理的なものを記述します。

UseCase

UseCaseはビジネス・ユースケースを記述します。

ビジネス・ユースケースはビジネス・システムの利用者などのアクターがビジネス・システムを通して目標を達成する物語を記述します。この物語をビジネス・システムの要求仕様とします。

BusinessFlow

ビジネス・プロセスの具体的な振る舞いはアクティビティ図によるビジネス・フローで記述することができます。

関係

ビジネス・プロセスはビジネス・オブジェクトを入力し、ビジネス・プロセス実行の結果作成されるビジネス・オブジェクトを出力するのが基本構造です。

そして、ビジネス・プロセス実行では様々なビジネス・オブジェクトが関係を持ちます。主に以下のようなビジネス・オブジェクトが使用されます。

archieve: 達成
service: サービス
worker: ワーカー
client: クライアント
manager: 管理者
maintainer: 保守者
control: コントロール
supply: 提供

archieve

archieveは達成する関係を記述します。ビジネス・ゴールをビジネス・プロセスに設定する時に使用します。

service

ビジネス・プロセスの外にあるサービス(アクターとしてモデル化)を設定します。

worker

ビジネス・プロセスを遂行する人間(アクターとしてモデル化)を設定します。

client

ビジネス・プロセスを利用する人間や組織(アクターとしてモデル化)を設定します。

manager

ビジネス・プロセスを管理する人間(アクターとしてモデル化)を設定します。

maintainer

ビジネス・プロセスを運用する人間(アクターとしてモデル化)を設定します。

control

ビジネス・プロセスを制御するビジネス・オブジェクトを設定します。

supply

ビジネス・プロセスの遂行に必要なビジネス・オブジェクトを設定します。

まとめ

今回はビジネス・プロセスの概要について説明しました。

次回はビジネス・プロセスの具体例について説明する予定です。

2024年7月31日水曜日

Cozyモデル駆動開発/ビジネス・コンテキスト(2)

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

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

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

この中でビジネス・コンテキスト図はUMLで作成しました。

UMLは強力なモデリング言語ですが、以下の理由によりプレインテキスト・ベースのモデルの方が利便性が高いのではないかと考えています。

UMLでは自然言語による仕様記述がうまく扱えない
グラフィカル言語は複雑なモデルの記述が煩雑になる
Gitによるバージョン管理などテキスト形式向けのサービスが受けられない

Cozyではプレインテキストによって、仕様記述の中にモデルを埋め込む形のモデル記述ようのフォーマットを用意しています。ただし、UMLのメタ言語は強力であり業界標準でもあるのでそのまま踏襲し、必要に応じて必要なスコープ、粒度のUMLを生成する、というアプローチを取っています。

いわゆる文芸的モデリング(literature modeling)です。

Cozyでは、ここまで見てきたようにorg形式で記述したCozyモデルを使用して以下の処理を行うことができます。

Relational Databaseの入出力
UML図(クラス図)の生成
Webでのエンティティの参照更新

このCozyモデルからビジネス・コンテキスト図を生成したいわけです。

Cozyモデル

Pieris Booksプロジェクトを通してCozyの機能とモデルをリブートするにあたり、Cozyモデルの記述形式として広く使われているMarkdownを可能にすることにしました。

今回からMarkdownによる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システムの管理を行う。

「#」で始まる行はMarkdownの見出しですが、この見出しを使ってモデルの木構造を表現します。

レベル1見出しが「Business」なので、ビジネス・モデルを記述していることを示しています。

レベル2見出しには以下のものが並んでいます。

System
Process
Actor

これはモデルの種類を示します。Systemはシステム、Processはプロセス、Actorはアクターです。

そして、それぞれの中にあるレベル3見出しはモデル名になります。

各ビジネス・オブジェクトでは各オブジェクト間の関係を以下のフィーチャーで設定しています。

composition
use
actor

compositionはUMLの合成(composition)を示します。

useはUMLの使用(use dependency)を示します。

actorはシステムやプロセスを使用するアクターを示します。

ビジネス・モデル

Business.mdでは以下の3つのモデル要素を記述しました。

システム
プロセス
アクター

それぞれについてみていきましょう。

システム

「システム」はビジネス・システムを示します。

以下の3つを定義しました。

Pieris Books
店舗
ECサイト

Pieris Booksではcompositionによって店舗とECサイトを保持していることを定義しています。このため、店舗とECサイトはPieris Booksの中ではサブシステムということになります。

プロセス

「プロセス」はビジネス・プロセスを示します。

システム開発用に作成するビジネス・モデルではビジネス・プロセスを軸にモデルを記述すると適切な抽象度でモデルを記述できます。

ビジネス・プロセスは以下の3つを定義しました。

店舗販売プロセス
EC販売プロセス
在庫管理プロセス

ビジネス・プロセスは次回に説明する予定です。

アクター

「アクター」はビジネス・アクターを示します。ビジネス・システムの外部に居て、ビジネス・システムと対話を行うビジネス・オブジェクトです。

Business.mdでは以下のビジネス・アクターを定義しました。

店舗顧客
EC顧客
外部ECサービス
決済サービス
配送サービス
店舗販売者
店舗運営者
販売管理者
システム管理者

ビジネス・コンテキスト図

ビジネス・コンテキスト図は、ビジネスを構成するシステムの境界、システム間の関係、とアクターとの関係をざっくり可視化します。

このためBusiness.mdに記述した内容をUML化すると以下になります。

前回の図に対して以下の変更を行っています。

名前変更：EC利用者→EC顧客, 店舗利用者→店舗顧客
名前変更：EC→ECシステム
追加：店舗販売者, 外部ECサービス
在庫管理サブシステムは一旦省略

Cozyでは、まだMarkdownからビジネス・コンテキスト図を出力する機能はありませんが、本記事の内容をベースに実装していく予定です。

まとめ

今回はビジネス・コンテキスト図の出力をきっかけとしてビジネス・モデルをCozyフォーマットで定義しました。

次回以降このモデルを拡張する形でITシステムの開発までつなげていくことになります。

2024年6月30日日曜日

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

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

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

ビジネス・ビジョン
ビジネス・ゴール

今回はビジネス・コンテキスト図を作成します。

「ブックカフェ併設のセレクトショップ販売店」の名前をPieris Booksとします。

ビジネス・コンテキスト図

Pieris Booksのビジネス文脈を以下の観点からビジネス・コンテキスト図で記述します。

ビジネスの境界を定める
サービス利用者
サービス提供者
使用する外部サービス

このビジネス・コンテキスト図はシステム開発のためのビジネス文脈を明確にするために、ビジネス・オーナーにヒアリングしながら開発側で作成しものです。抜けなどがある可能性はありますが、まずは起点となる土台を明確化する目的です。開発中に抜けなどが分かれば、随時追加していく想定です。

この結果作成したビジネス・コンテキスト図は以下になります。

ビジネス境界

ビジネス境界として、ビジネス・システムPierisBooksを作成しました。ステレオタイプにbusinessを設定しています。

ビジネス・システムPierisBooks内に以下の3つのビジネス・サブシステムを定義しました。

EC
店舗
在庫管理

PierisBooksに関係する各種アクターを定義しています。

サービス利用者

PierisBooksのサービス利用者は以下の2つのアクターです。

EC利用者
店舗利用者

利用者に対してECの口と実店舗の口を持っているので、それぞれの利用者をアクターとして記述しました。

EC利用者と店舗利用者が同じケースもあると思いますが、そのあたりのモデリングは後のフェーズで行う予定です。ここでは、ビジネス・システムの文脈がざっくりつかむことを優先しています。

サービス提供者

PierisBooksのサービス提供者は以下の3つのアクターです。

店舗運営者
販売管理者
システム管理者

PierisBooksの運営・管理を行うロールですが、ビジネスのレイヤーによってさまざまなロールがあります。

店舗運営者はビジネス上の店舗運営を行います。販売管理者は商品の管理などを行います。

システム管理者はビジネスとは距離をおいた形でITシステムの管理を行います。

使用する外部サービス

PierisBooksが使用する外部サービスは以下の3つのアクターとしてモデル化しました。

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

PierisBooksでは商品のショーケースとしての運営を行います。このため利用者が商品の購入を考えた場合には、PierisBooksのシステムを経由して外部ECサービスに販売・配送を依頼します。

決済サービスは店舗に在庫があった場合のECや店舗での購入で使用する想定です。

配送サービスは店舗在庫の配送を依頼します。

外部ECサービスと決済サービス、配送サービスは一部機能が重なるのでケース・バイ・ケースで使い分けることになるでしょう。このあたりの具体的な処理は今後のモデリングで考えていくことにします。

用語集

ビジネス・コンテキスト図に登場する用語をまとめて用語集を作成します。

種別には以下のものが入ります。

BS: Business System
BA: Business Actor

用語	種別	意味
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システムの管理を行う

まとめ

今回はビジネス・コンテキスト図のたたき台を作成しました。

次回は、ビジネス・コンテキストをCozyで取り扱う方法について考えます。

登録: 投稿 (Atom)