業務主角
分辨業務角色和業務主角要看環境而定。當你開發企業的ERP系統時，部門的員工都屬于業務角色，而你開發一個部門級的應用時，其他部門的員工可能屬于業務主角。
業務實體，在一些文章中被稱為商業對象（Business Object）。不論怎么叫，所表示的意義都是一樣的。例如在銀行信貸這個例子中，我們就涉及到很多業務實體：契約、單筆貸款、客戶等。所以業務實體就是企業中那些很基本的要素。如果覺得銀行押匯的例子不好理解�？梢韵胂蟛蛷d中的菜單、漢堡等都是業務實體。在RUP中，業務實體被定義為：
A business entity represents a "thing" handled or used by business workers.
業務實體代表業務角色處理或使用的"事物"。
業務實體
在很早以前，我們討論過需求易變性。相對于需求的不斷變化，可是業務實體對象在一段相當長的時間內都存在。航空公司今天打折，明天又不打，還有明折、暗折�？墒菣C票從來沒見有什么大的變化，從來也只有那幾樣屬性：價格、航班、出發地、目的地。所以業務實體是比較穩定的。這對于我們是有很大的意義的：
"一個業務實體經常代表某個對多個業務用例或用例實例有價值的事物，因此，業務實體對象的生存期相當長。一般而言，一個好的業務實體不包含關于其使用主體和使用方法的信息。"（RUP）
由業務實體組成的業務用例會穩定很多。在以前，開發方式采用模塊為基礎的方法，需求變化的時候，只好改寫模塊。如果采用穩定的業務實體來實現業務用例的話，業務用例的改變只需要對業務實體進行重新的組合。當然，這里還需要很多的技術來實現，并沒有那么簡單。要知道，四個現代化可不是一天就能夠實現的。 還有一個使用業務實體的重要原因：業務實體的特性決定它具有天生的重用性。就像麥當勞的銷售系統中有漢堡實體，生產系統中也有，供應鏈系統中也有。天哪，這世界真是美好！
使用業務實體一個很大的困惑是應該把它做為類還是屬性。這個取決于業務環境對這個實體的重視程度。一個客戶在銀行信貸部門是一個很重要的類，而在押匯部門就只是信用證實例的一個屬性。這個問題非常的重要。設計時的失誤可能會導致今后系統改進的極大痛苦。例如本該設計為類的業務實體設計成了屬性，在今后增加屬性的時候不得不面對著數據庫的調整和系統的修改。 6. 建立業務用例模型
業務用例模型（business use-case model），在RUP中定義為：
The business use-case model is a model of the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization.
業務用例模型是說明業務預期功能的模型。作為一個核心輸入模型，業務用例模型用于確定組織的各個角色和可交付工件。
從業務用例模型的定義可以看出，它是企業最核心，最概括的業務說明。它主要是由業務用例和業務主角構成的，其主要目的是說明客戶和合作伙伴是如何開展業務的，它描述業務的主要方式是通過業務用例的方式。下圖為RUP中業務用例模型的圖示。
業務用例模型
從圖中我們也可以很清楚的看出業務用例模型包括一組的業務用例。這是因為企業中的業務通常都會由多個的業務用例的多個實例構成。這些業務用例形成的企業工作流程可能會由業務主角所引發，也可能會由業務規則②所引發。
②業務規則（Business Rules）：業務規則是必須遵守的政策或條件的聲明。（Business Rules are declarations of policy or conditions that must be satisfied.）
業務用例模型實際上就是企業經營業務的一種描述，為了建立完整、準確的企業用例模型，應該將注意力專注于企業的業務做了些什么事情，而不應該集中于如何做。雖然這樣可能會產生一些業務用例相沖突，相重復的情況，但是RUP的思想在于迭代，這項工作完全可以在接下去的迭代周期內完善。
業務用例模型是和企業業務最貼近的計算機模型。它的很多思想和企業日常經營如出一轍。在企業的日�；顒又�，業務的種類可能有很多種。在一些講述ERP思想的文章中，通常會強調三類：
一種是和主營業務密切相關的工作，例如銀行的營業部、信貸部、押匯部等。這種工作通過人的勞動，將一種資源轉變為另一種資源，產生價值。
一種是管理型的工作，例如公司的管理層，財務部門等。這種工作本身并不產生價值，但是它通過指導、管理、檢測第一種工作，加大第一種工作的產出價值。
還有一種稱為支持工作，例如系統管理、安全等。它并不是很重要，具有支持其他工作的性質。
業務模型同樣可以使用這種分類。通過這種分類，可以更好的把握核心業務用例，為下一步的工作打好基礎。
有很多業務用例是由業務主角觸發的，RUP中也把和業務主角有關聯關系的業務用例稱為核心業務用例（Core Business Use Case）。這強調了構建業務模型的目的是為了提供以用戶為中心的服務。這也是我們建立業務用例的時候應該注意的。
當然，有時候業務用例的觸發是為了產生用戶需要的結果。例如企業的市場調查行為就不是由業務主角觸發，而是企業積累了大量用戶請求的結果。而對于管理型、支持型的，不直接和業務主角的客戶類發生聯系，但是也有其特定的業務主角，如管理型的業務用例需要和董事會為發生聯系，支持型的業務用例可能和供應商發生聯系。
在建立了基本的業務用例模型之后，對此模型進行精化是非常有必要的，這時候，在上一章中我們介紹的用例的擴展關系和使用關系就有了用武之地。除了這兩種關系，還有一種新的關系。 7. 在業務建模中使用關系
泛化關系（Generalization）：根據我的理解，可以把它看作我們比較熟悉的繼承關系很相似的一種關系。Generalization一詞含有一般化、概括的意思。它是一個相對抽象的詞。雖然它和繼承關系非常相似，但是它們在使用環境和產生目的方面都有相異之處。下圖描述了四個業務實體之間的泛化關系：
當你去麥當勞的時候（不要誤會，我并不是很經常去的），會選擇麥香雞漢堡、麥香魚漢堡或是吉士漢堡。但是分別對這三種漢堡建立業務實體就非常沒有意義。所以可以將它們概括為漢堡這個業務實體。同樣的道理，企業的業務流程中也可以概括出一些共有的屬性和行為。為了避免多次說明同一個工作流程，您可以將共有的行為放在一個單獨的業務用例中。稱為父用例，執行子用例的用例實例將遵循父用例的事件流，同時插入附加行為或修改在子用例事件流中定義的行為。
8. 方法的選擇
以上的原理我采用了UP的方法。但是除了UP方法，還有XP、FDD等方法。所以在做業務建模的時候，也要根據不同的方法選擇適當的工件。例如素材和功能。方法的好壞并不是我們這片文章討論的重點，我會在另一篇文章中討論方法。再一次需要強調的是，上面討論的RUP的工件只是為了學習，所以才定義了比較復雜的工件，區分了它們之間的區別。但是在實際中，并不需要這么多的工件，那只會使你的項目涉眾和開發人員糊涂。這些工件的區別只要在你心中就可以了。至于具體的實踐，我們會在下一篇文章中討論。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
