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

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

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

まとめ

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

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

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

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で取り扱う方法について考えます。

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

前回はプロジェクトのターゲットとなるビジネスとして「ブックカフェ併設のセレクトショップ販売店」そのビジネス・ビジョンを定義しました。

今回はビジネス・ゴールを定義します。

背景

ビジネス・ゴールを考える上で難しいのが本開発におけるビジネス・オーナーの立ち位置です。

本開発のビジネス・オーナーだあるブックカフェオーナーはITには疎く、本開発ではA君がヒアリングしながらビジネス・モデルを作成しています。このため、大企業のCEOが作成するような詳細なビジネス・モデルを作成して、これをベースにソフトウェア開発を進めるということは考えられません。

ここではソフトウェア開発に必要な指針レベルのざっくりしたものを、あまり時間をかけずに作成する 方針にしましょう。

また現段階では、ソフトウェア開発のフェーズはインセプション・フェーズなので、まずはたたき台レベルのビジネス・モデルにしておいて先を進めることを優先するのも合理的です。

アプローチ

前回挙げた開発システム概要をまとめると以下になります。

• 新刊・古本の販売も行うブックカフェだったが、新しくアクセサリーや日用品のセレクト商品販売を併設することになった
• このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式
• 見本品はECサイトでの販売も行う
• 見本品中心ではあるが小型の品は少量の在庫を持って即時販売も可能

この情報を元にビジネス・ゴールを考えていきましょう。

KGI/KPI

ビジネス・ゴールを考える上で重要な概念がKGIとKPIです。

• KGI : Key Goal Indicator
• KPI : Key Performance Indicator

KGIはビジネス上のゴールとなる指標で、売上高や粗利益といった会計などを中心とした目標を使うのが一般的です。

ただ、売上高や粗利益といった大きな枠組みの目標では、日々のビジネス活動に直接当てはめることは難しいので、中間目標としてビジネスのパフォーマンスの指標であるKPIを導入します。

つまり一つのKGIに対して、KGIを達成するための中間目標であるKPIが複数存在するという親子関係になります。

本来はこのKGI/KPIをビジネス・ゴールに盛り込みたいところです。

ただ、ビジネス・オーナーはもちろん最終的な収益には関心がありますが、KGIやKPIといったような指標化にはあまり興味がないようです。まだインセプション・フェーズでもあるので、システムが動作して大まかな状況が見えてくるまでKGI/KPIについては保留にすることにします。

ビジネス・ゴール

今回は作業を進めるためにざっくりという方針で以下のビジネス・ゴールにしてみました。

- ブックカフェにセレクト商品販売を併設
- セレクト商品は(1)店舗在庫あるものは直接販売、(2)店舗在庫のないものはECで販売、(3)WebのECサイトでEC販売

ビジネス・ゴールはMarkdown形式で記述しています。前回挙げた開発システム概要をまとめたレベルのものですが、まずはここからざっくり始めたいと思います。

保存

ビジネス・ゴールは src/main/cozy/business 配下に goal.md として格納します。

まとめ

今回は開発システム概要を元にビジネス・ゴールを作成しました。本来はビジネス・オーナーが作成するのが理想ですが、システム開発を進めるためにビジネス・オーナーにヒアリングしながら開発側で作成したものになっています。

次回もビジネス・モデルの作成を続けます。

Cozyモデル駆動開発/ビジネス・ビジョン

ビジネスで必要とされるソフトウェア・システムの開発を開始するにあたって、ソフトウェア・システムを利用するビジネス側の文脈を明確にしておく必要があります。

ビジネス側の文脈のモデルとしてビジネス・モデルを作成しますが、今回はその最初としてビジネス・ビジョンを作成します。

インセプション・フェーズ

UP(Unified Process)にならってソフトウェア開発のフェーズを以下の4つと考えることにします。

• インセプション・フェーズ (Inception phase)
• エラボレーション・フェーズ (Elaboration phase)
• コンストラクション・フェーズ (Construction phase)
• トランジッション・フェーズ (Transition phase)

インセプション・フェーズは、システム開発の方向性を確定するためのフェーズで、仮設に基づく実装を行いその結果を評価します。

エラボレーション・フェーズでは、複数のイテレーションで開発を勧めながらシステムの最終型に向けて必要な技術要素を決めていきます。

これらの作業の結果を受けて、コンストラクション・フェーズでは具体的な肉付けを行っていきます。

