下文中是關於業務用例和用例之間的對應關係的對話，一般來說在一些較大的業務系統或者業務邏輯較為複雜的系統開發中才需要進行單獨的業務建模過程，而對於大多數業務系統是不需要單獨進行這樣的開發階段的。
在每次的全程建模的培訓中，青潤都會提出這個過程將業務建模過程進行詳細的分解，但是在《軟體工程之全程建模實現》一書中對業務建模並沒有進行深入的闡述。
下文中的系統用例在青潤的定義中一般就稱之為用例，而系統用例這個名詞用於非業務性相關用例的命名，比如使用者管理，碼表分類定義 / 管理之類的非使用者原有業務需求產生的用例上，或者稱之為支撐業務用例而不得不構建的用例被稱之為系統用例。所以在這裡單獨進行明確，以便於大家的區分。
業務用例和用例的對應關係一般是 1 對 1 和 1 對多最為普遍，但是也可能出現多對 1 的形式，甚至一些使用者業務間交叉過多的業務實現中還可能出現多對 1 的形式。比如下面這個例子就是 2003 年底在北航給軟工碩士講課期間產生的一張圖，此圖的模型也在《軟體工程之全程建模實現》一書的光碟中可以找到：
下面是相關的對話內容，有助於對以上內容的進一步理解。
緣，妙不可言 21:32:59
uml 中，我本來認為業務用例和系統用例的關係是一對多，因為系統用例是從業務用例場景中推導出來的。可是後來被**的面試官反駁了。我反覆思考後現在認為： 業務用例和系統用例只是有用例粒度上的區別，即不同抽象層次上的，並不存在所謂的 1 對多關係。而且乙個業務用例物件可以有不同的場景例項，所以某個業務用例場景只是該業務用例物件的某個方面而已，自然從該業務用例場景中推導出的系統用例和該業務用例不會是 1 對多關係。
我覺得我的理解應該還有不對的地方，請本群的 uml 大牛 -- 青潤，給予指導，其他群友也一起參與討論下吧
青潤 21:46:02
呵呵，這兩者的關係，我那本書裡做了詳細的闡述。
基本上可以認為是粒度的問題，但是，也可能出現一些業務用例在確定了其業務範疇之後認為可以另外乙個或者多個業務用例合併成為乙個系統用例，所以，兩者不是簡單的 1vn 的關係，應該是 n v m 的關係更合適。
緣，妙不可言 21:48:30
多個業務用例合併成為乙個系統用例 ？？
青潤 21:48:50
對，你肯定是沒有遇到過，實際系統中會有這種特殊情況出現的，呵呵。
緣，妙不可言 21:49:04
應該是不同業務用例場景中推導出的系統用例合併為乙個吧
青潤 21:51:05
在一些特殊業務系統的開發中，有可能出現這種情況，比如，抽取出來的公用子流部分，完全可能進行子流的合併開發，實現系統的快速搭建和原型展示，這時候和用例業務場景沒有關係，呵呵，當然也有特殊的業務系統在實際開發中會出現合併的問題，比如你前期業務用例劃分過細，或者使用者方曾經進行過一些業務流程的制度性分割造成的結果，你想想吧，肯定能想明白。
緣，妙不可言 21:52:39
太深了，大象那書裡是說 物件必須從多個場景中分析出來，每個場景只是該物件對映到該處的乙個方面，所有名詞，包括用例也是物件，他的分析方法和概念類物件一樣
青潤 21:53:47
呵呵，這麼說沒有大的錯誤，只是考慮的業務環境不夠完整，經歷的業務系統多了，自然會遇到各種各樣稀奇古怪的業務狀況，自然就會有這樣的情況出現。
全程建模 業務用例與用例的對應關係解析
下文中是關於業務用例和用例之間的對應關係的對話，一般來說在一些較大的業務系統或者業務邏輯較為複雜的系統開發中才需要進行單獨的業務建模過程，而對於大多數業務系統是不需要單獨進行這樣的開發階段的。在每次的全程建模的培訓中，青潤都會提出這個過程將業務建模過程進行詳細的分解，但是在 軟體工程之全程建模實現 ...
用例與業務建模
盡可能識別外部系統，並用色彩標註新的外部系統和服務 我使用的是馬蜂窩預定酒店的流程 c.對比兩個時代 不同地區產品的用例圖，總結在專案早期，發現創新的思路與方法 兩個用例圖基本的功能差別不大，在搜尋酒店 選擇酒店這方面都大同小異，不過新時代的酒店支付功能有所變化。創新的思路與方法在於，要發現早期專案...
業務用例與系統用例的區別
1 業務用例就是要完成的業務，系統用例是系統要做的事情，兩者的域不同。2 業務建模主要描述了該專案涉及的所有業務，需求模型主要是描述為了滿足業務需求系統要做什麼，因此，需求模型與業務模型相比，它描述的只是業務模型的乙個子集。3 比方說我們設計乙個自動提款機系統，它可以滿足使用者的取款 改密 查詢等需...