2025年7月31日木曜日

Cozyモデル駆動開発/ユースケース・モデル

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

要求モデルをCozyモデルとして定義する方法について考えています。

前回は要求項目のモデルを考えました。

今回からユースケース・モデルについて考えていきます。

ユースケース・モデル

ユースケースは、システムの利用者が目的を達成するために体験する物語を記述したモデルです。

Cozyモデル駆動開発(CMDD)ではユースケース・モデルを要求モデルの中核モデルとしています。

ユースケース・モデルの記述にはUMLのユースケース図も使用しますが、モデルの本体は自然言語で書かれたユースケース記述です。ユースケース記述の集まりによって記述されるユースケース・モデルの概要を図示したものがユースケース図です。

このためCMDDではCozy Modeling Language(CML)によって記述したユースケース記述の集まりから必要に応じてユースケース図をCozyで生成するアプローチを取ります。

ユースケース記述

ユースケース記述の内容を基本情報と拡張情報に分けて考えます。

基本情報

ユースケース記述の基本情報は以下の項目で構成されます。

nametypemultdescription
ididentifier1ユースケースID
namename1ユースケース名
titlei18ntitle?タイトル
goali18ntext1プライマリ・アクターの目的
summaryi18ntext?
primary actorname1プライマリ・アクター
triggertext?トリガー

id

ユースケースを一意に識別するためのIDです。

name

ユースケースの論理名です。利用者の目的をベースにソフトウェアで識別しやすい名前をつけます。

title

ユースケースを人間向けに説明するラベルです。画面や文書上に表示されます。利用者の目的をベースにしたタイトルをつけます。多国語で定義することができます。

goal

このユースケースが達成すべき、プライマリ・アクターの目的です。多国語で定義することができます。

summary

このユースケース全体の簡潔な説明です。システムやアクターの主要な振る舞いを要約します。多国語で定義することができます。

primary actor

このユースケースを開始し、利益を得る主なアクターです。

trigger

このユースケースを開始する外的な出来事や操作です。

拡張情報

ユースケースの拡張情報はユースケースを高度に使用したい場合に用いる情報です。

nametypemultdescription
secondary actorname?セカンダリ・アクター
supporting actorname*スポーティング・アクター
preconditiontext*事前条件
postconditiontext*事後条件
prioritytoken?優先度
statustoken?状態

secondary actor

セカンダリ・アクターはこのユースケースに関与しますが、主要な操作主体ではないアクターです。

supporting actor

サポーティング・アクターはユースケースにおいて支援的な役割を果たすシステムやアクターです。

precondition

ユースケースが正しく開始されるために、事前に満たされているべき条件です。

postcondition

ユースケースが成功裡に完了した後に成立すべきシステムやアクターの状態です。

priority

このユースケースの重要度や実装上の優先順位です。

status

ユースケース記述の完成度やレビュー状況などのステータスです。

まとめ

今回はユースケース・モデルのユースケース・記述の基本情報と拡張情報の項目の洗い出しを行いました。

次回はCML(Cozy Modeling Language)での記述方法について考えます。

2025年6月30日月曜日

Cozyモデル駆動開発/要求項目モデル

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

要求モデルをCozyモデルとして定義する方法について考えています。

前回はコンテキスト・モデルを作成しました。

今回から要求モデルの作成を開始します。

要求項目モデル

Cozyモデルはユースケース駆動が軸となるので、ユースケース・モデルが重要なモデルとなりますが、ユースケース・モデル以外のモデルも目的毎に併用する形になります。

要求仕様をまとめるにあたって、ユースケースのような詳細なモデルに入る前の準備モデルといった位置付けのモデルが必要になります。

この目的で用意しているのが要求項目モデルです。

要求項目は以下の属性を持つシステムで実現したい要求で、この要求項目の集まりが要求項目モデルとなります。

  • 管理番号 (No)
  • 名前 (Name)
  • 内容 (Content)
  • 優先度 (Priority)
  • 作成日時 (CreatedAt)
  • 更新日時 (UpdatedAt)

属性は日本語と対応する英語を定義していますが、モデル記述時にはどちらを使ってもかまいません。

