[答疑]不同的方法對業務實體的定義多少有些差異
- 2019 年 10 月 6 日
- 筆記
OJT 2019-7-29 22:39
請教一下各位business entity的定義和用途
UMLChina潘加宇:
OJT
嗯，這是《軟件方法》的定義。不同的方法Business Entity的定義多少有些差異。例如
RUP：A business entity is a class that is passive; that is, it does not initiate interactions on its own. A business entity object may participate in many different business use-case realizations and usually outlives any single interaction. In business modeling, business entities represent objects that business workers access, inspect, manipulate, produce, and so on. Business entity objects provide the basis for sharing among business workers participating in different business use-case realizations.，
EA用戶手冊：Passive class accessed and manipulated by workers.
《軟件方法》的定義更具體，跟大家探討下對建模過程和產物的影響。
UMLChina潘加宇:
先說一下歷史。
UML標準里沒有"Business Worker"和"Business Entity"的概念，建模時表達為類的構造型。
這兩個概念來源於Ivar Jacobson的方法學。
在"The Object Advantage"（1995）和"Software Reuse"（1997）中，Ivar Jacobson將面向對象思想用於描述業務流程，把業務流程看作是一系列業務對象之間為了完成業務用例而進行的協作。
圖1 摘自Jacobson I., Ericsson M., Jacobson A., The Object Advantage: Business Process Reengineering With Object Technology. ACM Press (1994)
圖2 摘自Jacobson I., Griss M., Jonsson P., Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley (1997)
在RUP（Rational Unified Process）的文字里，正式出現"Business Worker"和"Business Entity"的說法，並作為類的構造型在Rational Rose等工具中使用。Rose里的圖標和RUP里的圖標有一定差距，反倒是EA里的圖標和RUP里的更相像。
圖3 摘自Kruchten P., The Rational Unified Process: An Introduction (2nd Edition). Addison Wesley (2000)
圖4 Rational Rose里的業務工人和業務實體
圖5 EA裏面的業務工人和業務實體
說完了歷史，接下來評價一下上面的定義。
關於業務工人，歧義不大，組織里的人肉零件。
關於業務實體，Ivar的書或者RUP里的知識是考慮不周的。主要問題是：把"業務實體"混淆為用面向對象方法構思軟件系統時的"實體類"，然後把它和業務工人並列，導致抽象級別不一致。像圖1中，把Loan Application和Account並列是不合適的。
組織的業務用例由組織內的各個系統協作實現。
例如，以某家企業為研究對象：
員工是業務工人。注意，這個員工是父母老師培育的人肉智能系統，和有沒有軟件系統、軟件系統是不是用面向對象的方法來構思沒有關係，時光倒流300年，這個人肉系統也存在。很多人在這裡犯糊塗，把外面的人肉系統等同於軟件系統用面向對象方法構思時（如果不用面向對象方法構思就什麼對象也沒有）的一個"員工"對象。
財務系統、釘釘系統甚至計算器可以算是業務實體。這些系統也是智能系統，和業務工人並列沒問題。
但是，把訂單（不管是一份紙質訂單還是軟件系統里的一個"訂單"對象）當成業務實體，然後和業務工人並列，是不合適的。員工和其他員工協作、員工和軟件系統協作可以，員工和一張紙協作、員工和某個軟件系統里的一個「員工」對象協作說不通。
實際上，員工就算和軟件系統的某個對象交互，那也是一個邊界類（例如「員工界面」）的對象。
有的人可能在這裡又會犯糊塗："訂單"有智能啊，"訂單"類的狀態機封裝了很多邏輯在裏面呢。如果是這樣，把前面文字再看一看。
《軟件方法》中，把業務實體定義為"非人智能系統"。如果需要在業務序列圖中表達A請求B做某事，傳遞的參數是一份訂單，那麼可以加一個類"訂單"，但不加業務實體構造型。
如果硬要把訂單稱為業務實體，也不是不可以，那需要找另一個詞來表達"非人智能系統"，不要把它和沒有智能的一張紙或者它內部的一個對象並列。
最後要說的是，要用發展的眼光看問題，不能搞"原教旨主義"。
某種思想或方法起源於某人，不意味着某人最初對該思想或方法的認識永遠是最正確的，也不意味着某人在以後的歲月中針對該思想或方法發表的各種觀點都是正確的。
我從2005年開始，使用Ivar Jacobson的方法學做業務建模，也指導很多團隊做了大量的業務建模工作，也寫了很多文章。之所以寫"從2005年開始"，是因為在這之前業務建模的業務流程部分我用的是活動圖。
通過大量的實踐不斷調整和加深對業務建模的認識，我認為許多先行者沒有考慮過或者考慮不周到的問題，我已經考慮過了。
《軟件方法》中的內容及其衍生物是先行者沒有過的積累，是目前認識最到位的高效從業務建模推導出系統需求的方法。有懷疑的讀者，可以去看書或者UMLChina網站、公眾號的內容。
這和當前的某些「創新」是不一樣的。有一些人，不學習不思考，在對前人積累不了解的情況下，憑着自己的一些朦朧認識，隨便拋出新概念忽悠他人，認真一看，那些認識連前人的尾巴都碰不到。這樣的人，國內國外都有。