一通り開発が終了した後、トランジッション・フェーズではプロジェクトのクロージングや保守体制への以降を行います。

今回からプロジェクトの立ち上げとなるインセプション・フェーズの活動を進めていきます。

開発システムの概要

今回の開発ターゲットはブック・カフェの販売システムです。

このブック・カフェでは、新刊・古本などの書籍に加えてアクセサリーや日用品などのセレクト商品の販売をしています。

もともと新刊・古本の販売も行うブックカフェでしたが、新しくアクセサリーや日用品のセレクト商品販売を併設することにしました。

このセレクト商品は見本品の展示を基本と考えており、見本品に対してECでオーダをする方式を主に考えています。また見本品はECサイトでの販売も行います。

とはいえ、見本品中心ではありますが小型の品は少量の在庫を持って即時販売も可能にしたいと考えています。

開発体制

以下の開発体制を想定しています。

• フロントエンド開発者 1人
• バックエンド開発者 1人
• ブックカフェオーナー 1人 (発注者)

ブックカフェオーナーのX氏から個人でシステム開発を受注したA君がバックエンド開発を行い、フロントエンドエンジニアのB君にUI開発を依頼するという体制です。

ブックカフェオーナーはITには疎いので、A君がヒヤリングを行いながら自前でビジネス・モデルと要求モデルを作成していく想定です。

フォーマット

ビジョンの記述には以下のフォーマットを使用することにします。

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

このフォーマットを使ってビジネス・モデルのビジョンとシステムの要求モデルのビジョンの2種類を作成していきます。

ビジネス・ビジョン

ビジネス・システムのモデルでは、ビジネスそのもののビジョンをビジネス・ビジョンとして定めます。

X氏と話し合って以下のビジネス・ビジョンを定義しました。X氏はこういったドキュメントの作成に乗り気ではありませんので、ソフトウェア開発側で意識するビジョンとしてメモ的に作成したものです。今後の開発で随時調整していくことを想定しています。

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

まずブックカフェ併設のセレクトショップの名前を仮にBCwSG(Book Cafe With Select Goods)と決めました。

ターゲットとなる利用者を「本を読みながらカフェでのんびりしたい人」とし、セレクトショップ販売店に「カフェの利用者にセレクト商品の紹介と販売を行うことができる」ことをビジネス上の価値としました。

これが通常のセレクト・ショップに対するアドバンテージと考えています。

保存

ビジネス・ビジョンは src/main/cozy/business 配下に vision.txt として格納します。

まとめ

今回からブックカフェ併設のセレクトショップBCwSGを題材に具体的なモデリングを進めていきます。

インセプション・フェーズの最初のモデルとしてビジネス・ビジョンを作成しました。

モデリングを行いながら各作業分野で定義していくモデルを明らかにしていきたいと思います。

Cozyモデル駆動開発/成果物の管理

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみます。

ファイル構成

図はCozyモデル駆動開発におけるプロジェクトのファイル構成の案です。

プログラムはScalaによる記述を想定しているのでsbtのファイル構成を踏襲しています。

srcディレクトリの配下に以下のディレクトリを配置します。

main

メインのソースコード

test

テストのソースコード

さらにmain配下に以下のディレクトリ配置します。

cozy

Cozyモデル

scala

Scalaプログラム

以下でそれぞれの内容について説明します。

Cozyモデル

src/main/cozyディレクトリにCozyモデルを格納します。

Cozyでは、Cozyモデルと後述のScalaモデルの両方のコンテンツの情報を統合してプロジェクトのCozyモデルを作成します。

CozyモデルはScalaモデルで記述しきれない仕様をCozy形式で記述します。

cozyディレクトリには以下のディレクトリを配置します。それぞれのディレクトリが対応するモデルを格納します。

• business : ビジネス・モデル
• requirement : 要求モデル
• analysis : 分析モデル
• design : 設計モデル

ビジネス・モデル

businessディレクトリにはビジネス・モデルを格納します。

ソフトウェア開発におけるビジネス・モデルでは、開発するソフトウェアのビジネス上の位置づけや用途などのビジネス文脈を記述します。

ビジネス・システムを駆動するビジネス・モデルを作成し、これをソフトウェア開発の入力にするのが理想ですが、そのような本格的なアプローチが取れない場合はソフトウェア開発に必要な範囲でビジネス文脈を整理するのがよいでしょう。