優先度

要求項目の優先度は以下のMoSCoW基準で記述します。

優先度展開形意味備考
MMust have必須要求
SShould have重要要求
CCould have可能であれば実現要件
WWant to have将来検討要望

フォーマット

モデル記述のフォーマットは以下のものになります。

  1. # 要求項目  
  2. ## 商品の販売  
  3. | Item       |          値 |  
  4. |------------+------------|  
  5. | No         |        001 |  
  6. | Priority   |          M |  
  7. | CreateDate | 2025-06-30 |  
  8. | UpdateDate | 2025-06-30 |  
  9. ### 内容  
  10. Web画面経由で商品の販売を行う。  
  11. ## 商品の発送  
  12. | Item       |          値 |  
  13. |------------+------------|  
  14. | No         |        002 |  
  15. | Priority   |          S |  
  16. | CreateDate | 2025-06-30 |  
  17. | UpdateDate | 2025-06-30 |  
  18. ### 内容  
  19. 販売した商品の発送を発送システムに依頼する。  

要求項目

以下のように要求項目セクションを宣言するとその内容が要求項目モデルになります。

  1. # 要求項目  

要求項目の名前

以下のようにサブセクションのタイトルが要求項目の名前になり、サブセクション内の情報が要求項目のモデルとなります。

  1. ## 商品の販売  

プロパティ

各種属性は以下のようなプロパティの表で一括して記述することができます。

  1. | Item       |          値 |  
  2. |------------+------------|  
  3. | No         |        001 |  
  4. | Priority   |          M |  
  5. | CreateDate | 2025-06-30 |  
  6. | UpdateDate | 2025-06-30 |  

内容サブサブセクション

タイトルが「内容」または「Content」のサブサブセクションにはモデルの内容を記述します。

  1. ### 内容  
  2. Web画面経由で商品の販売を行う。  

管理方法

Cozyモデルの記述方法として上記のテキスト・フォーマットを定めています。このテキストをCozyが読み取って処理します。

また、同等の情報があれば要求管理システム、バグ管理システムやExcelなどの表計算ソフトのフォーマットでの管理も可能です。この場合、Cozyで処理をするためには連携アダプタが必要になります。

まとめ

今回は要求項目モデルを定義しました。

次回も引き続き要求分析を進めます。

2025年5月31日土曜日

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

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

要求モデルをCozyモデルとして定義する方法について考えています。

前回はビジョン宣言を作成しました。ビジョン宣言によってシステム開発の目的やスコープがざっくりと定められたことになります。

続いて、今回はコンテキスト・モデルを作成します。

コンテキスト・モデル

コンテキスト・モデルは、開発対象の大枠についてシステムの外部とシステムとの関係を中心にモデル化したものです。コンテキスト図という形でビジュアル表現にして、全体を俯瞰することを可能にします。

ビジネス分析でビジネス・システム向けのコンテキスト・モデルであるビジネス・コンテキストを作成しました。まず、このビジネス・コンテキストを確認した後に、システム開発向けのコンテキスト・モデルを作成します。

ビジネス・コンテキスト

「Cozyモデル駆動開発/ビジネス・コンテキスト(2)」の回で、ビジネス・モデルのビジネス・コンテキストをCozy形式で作成しました。Cozyのアプローチでは、Cozyオブジェクト・モデルからコンテキスト・モデルを抽出しコンテキスト図を生成します。

