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にしておき、必要に応じて参照用のアクティビティ図を生成する開発スタイルになります。
まとめ
今回はビジネス・モデルにおけるビジネス・フローについて説明しました。
今回でビジネス・モデルは終了です。次回から要求モデルに入っていきます。
投稿
