敏捷面向對象分析與設計思想

萬星

摘要

本文主要討論以面向對象的方法來構建企業信息系統，對比了面向對象建模與面向過程和數據建模的區別，和使用面向對象建模的動機。本文對于面向對象分析與設計中蘊含的思想進行了一些擴展，討論了面向對象技術與REST，Workflow，面向服務之間的關系，以及面向對象技術與這些應用的關系。

1       引言

本文建立在企業級信息系統開發的前提下，不討論其他類型的計算機系統，這一點要首先聲明，因為不同訴求不同領域的計算機工作者總是會對同一問題得到不同的見解，并且爭論一些毫不相干的話題。

企業信息系統具有以下幾個特點：

1.         需要處理大量相互關聯的數據。這一特點使得信息系統總是與數據庫關聯在一起，并促成了早期的以數據建模方式開始構建信息系統。數據庫專家致力于如何設計數據模型，以使訪問高效，不易出錯等。這時，管理數據是主要需要解決的問題。這一情況，在現在仍然需要重視。另一方面，這些數據之間具有廣泛的聯系，復雜的數據模型就像一張大網一樣，各個數據彼此參照，因此當添加、改變或移除一個節點時都相當復雜。

2.         沒有“邏輯”的業務邏輯。業務常常缺乏一個具有嚴格數學意義的邏輯，往往會因為與某個客戶的談判，臨時將催款日期推后幾天，而改變了過去的處理邏輯。在企業應用中，正是成千上萬的“一次性業務邏輯”導致了開發的難度[Fowler02]。即使是不經常改變的業務，也可能會存在大量的針對不同情況的不同的處理邏輯。企業應用如何能正確將變元與恒元分離開，使得變元獨立于恒元進行變化，是構建穩定的信息系統的主要思想。另外，業務流程在某些系統中也是經常會改變的，但是其改變的只是操作序列，而推動業務流轉的元模型并未改變。因此，抽象出了工作流引擎。

3.         復雜的用戶界面。企業信息系統往往會帶有一個復雜的用戶界面，包含大量的控件，對用戶激發的系統事件進行響應調用系統操作。將業務邏輯和用戶界面邏輯分開是件非常困難的事情，比如，對于某些數據的篩選，雖然看似是用戶界面的一個簡單的選擇，實際上卻蘊含著復雜的業務邏輯。另外，需要支持多種客戶端，也是用戶界面處理的難題。

4.         大量的并發訪問。企業信息系統往往是一個多用戶并發訪問的系統，因此必須做好并發處理，否則就會出現線程爭搶，數據庫死鎖，事務也會因為多種不一致性而失敗。

5.         存在大量的異構的遺留系統。有的時候不得不面對拯救信息孤島，整合遺留系統的問題，尤其是在當今已經出現了大量的企業信息系統的時候。因此SOA，REST等技術的出現，成為徹底打破平臺束縛，進行異構系統整合的首選。

    雖然同屬于軟件開發，但是信息系統開發與其它軟件開發還是有很大區別的，因此，對于該領域的不同方法，面對不同的情況，發揮了不同的作用。

面向過程的面對業務處理序列建模，而非業務中固定的實體及其固有行為。而這些業務處理序列會時常發生變化，也會因為一個不可思議的條件而產生細微的差異，導致大量重復的處理代碼或者需要不斷的需要修改已經穩定發布的代碼甚至是模塊。比如訂單是ERP系統中常見的實體，而處理訂單的業務邏輯則各不相同，面向過程沒有對穩定的東西建模而對不穩定的東西建模，因此在處理易變的業務邏輯是有問題。數據建模，是對于業務系統中的業務實體進行建模，然而這些數據表缺乏表達業務含義的能力，但是在應用早期，對于業務處理的需求也比較少，這樣做是什么問題，就是在今天，如果業務邏輯簡單或者很固定，則采用這種方法也是沒有問題的。然而，隨著業務的復雜性、多樣性和易變性，特別是對于同一業務會存在多種不同的處理情況，僅依靠數據建模就不足以完成要求了。

三層架構[TK78，Gartner95]是一個清晰的分層架構，也是眾多分層架構中最著名的一個。表現層，業務層和持久化層，形成一個單向依賴層模式，也分離了不同的系統處理關注點。雖然不同的理論提出了不同的分層架構，但是我們都可以通過對于三層架構的擴展和細分，去發現其他層次的意義。