ビジネス・モデルではBusiness.mdとして以下のモデルを記述しました。このモデルから必要に応じてコンテキスト・モデルを記述するコンテキスト図を生成しました。

  1. # Business  
  2. ## System  
  3. ### Pieris Books  
  4. Pieris Booksビジネス。  
  5. - composition :: 店舗, ECサイト  
  6. - use :: 店舗販売プロセス  
  7. - use :: EC販売プロセス  
  8. - use :: 在庫管理プロセス  
  9. 店舗とECサイトで商品販売を行う。  
  10. 店舗には売れ筋商品のみ実商品を在庫として保管し、その場で販売を行う。  
  11. 通常の商品は見本品のみ展示し、注文があった場合はEC販売プロセスで決済と配送を行う。  
  12. EC販売プロセスでは外部ECサービスを用い、決済や在庫管理、配送処理を外部ECサービスが  
  13. 提供するものを利用する。  
  14. ただし、店舗顧客には通常の店舗での購入と同様にレジによるオペレーションで販売処理を行う。  
  15. ### 店舗  
  16. Pieris Booksの実店舗。  
  17. ### ECサイト  
  18. Pieris BooksのECサイト。  
  19. ## Process  
  20. ### 店舗販売プロセス  
  21. 店舗で商品販売を行う。  
  22. - actor :: 店舗顧客  
  23. - actor :: 店舗販売者  
  24. - use :: 在庫管理プロセス  
  25. - use :: 店舗  
  26. - use :: EC販売プロセス  
  27. - use :: 決済サービス  
  28. ### EC販売プロセス  
  29. ECサイトで商品販売を行う。  
  30. - use :: 在庫管理プロセス  
  31. - use :: 外部ECサービス  
  32. ### 在庫管理プロセス  
  33. 実店舗での在庫管理を行う。  
  34. - actor :: 販売管理者  
  35. - use :: 配送サービス  
  36. 在庫管理の延長で配送サービスへの受け渡しも行う。  
  37. ## Actor  
  38. ### 店舗顧客  
  39. 店舗の利用者。  
  40. 店舗に在庫がある場合は直接購入することができる。  
  41. 店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。  
  42. ### EC顧客  
  43. ECサイトの利用者。  
  44. ### 外部ECサービス  
  45. 見本品を購入する際に使用する外部のECサービス。  
  46. ### 決済サービス  
  47. ECまたは店舗での商品販売に使用する決済サービス。  
  48. ### 配送サービス  
  49. ECでの商品販売を依頼する配送サービス。  
  50. ### 店舗販売者  
  51. 店舗で商品の販売を行う。  
  52. 店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。  
  53. ### 店舗運営者  
  54. ビジネス上の店舗運営を行う。  
  55. ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。  
  56. ### 販売管理者  
  57. 店舗での商品管理などを行う。  
  58. ### システム管理者  
  59. Pieris BooksのITシステムの管理を行う。  

オブジェクト・モデル

ビジネス・コンテキスでは、コンテキスト・モデルとしてコンテキスト図を作成するのではなく、オブジェクト・モデルを作成し、このオブジェクト・モデルからコンテキスト・モデルを記述するコンテキスト図を生成するアプローチをとっています。

システム開発向けのコンテキスト・モデルでも同様のアプローチを取ります。

このアプローチの元、作成したオブジェクト・モデルが以下のものです。

  1. Pieris Book Store System  
  2. ========================  
  3. # System  
  4. ## Pieris Book Store System  
  5. Pieris Books StoreのECシステム。開発対象のシステム。  
  6. # SubSystem  
  7. ## EC  
  8. ECサイトからの販売を管理するサブシステム。  
  9. 販売管理処理はCommerceに移譲する。  
  10. - use :: Commerce  
  11. ## Store  
  12. 店舗からの販売を管理するサブシステム。  
  13. 販売管理処理はCommerceに移譲する。  
  14. - use :: Commerce  
  15. ## Commerce  
  16. 販売管理を行うサブシステム。  
  17. 外部ECサービスと決済サービスを使用する。  
  18. - use :: 外部ECサービス  
  19. - use :: 決済サービス  
  20. ## StockManagement  
  21. 在庫管理を行うサブシステム。  
  22. - use :: 配送サービス  
  23. # Actor  
  24. ## 店舗顧客  
  25. 店舗の利用者。  
  26. 店舗に在庫がある場合は直接購入することができる。  
  27. 店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。  
  28. - use :: 店舗販売者  
  29. ## EC顧客  
  30. ECサイトの利用者。  
  31. - use :: EC  
  32. ## 店舗販売者  
  33. 店舗で商品の販売を行う。  
  34. 店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。  
  35. - use :: Store  
  36. ## 店舗運営者  
  37. ビジネス上の店舗運営を行う。  
  38. ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。  
  39. - use :: Commerce  
  40. ## 販売管理者  
  41. 店舗での商品管理などを行う。  
  42. - use :: Commerce  
  43. ## システム管理者  
  44. Pieris BooksのITシステムの管理を行う。  
  45. - use :: Pieris Book Store System  
  46. # External Service  
  47. ## 外部ECサービス  
  48. 見本品を購入する際に使用する外部のECサービス。  
  49. ## 決済サービス  
  50. ECまたは店舗での商品販売に使用する決済サービス。  
  51. ## 配送サービス  
  52. ECでの商品販売を依頼する配送サービス。  