前回はEssenseのアルファとしてビジネス・システム・アルファとして定義しました。

記述するモデルの候補としては以下のものが考えられます。

• ビジョン
• ゴール
• ビジネス・コンテキスト
• ビジネス・ユースケース
• ドメイン・モデル

また、ビジネスの計測と結果のフィードバック・ループに対応するため以下のモデルについても扱っていく予定です。

• KGI(Key Goal Indicator)
• KPI(Key Performance Indicator)

モデルは基本的には通常ファイルに自然言語のテキストとして記述する形になりますが、コンテキスト・モデルは図として記述するのが適切なので、これをどのように記述するのかは工夫が必要そうです。

要求

requirementディレクトリには要求モデルを格納します。

記述するモデルの候補としては以下のものが考えられます。

• ビジョン
• ゴール
• コンテキスト・モデル
• ユースケース

ビジョン、ゴール、コンテキスト・モデル、ユースケースはビジネス・モデルと同じ項目ですが、開発対象となるソフトウェア・システムのビジョン、ゴール、コンテキスト・モデル、ユースケースという点が異なります。

またビジネス・モデルで定義したKGIやKPIも、必要に応じて要求モデルに引き継がれるでしょう。

モデルの記述方法はビジネス・モデルと同様に通常ファイルに自然言語で記述するものが中心となります。

分析

analysisディレクトリには分析モデルを格納します。

作業分野「分析」と「設計」はEssense標準ではShape the Systemアクティビティ空間に所属するアクティビティということになるでしょう。

分析はPIM(Platform Independent Model)を、設計はPSM(Platform Specific Model)を記述するというモデルの抽象度に違いがあります。

しかし、実装主導の開発では開発ではPIMを意識しつつPSM主体の設計になると思うので、実務的には要求から直接設計に進み、必要に応じて分析も行う、というところが実際のところかもしれません。この点も加味して分析について検討していく予定です。

設計

designディレクトリには設計モデルを格納します。

設計モデルでは、実装に直結したモデルを構築します。

設計モデルを考える上で重要なのはプログラム自身が設計になっているといる点です。特にオブジェクト指向プログラミングで記述した場合には、オブジェクト・モデルとのインピーダンス・ミスマッチが低いので、場合によってはそのままモデルと考えてもよいかもしれません。

しかし、プログラミングの場合はプログラム動作上のさまざまな処理を追加していくため、抽象的なモデルとずれてきたり、境界が曖昧になってきます。この問題に対応するためアノテーションの仕組みを使ってモデルとして扱う箇所とモデルとして位置づけを記述していくことになるでしょう。また、JavaやScalaではプログラム内に仕様を自然言語で記述する仕組みがあるので、これを用いてより詳細にモデルの情報を記述することができます。

すべてのモデルをアノテーション付きプログラムで記述することはできないので、この記述できない部分は別の形でモデルを記述することになります。

一つはドメイン・モデルなど定型化して形式で記述したモデルです。

このモデルからはインタープリタで直接実行したり、実装を自動生成することができます。

最後にアーキテクチャ全体の情報やコンポーネントやクラスなどの仕様に関して自然言語による記述を行う場合があります。このような記述は通常ファイルに記述した上でプログラム・モデルと統合して設計モデルを組み上げていくことになるでしょう。

Scalaプログラム

本シリーズではプログラミング言語にScalaを用います。

Scalaプログラムとして開発するソフトウェアの本体のプログラムとテスト・プログラムを作成します。

本体

開発ターゲットの本体のScalaプログラムはsrc/main/scalaディレクトリに格納します。

前述したようにScalaプログラムにアノテーションとScaladocを併用することで、モデルとして扱うことができます。

プログラミング言語としてScalaを使用するので、Scaladoc形式でインタフェース仕様を記述します。

Cozyは、モデル、プログラム、テスト・ケースからそれぞれに記述された仕様を集め、マージしたものをプロジェクトの仕様として統合します。

テスト

Scalaによるテスト・プログラムはsrc/test/scalaディレクトリに格納します。

Cozyモデル駆動開発ではTDD(Test-Driven Development)、BDD(Behavior-Driven Development)でテストを動く仕様(executable specification)として扱っていきます。

これはテストを要求仕様、コンポーネント仕様として作成して活用していくという意図があります。

この場合は、自然言語で記述した要求モデルとどのように連携していくのかがポイントとなるでしょう。

TDD, BDDの基盤としてscalatestを使用する想定です。