新的技術帶來了新的解決問題的方案，然而已有的經驗如何服務于這些新的技術，去解決那些由來已久的問題，或者以傳統的方式去解決新技術自身的問題，同樣是值得思考的。

1.1    對世界建模的三大方法論

在對于世界建模的方法論中，主要有三種方法占領了高地，分別是結構化方法（面向過程[Yourdon79]），面向對象范型，和實體關系模型（面向數據范型）。結構化方法強調過程序列，面向對象強調對象交互，實體關系模型強調實體與其間的關系，其不關注業務處理，即只是靜態建模。

1.2    信息系統與三大范型

在開發企業級信息系統過程中，我們都要對于業務中的概念進行建模，無外乎就是業務實體（領域模型），業務操作（業務處理），單據，被統計的數據集，業務實體之間有某種關系（一對多、多對一等關聯關系，特化/泛化的繼承關系，生命周期同步或異步的包含代表的組合/聚合關系，一方對另一方調用或其他行為的依賴關系），業務操作的序列這些概念，而實體或者對象或者結構體都包含字段/屬性/成員變量。而三大方法論只不過是從不同角度觀察和描述世界，因為軟件不能也不必對于世界進行完整的建模，因此選擇有利于項目軟件活動的建模方法是必要的，每種方法都各有所長，在過去四十年間，使用各種方法都創建了大量成功的系統和導致了很多失敗的項目。

簡單而言，信息系統主要為了解決業務問題，業務通過一個個促使狀態發生變化的操作得以開展，使用結構化方法主要是通過外部力量改變數據狀態，而面向對象方法是通過對象自身的行為改變其內部狀態（所謂封裝的概念）。

在這里我將簡單分析一下三大方法是如何對上述業務概念進行建模的。在結構化方法中，過程是一等公民，我們首先要知道做事情的一連串過程，經典的分析工具是業務流程圖和數據流程圖，此方法更加強調數據的結構，是單數還是集合。一個過程就是一個改變實體狀態的操作序列。

在面向對象中，對象是一等公民，我們主要關注的是對象如何通過向彼此發送消息，支配行為，改變狀態。很多面向對象的專著和論文都強調了面向對象建模首先是對行為建模，其次是對數據結構建模，比如責任驅動設計（RDD）[WW89]，契約式編程等。

而在實體關系模型中，首先要找到實體，然后確定實體和實體之間的關系。很多開發者都發現E-R圖和領域模型圖（通常用UML類圖表示）很相似，甚至分不清數據模型和領域模型，這是很正常的，因為它們是對同一個世界進行建模。而這些實體/對象都會包括屬性，所以某些模型看上去是相似的了，但是這種相似不等于完全相同，所以才會有諸如對象關系阻抗不匹配的困擾。實體關系建模反映了在完成某一業務過程時各個實體以及它們之間的關系的狀態快照（SnapShot）或者選擇狀態快照（限定捕捉某些實體的某些字段以及某種特定組合）。這些快照有可能就是業務過程中產生的單證或者統計數據表中的統計單元。狀態（State）這個詞在面向對象技術的詞匯表中代表的意思是對象屬性在某一時刻的值集合。從面向對象的角度來看，開發者需要將這些在刷新（flush）內存之后依然需要保存的狀態持久化到數據庫中（或者平面文件（flat file）中，諸如文本文件、XML文件之類的），所以在面向對象范型中，數據庫只是持久化機制的一種，并非系統的核心，某些順時狀態只需要保存在內存中即可。而以數據庫為中心開發的系統，會傾向于將任何狀態都持久化到數據庫中，比如購物車的不同實現方式，使用面向對象設計可能會傾向于使用Hashmap，而以數據庫為中心則傾向于將其映射到數據庫中。

2       面向對象分析與設計

面向對象分析與設計是非常流行的方法，除了流行的設計模式、設計原則和最佳實踐之外，其本身的含義則缺乏鮮明的注釋，本節以ERP系統為例，試圖將其與其他兩種方法論視圖做一下對比。