大きく以下の4つのセクションから構成されています。

  • System
  • SubSystem
  • Actor
  • External System

System

Systemセクションには、サブセクションのタイトルにシステム名とシステムの説明を記述します。

SubSystem

SubSystemセクションでは、サブセクション毎に1つのサブシステムを表します。サブセクション名がサブシステム名、サブセクション内にサブシステムの説明を記述します。

上記のモデルでは以下のサブシステムを定義しています。

EC
EC運営システム
Store
店舗運営システム
Commerce
販売システム
StockManagement
在庫管理システム

それぞれの説明文の中に以下のような形で、他オブジェクトへの参照を記述しています。

  1. - use :: Commerce  

この参照の記述がモデルとして解釈されます。

Actor

Actorセクションでは、サブセクション毎に1つのアクターを表します。オブジェクト・モデル的には外部サービスもアクターの一種ですが、CozyモデルではExternal Serviceとして別セクションで定義するようになっています。

上記のモデルでは以下のサブシステムを定義しています。

  • 店舗顧客
  • 店舗販売者
  • EC顧客
  • 販売管理者
  • 店舗運営者
  • システム管理者

それぞれの説明文の中に以下のような形で、他オブジェクトへの参照を記述しています。

  1. - use :: EC  

External Service

External Serviceセクションでは、サブセクション毎に1つの外部サービスを表します。

上記のモデルでは以下のサブシステムを定義しています。

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

コンテキスト図

今回作成したオブジェクト・モデルからCozy以下のコンテキスト図が生成される想定です。

まとめ

今回はコンテキスト・モデルの作成を行いました。

実際に作成したのはオブジェクト・モデルで、このオブジェクト・モデルからコンテキスト・モデルの記述に必要な要素だけ取得して、コンテキスト図を生成しました。

このコンテキスト図により開発対象のシステムの全体像を俯瞰することができるようになります。

次回も引き続き要求分析を進めます。

2025年4月30日水曜日

Cozyモデル駆動開発/ビジョン宣言

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

前回から要求分析に入っています。要求モデルをCozyモデルとして定義する方法について考えます。

今回はビジョン宣言を取り上げます。

ビジネス・ビジョン宣言

「Cozyモデル駆動開発/ビジネス・ビジョン」の回で、ビジネスのビジョンを記述するフォーマットとして以下のものを導入しました。

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

このフォーマットを使用して以下のビジネス・ビジョンを定義しました。

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

ビジョン宣言

ビジネス・ビジョン宣言に使用したフォーマットをシステム開発にも使用します。

ビジネス・ビジョンではセレクトショップ販売店のビジネス全体のビジョンを定義しましたが、システム開発におけるビジョン宣言は今回開発するシステムの意図と目標を定めるビジョンを定義します。

「ビジネス・ビジョン」の回で説明した通り現在はインセプション・フェーズなので、BCwSGのセレクトショップ販売店の基盤となるソフトウェア・システムの核となる構造を試行することが目的となります。

このような点を考慮して、インセプション・フェーズの開発ビジョンとして以下のものを定義しました。

  1. FOR カフェ併設セレクトショップ販売店BCwSG  
  2. WHO カフェの利用者  
  3. THE BCwSGシステム is a ブックカフェ併設のセレクトショップ  
  4. THAT カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる  
  5. UNLIKE 通常のセレクト・ショップ  
  6. OUR PRODUCT 在庫を持たずに商品販売ができる  

「カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる」点を軸に実証性の検証と実現するためのメカニズムの試行を目的に開発を進めます。

保存

