2025年3月31日月曜日

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

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

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

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

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

要求モデル

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

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

スコープ・モデル

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

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

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

ビジョン宣言

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

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

システム・コンテキスト

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

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

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

機能要求モデル

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

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

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

ユースケース・モデル

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

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

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

フィーチャ・モデル

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

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

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

非機能要求モデル

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

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

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

品質属性

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

コスト

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

技術上の制約

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

まとめ

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

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

投稿者 時刻: 0 件のコメント:
ラベル: ,

2025年2月28日金曜日

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

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

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

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

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

ビジネス・フロー

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

view plainprint?
  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となっています。これはこのセクションの内容がアクティビティ・モデルということを示しています。

view plainprint?
  1. # ACTIVITY  

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

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

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

view plainprint?
  1. ## SalesOrder  

アクティビティ・ノード

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

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

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

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

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

DECISION

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

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

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

view plainprint?
  1. - Yes :: Process order  
  2. - No :: Notify customer  

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

TRANSITION

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

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

アクティビティ図を生成

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

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

まとめ

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

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

投稿者 時刻: 0 件のコメント:
ラベル: ,

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で行うことができます。

view plainprint?
  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システムの文脈で構築するドメイン・モデルとは連続性があるものの完全にマッチするわけではないので、この段階では参考情報という扱いになります。

まとめ

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

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

投稿者 時刻: 0 件のコメント:
ラベル: ,
登録: 投稿 (Atom)