まとめ

今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみました。

次回はビジネス・モデルについて具体的に考えていく予定です。

Cozyモデル駆動開発/ビジネス・モデリング

モデル駆動開発ワークベンチCozyを使用したモデル駆動開発を具体的に考えて、Cozyへの機能要件を洗い出しています。

Cozyを使用したモデル駆動開発をCozyモデル駆動開発 (Cozy Model-Driven Development)、略してCMDDと呼ぶことにします。

ビジネス・モデリングの位置付け

まず最初の作業分野はビジネス・モデリングです。

ビジネス・モデリングの関心分野の候補としては、カスタマー(Customer)とソルーション(Solution)が考えられます。

Essenceカーネルではカスタマーには以下のアルファが定義されています。

• ステークホルダー(Stakeholders)
• 機会(Opportunity)

またソルーションには以下のアルファが定義されています。

• 要求(Requirements)
• ソフトウェア・システム(Software System)

ビジネス・モデリングをどの関心分野のどのアルファにどのような形で組み込むかは、開発プロセス内でのビジネス・モデリングの目的によって変わってくるところでしょう。

CMDDでは小規模チームで、中小規模アプリケーションまたは大規模アプリケーションのサブシステムの開発をターゲットにします。

ビジネス・モデリングは要求アルファの入力の情報になるものなので、ソルーションの補助的な活動と考えると要求アルファにアクティビティと成果物を追加するアプローチも考えられます。

また、ビジネス・モデリングはソルーションの外側、カスタマー側の情報と考えるとカスタマー側に配置することも考えられます。その場合はステークホルダー、機会といったアルファに入れるよりも、新しくビジネス・モデリングを行うアルファを追加するのがよさそうです。

今回は関心分野カスタマーに新規のアルファとしてビジネス・システム・アルファを追加して検討を進めることにします。

ビジネス・システム・アルファ

ビジネス・モデリングではビジネス・システムをモデリングします。

このビジネス・システムをモデリングするアルファをビジネス・システム・アルファとします。ビジネス・システム・アルファの成果物(Work Product)として以下のモデルを考えます。具体的なモデルを作ってみて調整していく予定です。

• ビジョン
• ビジネス・コンテキスト
• ビジネス・ユースケース
• ドメイン・モデル

ビジョン

ビジョン(Vision)はプロジェクトのビジネス・システム上のビジョンです。

プロジェクトの全体の方向性を定めます。

このビジョンをベースに、要求アルファでソフトウェア開発上のビジョンを定める想定です。

ビジネス・コンテキスト

ビジネス・システムのおかれている環境をビジネス・コンテキストとしてモデル化します。

ビジネス・システムと関係する外部組織の存在とインタラクションを明確にします。

ビジネス・ユースケース

ビジネス・ユースケース(Business UseCase)はビジネス・システムにおけるユースケースです。

ビジネス・コンテキストの舞台の上で、ビジネス・システムの各種利用者が体験する物語を記述します。

開発対象のソフトウェア・システムはこの物語の中に登場し、物語の遂行を助けます。

要求アルファで作成する(システム)ユースケースは、ビジネス・ユースケースの物語の中での利用方法を切り口に・ソフトウェア・システムと利用者の対話の物語を記述することになります。

ドメイン・モデル

ドメイン・モデル(Domain Model)はソフトウェア・システムの操作対象となる問題領域(problem domain)のモデルです。

ドメイン・モデルはビジネス・システムとソフトウェア・システムで一本化したいので、その方向で検討を進めます。

ただ、ビジネス・システムとソフトウェア・システムのモデルの規模が違いすぎる場合は別立てで管理した方がよいかもしれません。そのあたりの考察も進めていきたいと思います。

まとめ

今回は要求アルファの入力となるビジネス・モデリングの扱いについて考えてみました。

ここでは、関心分野カスタマー側にビジネス・システム・アルファとして入れることにしましたが、その是非は今後の考察で検討していきたいと思います。

次回は、ビジネス・システム・アルファの具体的な検討に入る前に、モデルなどの成果物の管理方法について検討します。

Cozyによるモデル駆動開発

モデル駆動開発のエコシステムを支えるキーパーツとして、Webアプリケーション・フレームワークのCozy Webを開発してきました。

今回からCozyを使用したモデル駆動開発について具体的に考えていきたいと思います。