作成したビジョン宣言をCozyモデルとして保存します。

以下のようにVisionセクションにビジョン宣言を記述します。

  1. # Vision  
  2. FOR カフェ併設セレクトショップ販売店BCwSG  
  3. WHO カフェの利用者  
  4. THE BCwSGシステム is a ブックカフェ併設のセレクトショップ  
  5. THAT カフェとセレクトショップ利用者に展示しているサンプル商品からECに発注できる  
  6. UNLIKE 通常のセレクト・ショップ  
  7. OUR PRODUCT 在庫を持たずに商品販売ができる  

作成したビジョン宣言のCozyモデルはsrc/main/cozy/requrement配下にvision.doxとして格納します。

まとめ

今回からブックカフェ併設のセレクトショップBCwSGのシステム開発に入ってきました。

まずシステムの意図と目標を定めるビジョン宣言を作成しました。

次回も引き続き要求分析を進めます。

2025年3月31日月曜日

Cozyモデル駆動開発/要求モデル

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

前回までビジネス・モデルの作成を行いました。

ビジネス・モデルを作成することで開発対象のシステムが動作するビジネス上の文脈を明確化しました。このビジネス文脈を前提に、要求モデルの作成を進めることになります。

今回から要求モデルのモデルの定義とCozy上での取り扱いついて検討していきます。

要求モデル

要求モデルは以下のサブ・モデルで構成されます。

  • スコープ・モデル
  • 機能要求モデル
  • 非機能要求モデル

スコープ・モデル

スコープ・モデルは開発対象システムのスコープを定めます。ビジネス・モデルの文脈の中で、システムの置かれる立ち位置、システムの責務を考えていきます。

スコープ・モデルは以下の2つのモデルで構成されます。

  • ビジョン宣言
  • システム・コンテキスト

ビジョン宣言

ビジョン宣言は、システム開発のビジョンを定義します。

ビジネス・モデルで今回のシステム開発に関わるビジネス上のビジョンをビジネス・ビジョン宣言として定義しました。このビジネス・ビジョン宣言を参考に、システム開発のビジョンを定義します。

システム・コンテキスト

システム・コンテキストは開発対象のシステムをコンテキスト図を使って記述します。

システムの利用者や外部システムなどのアクターとシステムの境界を明確にするのが目的です。

ビジネス・モデルで作成したビジネス・コンテキストをベースにシステム開発に関係する部分を詳細化したものになります。

機能要求モデル

機能要求モデルはシステムの提供する機能に関する要求仕様を記述するモデルです。

機能要求モデルは以下の2つのモデルで構成されます。

  • ユースケース・モデル
  • フィーチャ・モデル

ユースケース・モデル

ユースケース・モデルはアクターの目標と達成するための物語であるユースケースを軸とした要求モデルです。

ユースケース駆動開発は、ユースケースを軸に要求分析からシステム分析、ドキュメント、テストなどの各作業分野を駆動していく開発方式です。

ユースケースを開発の単位として開発管理を行っていきます。ただし、ユースケースだと開発の粒度が大きい場合には、一回のイテレーションにフィットするサイズにユースケースを分割したユースケース・スライスを使用してます。

フィーチャ・モデル

フィーチャ・モデルはユースケースに向かない開発項目をフィーチャとして定義したモデルです。

フィーチャ単独で定義するケースとユースケースのシナリオ内で使用するシステム機能をフィーチャとしてモデル化する場合があります。

ユースケースを補完するモデルとして使用します。

非機能要求モデル

非機能要求モデルは機能要求モデルで記述できない、機能を横断した要求項目を記述するモデルです。

非機能要求モデルは以下のようなモデルで構成されます。

  • 品質属性
  • コスト
  • 技術上の制約

品質属性

品質属性は性能、スケーラビリティ、セキュリティなど機能に対して横断的な関心事の品質要件を定義したものです。

コスト

コストはシステムの開発費やハードウェアの調達費、運用コストなどです。

技術上の制約

技術上の制約は使用することが求められているハードウェア、OS、ミドルウェアなどが代表的なものになります。

まとめ

今回は要求モデルの全体像について説明しました。

