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システムの開発までつなげていくことになります。
投稿