以另外兩種方式對于領域建模的思維來看ERP系統，看到的就是一個個單據的填寫與流轉（數據流程圖），數據庫中記錄的變化，統計報表。那么業務呢？業務就只是填寫單據和生成報表嗎？系統所做的工作就只是幫助用戶記錄填寫的數據，或者僅僅就是支持CRUD操作嗎？

如果以面向對象視角來分析，看到的是什么呢？在一個對象系統中，對象扮演業務領域中的角色，彼此發送消息，完成屬于自己職責的任務。

2.1    信息系統中一些常見概念

在這一節中，主要探討在企業信息系統中常見的一些概念，在面向對象系統視角下的含義。

[單證]

單證處理是信息系統的主要功能，某些信息系統對于用戶而言就是處理單證，然而就本質而言，某些單證是處理業務的附屬品，它們本身沒有行為，或者是為了作為執行某種操作的依據（在進行某項業務時所開理的手續，如出庫單，合同；進行某項業務時對照信息，如理貨單），或者是為了長久記錄操作狀態以備事后查證（收費憑證）或統計分析，簡單而言，他們是為業務而存在的，并非業務本身。這些單據的特點是，其數據都來自于其他領域對象或者純虛構（為了系統得以運轉而虛構出來的對象，而非領域中的對象）[Larman04]，因此它們不是真正的對象。而某些單據，則是領域中的對象，比如計劃，其不是其他對象狀態快照的簡單集合，而是具有行為的對象，它代表的抽象意義是對于未來的安排與決策。

[UI]

而用戶界面是什么？在面向對象分析中，它只不過是用戶操縱對象社區的接口，和展示對象狀態的接口（或者說是窗口）。另外一個叫做表現層的概念，則又將頁面邏輯和應用控制邏輯進行分離。為了隱藏客戶端對于對象社區的知曉，簡化類型轉換和異常處理，經常會使用VO（值對象）[Fowler2002]搜集領域對象中需要展示給用戶的狀態（如Struts中FormBean）。在分布式系統中，會使用其作為DTO（數據傳輸對象），如今XML是異構系統的一個選項。

使用Delphi，VB等微軟平臺的工具進行開發時，常會使用數據感知控件構造界面，這意味著不具有一個代表領域概念的對象層，而且傾向于采用對象關系建模，并且程序常常是過程化的。這在業務簡單穩定，大多數操作僅僅是簡單的CRUD操作時這樣做是合理且有效的，然而在大型復雜的信息系統構建過程中，這將不能應對系統的變化和擴展。

[數據庫]

在以對象為中心的信息系統中，會決定將哪些對象進行持久化。在這里存在一個問題，持久化的一定是一個定格到某個狀態的對象，還是對象中的數據到數據表的一個非面向對象映射。前者通過借助O/R映射工具可以實現一個優雅的對象持久化層次，而后者會使用一個不完整的對象模型。使用成熟的O/R映射工具可以避免很多對象模型到實體關系模型映射的困難。不需要使用實體關系模型再對領域重新建模，而可以采用一個有規律的轉化（比如引用與外鍵的關系）。

2.2    信息系統構建中的面向對象分析

面向對象系統的穩定性保證在于其對于領域的準確抽象，比如飯店的核心業務就是點菜，上菜，結帳。隨著飯店規模的擴張，各種技術的發展，金融規則的變更，這三個核心的業務是不會變的，變的是如何點菜（服務員記在腦袋里，記在點菜單上，記在手持PDA上，還是顧客自己在點菜單上勾畫，在電子菜單上點擊選擇，這些都只是點菜方式的不同），需要產生哪些憑證（是否打印出來供顧客確認，是否需要上菜時進行核對，是否需要與后廚核對，是否需要與財務人員核對，不同的答案組合會得到不同的票據，其上的內容也會有所不同），如何上菜（顧客自取還是服務員送達），如何結帳（飯前結帳還是飯后結帳，現金支付，還是未來隨著飯店不斷發展壯大之后可以采用會員卡結帳，積分結帳，信用卡結帳等多種方式）。面向對象分析優劣體現為以下幾個方面：