次回はスコープ・モデルのビジョン宣言について説明します。

2025年2月28日金曜日

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

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

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

  • ビジネス・ビジョン
  • ビジネス・ゴール
  • ビジネス・コンテキスト図
  • ビジネス・プロセス
  • ビジネス・ユースケース
  • ビジネス情報モデル

ビジネス・プロセスの具体的な動きをモデル化するしたい場合には、ビジネス・フロー図が有効です。UMLではアクティビティ図で記述しますが、CozyではCML(Cozy Modeling Language)で記述して必要に応じてアクティビティ図に変換します。

ビジネス・フロー

以下のドキュメントは商品購入のビジネス・フローをCML(Cozy Modeling Language)で記述したものです。

  1. # ACTIVITY  
  2. ## SalesOrder  
  3. 顧客の購入処理  
  4. ### CreateSalesOrder  
  5. 顧客が購入依頼を行う  
  6. ### DECISION: StockAvailable  
  7. 在庫の確認を行う  
  8. - Yes :: ProcessOrder  
  9. - No :: NotifyCustomer  
  10. ### ProcessOrder  
  11. 購入処理を進める  
  12. ### ShipOrder  
  13. 配送処理を進める  
  14. #### TRANSITION  
  15. - FINAL  
  16. ### NotifyCustomer  
  17. 在庫の不足により購入が失敗したことを顧客に通知  
  18. ### CancelOrder  
  19. 購入処理をキャンセルする  

CMLでアクティビティ・モデルを記述する文法を以下で説明します。

ACTIVITY

最初のセクションのタイトルがACTIVITYとなっています。これはこのセクションの内容がアクティビティ・モデルということを示しています。

  1. # ACTIVITY  

アクティビティ・モデル名

ACTIVITYセクション直下のサブセクションではアクティビティ名を指定します。

ここではSalesOrderを指定しているので、アクティビティ・モデルSalesOrderの定義ということになります。

  1. ## SalesOrder  

アクティビティ・ノード

サブサブセクションは以下の項目が並んでいます。

  • CreateSalesOrder
  • DECISION: StockAvailable
  • ProcessOrder
  • ShipOrder
  • NotifyCustomer
  • CancelOrder

これらはアクティビティ・ノードを構成するアクティビティ・ノードです。アクティビティ・ノードはそれぞれ実行する処理が定義されています。処理内容は日本語で記述しています。

処理が終わると接続された次のアクティビティ・ノードに制御が移ります。

アクティビティ・ノードの制御の移動は後述するTRANSITIONサブサブサブセクションに記述します。このTRANSITIONサブサブセクションが定義されていない場合は、すぐ下のアクティビティ・ノードに遷移します。

DECISION

サブサブセクション「DECISION: StockAvailable」は「DECISION: 」で始まるのでデシジョン・ノードとなります。ノード名はStockAvailableです。

デシジョンノードでは条件ごとの分岐を記述します。

条件の内容として日本語で「在庫の確認を行う」と定義しています。この条件に対して以下の定義が行われています。

  1. - Yes :: Process order  
  2. - No :: Notify customer  

条件がYesの場合はProcessOrderノードに、Noの場合はNotifyCustomerノードに遷移します。

TRANSITION

各ノードのデフォルトの定義は、処理終了後直下のノードに遷移しますが、他のノードに遷移させる場合はサブサブサブセクション「TRANSITION」で遷移先を指定します。

アクティビティ・ノードShipOrderでは以下の定義をしているので、処理終了後FINALに遷移します。FINALはアクティビティの終了を示すので、ShipOrder終了後にアクテビティ全体が終了します。

アクティビティ図を生成

このCMLモデルからCozyによってアクティビティ図を生成したものが以下の図です。

モデル記述はCMLにしておき、必要に応じて参照用のアクティビティ図を生成する開発スタイルになります。

まとめ

今回はビジネス・モデルにおけるビジネス・フローについて説明しました。

今回でビジネス・モデルは終了です。次回から要求モデルに入っていきます。

2025年1月31日金曜日