Cozyは現在開発途中ですが、モデル駆動開発に必要な機能を拡張していく上でどのような機能が必要かの洗い出しが目的です。要求モデルにおけるユースケース分析的なアプローチですね。

EssenceというOMGが標準化している開発方法論フレームワークの枠組み、用語を使用して考えていくことにします。

実際の検討に入る前に、今回は開発方法論を記述する言語として使用するEssenceについてみていきます。

Essence

EssenceはSoftware Engineering Methods and TheoryとObject Management Group®によって作成された開発方法論のフレームワークです。

• https://www.omg.org/spec/Essence/

Essenceでは開発方法論を記述する言語(Language)と基本的な枠組み(Kernel)を定めており、この骨組みにプラクティスで肉付けすることで開発方法論を定義します。

Essenceの言語では、従来のモデリングの用語に加えて、新しい用語が導入されています。その点も含めて用語の整理をします。

基本概念

アルファ

アルファ(alpha)は開発作業を進める上で必要な各種概念を表現したものです。アルファの具体例として要求(requirement)やソフトウェア・システム(software system)があります。

アルファに対応する日本語用語はないと思うので、本Blogではアルファの用語を使います。

ワーク・プロダクト

ワーク・プロダクト(work product)はソフトウェア開発の各種成果物です。

ワーク・プロダクトの例としては要求仕様(要求アルファ)やコード(ソフトウェア・システム・アルファ)があります。

アクティビティ

アクティビティ(activity)はソフトウェア開発の活動を表現します。

アクティビティの例としては「ミーティングを開く(Holding a meeting)や「コードを書く(Writing Code)」があります。

アクティビティ・スペース

アクティビティ・スペース(activity space)はソフトウェア開発の活動分野を表現したものです。

アクティビティ・スペース内でアクティビティが実行されます。

アクティビティ・スペースの例としては「ステークホルダー・ニーズを理解する」や「システムを実装する」などがあります。

コンピテンシィ

コンピテンシィ(competency)は作業を進めるのに必要な各種能力です。

コンピテンシィの具体例としてはステークホルダー代表(カスタマー関心分野)や開発(ソルーション関心分野)などがあります。

関心分野

Essenceではソフトウェア開発の関心分野(area of concern)として以下の3つを定義しています。

• カスタマー
• ソルーション
• エンデバー

Essenceのアクティビティはこの関心分野のどれかに所属することになります。

カスタマー

カスタマー(customer)はソフトぅエア・システムの利用方法についての関心分野です。

Essenceカーネルではカスタマーの関心分野で以下のアルファを定義しています。

• ステークホルダー (stakeholder)
• 機会 (opportunity)

また以下のアクティビティ・スペースを定義しています。

• 可能性を探る (Explore Possibilities)
• ステークホルダー・ニーズを理解する (Understand Stakeholder Needs)
• ステークホルダーの満足を確保する (Ensure Stakeholder Satisfaction)
• システムを利用する (Use the System)

ソリューション

ソルーション(solution)はソフトウェアの実現に関しての関心分野です。

Essenceカーネルではソルーションの関心分野で以下のアルファを定義しています。

• 要求 (requirement)
• ソフトウェア・システム (software system)

また以下のアクティビティ・スペースを定義しています。

• 要求を理解する (Understand the Requirements)
• システムを形作る (Shape the System)
• システムを実装する (Implement the System)
• システムをテストする (Test the System)
• システムを配備する (Deploy the System)
• システムを運用する (Operate the System)

エンデバー

エンデバー(endevor)は直訳すると「努力」ですが、ここではチームが努力して進める活動というような意味合いから選ばれた用語ではないかと思います。

エンデバーに対応する日本語用語はないと思うので、本Blogではエンデバーの用語を使います。

Essenceカーネルではソルーションの関心分野で以下のアルファを定義しています。

• チーム (team)
• ワーク (work)
• 仕事の進め方 (way of working)

また以下のアクティビティ・スペースを定義しています。

• ワークの準備をする (Prepare to do the Work)
• アクティビティを協調させる (Coordinate Activity)
• チームをサポートする (Support the Team)
• 進捗を追尾する (Track Progress)
• ワークを止める (Stop the Work)

まとめ

本ブログでCozyを使用したモデル駆動開発に対する分析を始めることにしました。

開発プロセスを記述するためのフレームワークとしてOMGのEssenceを使用します。今回はその準備としてEssenceの用語の整理をしました。

次回はビジネス・モデリングんいついて考えます。