1、是否對于領域有個相對合理的抽象。比如前例，合理的抽象絕對不會是[填寫點菜單]。這需要領域專家的參與，因為只有他們最清楚該領域的核心是什么。領域驅動設計，建立合理的領域對象被認為是解決企業應用核心復雜性之道。[Evans03，Fowler02]

2、是否有效分離表現層，業務層和持久層。表現層作為對外提供服務的接口，指明了外部如何使用該系統的契約，這樣業務層可以作為Web Service暴露給外部，可以是REST風格的服務接口，抑或作為另一個系統的數據源。而數據源層作為業務層訪問外部服務的接口，指明了該系統如何使用其它服務的契約，這些服務就可能是數據庫服務，消息服務，甚至是另一個可以提供數據的系統。這也恰恰提醒我們，表現層接口和數據源層（我還是覺得叫數據訪問層比較好）接口并不直接相關，因此在設計時不要將這兩個接口進行簡單的設計映射，表現層接口的契約與數據源層接口的契約簡單對應會造成系統不穩定，數據訪問層的變動將導致表現層接口的變動。另外，尤其要記住，它們是為不同目的設計的！

3、是否有效分離應用邏輯與領域邏輯。在大型企業信息系統中，會分離出單獨的應用邏輯層，以確保領域邏輯的穩定和可復用性。領域邏輯和應用邏輯都屬于業務邏輯。應用邏輯有時被稱為工作流邏輯[Fowler02]。這一分離對于大型信息系統而言是非常重要的，這使得領域模型獨立于不斷變化的應用需求。應用需求的例子包括點菜服務（Order Dishes Service），其中會用到點菜（Order Dishes，只包含創建并將點菜單與支付方式，點菜單項與Dish對象進行關聯或者解除關聯等操作），點菜單（Dishes Order），支付方式（Payment Method），菜單（Menu，其中包含Dish對象）等領域對象和其中的領域邏輯（比如點菜單中的添加點菜項目邏輯中，可能會包含合并相同菜項，數量加1，并更新消費總額的領域邏輯），同時還可能包括向其他系統發送消息等邏輯，如庫存系統，財務系統。這些領域邏輯會在不同的應用需求之下使用，比如老板管理菜單時，同樣會用到菜單對象。而是否通知更新其他系統，或者其它應用需求，與領域本質并無直接關系，并且會不斷變更（比如進行精細化庫存管理之前并不需要將點菜與庫存直接關聯），因此將其分離是很重要的。需要注意的是，應用邏輯與應用控制層并非一物，應用控制層位于表現層，作用在于接受請求，調用領域邏輯或者應用邏輯，其核心在于實現控制邏輯，在小型信息系統中不存在單獨的應用邏輯層，其中對于領域邏輯的調配和非領域邏輯的實現也在這一層中完成。在分層結構中，應用邏輯會被實現為服務層中的對象，而在服務層中，有時則只使用業務門面（Facade）模式，門面只是對于領域對象一個薄層，業務邏輯完全存在于領域對象之中[Fowler02]。然而無論采用何種分層架構或在分層架構中的哪一層次實現應用邏輯和領域邏輯，對于應用邏輯與領域邏輯的分離都是重要的，這比在系統中僅僅分離出業務邏輯更進了一步。

總之，構建一個真正代表領域核心的、合理抽象、職責明晰的領域模型是保證系統穩定發展的前提。

2.3    業務建模方法與用例使用

業務建模（在面向對象分析中指建立領域模型）和用例使用分別是系統分析工具和需求搜集分析工具。建立領域模型和編寫用例文本是一個交替進行的過程。在編寫用例前，開發人員和領域專家會一起建立一些核心的抽象模型，然后編寫用例（主要用以發現新的需求[Cockburn01]）從而獲得啟發，擴展領域模型。

編寫用例要注意以下幾點：

1.         編寫用例是指編寫用例文本，而非繪制用例圖。用例圖的作用在于說明用例之間的關系，參與者與用例之間關系，以及參與者之間的關系。作為用例文本的高層展示具有一定作用，然而專注于用例關系會導致沒法專注于對于復雜靈活的業務需求的發現與捕捉。