Cozyモデル駆動開発/ビジネス情報モデル

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

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

  • ビジネス・ビジョン
  • ビジネス・ゴール
  • ビジネス・コンテキスト図
  • ビジネス・プロセス
  • ビジネス・ユースケース

今回はこれらのモデルの作成過程で同時に作成される情報モデルについて考えます。

ビジネス・オブジェクト

ビジネス・コンテキスト

ビジネス・コンテキストの作成時に以下の用語集を作成しました。

用語種別意味
Pieris BooksBSPieris Booksビジネス全体
ECBSPieris BooksのEC機能
店舗BSPieris Booksの実店舗
在庫管理BS実店舗での在庫管理
EC利用者BAECサイトの利用者
店舗利用者BA店舗の利用者
外部ECサービスBA見本品を購入する際に使用する外部のECサービス
決済サービスBAECまたは店舗での商品販売に使用する決済サービス
配送サービスBAECでの商品販売を依頼する配送サービス
店舗運営者BAビジネス上の店舗運営を行う
販売管理者BA店舗での商品管理などを行う
システム管理者BAPieris BooksのITシステムの管理を行う

ビジネス・プロセス

ビジネス・ユースケースを記述するモデルとしてBusiness.mdを作成しました。

ここでは以下の用語が定義されています。ビジネス・コンテキストで抽出した用語をベースにビジネス・プロセスを定義しながら作成したものです。一部用語はより適切と思われるものに改良しています。

  • 店舗販売プロセス
  • EC販売プロセス
  • 在庫管理プロセス
  • ECサイト
  • 店舗顧客
  • EC顧客
  • 外部ECサービス
  • 決済サービス
  • 配送サービス
  • 店舗販売者
  • 店舗運営者
  • 販売管理者
  • システム管理者

ビジネス・ユースケース

ビジネス・ユースケースを記述するモデルとしてBusinessUseCase.mdを作成しました。

ビジネス・ユースケースの作成時に以下のビジネス・アクターを使用しました。

  • 店舗顧客
  • 店舗販売者
  • 店舗販売システム

またユースケースの脚本に登場するモノは以下になります。

  • 商品
  • 商品情報
  • 在庫数

情報モデル

Business.mdとBusinessUseCase.meから情報モデルに対応するモデル群を抽出してまとめると以下になります。この抽出作業はCozyで行うことができます。

  1. # Overview  
  2. - cope :: business  
  3. # Actor  
  4. ## 店舗顧客  
  5. 店舗の利用者。  
  6. 店舗に在庫がある場合は直接購入することができる。  
  7. 店舗に在庫がない場合は、見本品を参考に購入し配送で商品を受け取ることができる。  
  8. ## EC顧客  
  9. ECサイトの利用者。  
  10. ## 外部ECサービス  
  11. 見本品を購入する際に使用する外部のECサービス。  
  12. ## 決済サービス  
  13. ECまたは店舗での商品販売に使用する決済サービス。  
  14. ## 配送サービス  
  15. ECでの商品販売を依頼する配送サービス。  
  16. ## 店舗販売者  
  17. 店舗で商品の販売を行う。  
  18. 店舗顧客に対して接客を行い、購入時はレジから購入登録を行う。  
  19. ## 店舗運営者  
  20. ビジネス上の店舗運営を行う。  
  21. ダッシュボードから各種のメトリクスを確認し、必要に応じてビジネス上の施策を行う。  
  22. ## 販売管理者  
  23. 店舗での商品管理などを行う。  
  24. ## システム管理者  
  25. Pieris BooksのITシステムの管理を行う。  
  26. # Entity  
  27. ## 商品  
  28. Pieris Booksが販売する商品。  
  29. ## 在庫  
  30. 商品の在庫。  
  31. # Value  
  32. ## 商品情報  
  33. 商品の内容を確認するために参照する情報。  

この情報モデルはドメイン・モデルの雛形となります。ただ、ITシステムの文脈で構築するドメイン・モデルとは連続性があるものの完全にマッチするわけではないので、この段階では参考情報という扱いになります。

まとめ

今回はビジネス・モデルにおける情報モデルについて説明しました。

次回はビジネス・フローについて取り上げる予定です。