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

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

まとめ

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

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

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

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

リスト

リストで属性情報を記述する場合、以下のようにUMLベースの記法で属性名を記述します。

- id: token
- name: string
- price: token [?]

多重度は省略すると1となります。またUMLの記法に食わえて以下のマークを使うことができます。

• ? : 0..1
• + : 1..*

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

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

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

関連

関連(association)も属性と同様に以下の2つの形式で記述することができます。

• 表
• リスト

表

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

| Name  | Type       | Multiplicity |
|-------+------------+--------------|
| items | OrderItems |            * |
| user  | User       |            1 |

型(Type)の対象はEntityです。

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

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

: Associations
| Name  | Type       | Multiplicity |
|-------+------------+--------------|
| items | OrderItems |            * |
| user  | User       |            1 |

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

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

リスト

リストで関連情報を記述する場合、以下のようにUMLベースの記法で関係を記述します。

- items: OrderItems [*]
- user: User

属性と同様に多重度は省略すると1となります。またUMLの記法に食わえて以下のマークを使うことができます。

• ? : 0..1
• + : 1..*

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

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

ビジネス・モデルの場合

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

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

• 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モデル記述言語を使ってビジネス・プロセスの定義を行っていきます。

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の構造をもう少し掘り下げてみます。