2.         要區分業務用例和系統用例。業務用例主要描述業務流程，可以使用活動圖，業務流程圖等技術加以圖形化表示；系統用例主要描述系統功能，與傳統的功能列表相比，其強化了參與者與系統的交互，并且對于分解多條件事件和異常處理有巨大好處。好的系統用例有助于在業務建模時發現核心抽象，并且對于以用戶故事的形式組織迭代開發具有指導意義。系統用例可以使用交互圖進行圖形化表示。經典的結構化方法引入業務流程圖以描述業務流程，并使用DFD（數據流程圖）進行細化，實際上只是完成了業務用例的編寫，而對于系統用例則采用功能列表等技術，用例方法并非是面向對象的，但是它最廣泛的被用于面向對象范型之中。

3.         編寫用例應采用迭代方式。不少組織在瀑布模型中使用用例方法，一次編寫大量用例，并且每個用例都具有大量擴展流程，編寫者和審核者都可能因為大段的文字描述而產生疲勞感和抵觸情緒。因此，在每個迭代中只細化幾個場景（可能是主成功場景或擴展場景）即可，同時Larman也指出一次迭代的最小工作單元就是一個場景[Larman04]。對于用例的重構也是不可或缺的，隨著對于需求的深入了解，用例也需要不斷更新。比如需要將過于瑣碎的步驟提取成新的用例。

4.         要保持用例中執行步驟的抽象程度一致。用例場景中的每個步驟都有可能作為一個引用用例，用例可以被看作一個不斷展開下去的故事[Cockburn01]。因此某些明顯為了某一目標而出現的步驟被歸結為一個引用用例可以保持抽象一致。

5.         注意區分系統事件和系統操作。系統事件指的是外部輸入事件，參與者發起系統事件，如按下鼠標左鍵；系統操作是指處理系統事件的操作[Larman04]，比如當參與者按下鼠標左鍵時，系統提示用戶按下鼠標左鍵[Ambler02]。

6.         編寫用例參照一個好的格式和遵循一些優秀的實踐和模式大有裨益。Cockburn的《編寫有效用例》和另兩位作者的《有效用例模式》值得推薦，尤其是前者幾乎是必讀書籍，其毫不含糊的直擊每個用例初學者都會遇到的問題，如怎樣處理條件分支，怎樣編寫含有CRUD操作的用例等。

7.         要清楚用例并不是需求的全部。建立詞匯表（可作為數據詞典使用），UI需求說明書，業務規則等以記錄其他需求有助于編寫高效的用例[Larman04，Cockburn01]，另外，也有助于發現真正的業務邏輯，而不被UI操作，數據存儲策略等需求干擾。

建立領域對象將從用例文本（主要是系統用例）中獲得靈感。主要包括：

1.         發現對象，確定Role Stereotypes

2.         發現并分配職責

有大量優秀的著作討論如何發現對象和分配職責，其中由RDD（責任驅動設計）的創始人Wirfs-Brock編寫的《對象設計：角色，責任和協作》是對于該問題討論的專著，Larman的《UML和模式應用》中提出的GRASP原則（通用職責分配軟件模式），Ambler的《Object Primer》和McConnel的《代碼大全》中對于職責分配的討論。

此外對于構建企業信息系統的開發人員而言，Martin Fowler的《分析模式：可復用對象模型》和Eric Evans《領域驅動設計：企業應用核心復雜性解決之道》提供了業務領域現成的模式和分析問題的方法。

2.4    信息系統構建中的面向對象設計

區分需求分析、系統分析和系統設計是非常重要的，Ed Yourdon和Peter Coad的巨著《面向對象分析與設計》明確的劃分了這一點。然而Evans卻強調要建立一個統一的，貫穿需求分析、系統分析與設計過程的領域模型，以統一業務人員與開發人員的思想。而在分析模型（即領域模型）與設計模型之間建立低表示差異具有重要的意義[Larman04]。本文對于分析模型，領域模型，領域對象，設計模型等概念的區分參照[Larman04]。

與結構化方法相比，面向對象設計擁有大量的模式，雖然某些模式同樣適用于非面向對象設計，但是面向對象固有的能力可以更好的實踐這些模式。

基于建立好的抽象的領域模型進行面向對象設計，使用接口，委托，繼承，多態等技術手段分離變化，是面向對象范型進一步實現高穩定性、易擴展性、高可重用性信息系統的保證。

3       工作流與面向對象技術

3.1    業務流程，工作流與業務邏輯，業務規則

業務流程，工作流，業務邏輯，業務規則等概念既相似又不同。在不同規模的信息系統中，它們所起的作用不盡相同，而在不同的著作中，對于它們的定義也不同。

在大多數語境下，業務流程和工作流是同一概念，某些工作流規范亦稱為業務流程管理規范，而采用了UML活動圖來定義工作流。

業務邏輯表示完成業務的邏輯，那些涉眾比較廣，跨越了很多會話，生命周期很長的業務邏輯應該被歸于業務流程，而某些業務規則，亦是業務邏輯的一部分。當然更多的是介于兩者之間的業務邏輯（如前文討論領域邏輯）。

業務規則表示了處理某項業務的規則，可能是企業內部的規章制度，法律法規，稅務規則等。在企業信息系統中，經常會遇到針對不同類型的產品或客戶，需要基于不同的業務規則進行處理的情況。

對于項目所建立的信息系統而言，哪部分是最復雜的，最多變的，最能產生收益和造成風險的，是必須要分析清楚的。

工作流引擎在于將業務流程或工作流中的節點之間的流轉或調用提取出來，構建為通用的框架，并將流程定義分離出來，以提高業務流程管理的能力。

然而，并不是所有的信息系統的核心復雜性都來自于業務流程的多變和復雜，而恰恰是復雜多變的領域邏輯，而改變工作流程的情況并不常見，流程也并不復雜。

因此，工作流引擎或平臺依然無法解決領域邏輯的復雜性和易變性，而解決這些問題的強大工具依然是面向對象技術。

3.2    工作流與面向對象技術

工作流引擎可以主要負責業務流程的調度，其中的每個節點，調用一個業務門面中的方法。一個業務流程可以代表一個應用，比如點餐，可能會涉及到很多參與者，位于不同會話，這往往可能對應于一個用例。將應用邏輯封裝在較高的層中可以使得變更該層的實現更為容易——你可能用一個工作流引擎就做到這一點[Fowler02]。

把工作流引擎只是看作一個實現應用邏輯的框架是有好處的，而某些工作流引擎也是使用面向對象技術實現的。這與前文討論分離應用邏輯和領域邏輯是密切相關的。就前文的例子而言，可以將點菜，更新庫存，通知財務系統看作是三個節點，其中前者是人工節點，后兩者是自動節點，這樣，添加和修改應用邏輯，只需要修改流程定義即可，而不需要修改應用邏輯對象（此時整個工作流引擎代替了應用邏輯對象）。因此，事務管理和安全控制也應該在這一層次實現。

    這一層次的事務管理，往往屬于業務事務[Fowler02]，如果像上文一樣設計，處理起來會更加困難。

節點的實現方式有很多，某些規范定義了Web Service，而采取本地方法調用從效率和編寫測試維護難度等方面都是更好的選擇。這符合Fowler的分布式對象第一定律：不要分布你的對象[Fowler02]。

工作流平臺和引擎在公文報批，OA中能發揮最大的作用，而在ERP系統中，只是解決了次要問題，更復雜的問題依然需要借助面向對象技術，把它作為系統的一個應用層在大型復雜信息系統應用中會是一個好的選擇。

然而，如果業務流程不會經常變更，使用工作流引擎帶來的運行效率，事務處理等問題將使得投入得不償失。

判斷的依據可以是：繪制活動圖來表示業務流程，如果業務流程中包含很多節點，而每個節點所完成的功能只是簡單的CRUD操作，也不需要處理復雜多樣的業務規則，則將重點放在工作流引擎上具有重大價值；如果業務流程只包含幾個節點，而每個節點所要完成的處理非常復雜，包括復雜的校驗，計算，關聯關系，需要處理復雜多樣的業務規則，則應該考慮將重點放在對于業務規則的處理上面。

在我們的項目中，我們將屬于不同參與者完成的步驟作為工作流節點，而由同一個參與者完成的任務則放到應用邏輯對象中，然后以業務門面進行封裝，以減少離線事務處理[Fowler02]。由于同時采用遠程客戶端和Web客戶端，因此我們還會將工作流調用對象和業務門面暴露為遠程門面，通過使用Spring框架實現遠程調用的一致性。