淺論陰陽太極與 UML 建模

淺論陰陽太極與 UML 建模

ZX-UDD 的另一個重要組成部分是利用統一建模語言 UML 對面向對象軟件的設計進行建模，這部分建模當然是敏捷的（agile），沒有人喜歡笨拙的建模。簡單的只需幾秒鐘可以迅速在人的大腦中完成，復雜的則可以畫在紙上、白板上，記錄在建模工具生成的電子文檔中。

軟件究竟是什么？有很多比喻可以形容。靜態的軟件就像一座虛擬的建筑（Architecture），而運動時的軟件有時就像一部開動的虛擬機器，或多條柔性的工廠流水線（進程與線程），有時又像一種虛擬的生物，可以肆意地復制和生長（比如軟件病毒）。過去有一種說法，認為：程序 = 算法 + 數據結構，如今看來這種舊結構化時代的觀點是不準確、不全面的，在新結構化時代我們至少可以得出這樣大致的公式：程序 = 算法 + 軟件結構 + 數據結構 + ？，在這里我們強調軟件結構不同于數據結構，軟件是操縱數據的程序，而除了算法和數據結構以外，軟件結構（包括架構和設計模式）的質量對軟件的質量同樣具有決定性的影響。

過去這 15 年無疑是面向對象（OO）軟件的天下，世界軟件開發早已進入了 OO 時代。人們知道，高質量的好軟件是設計出來的，而軟件的設計目前依然主要依賴于人們大腦的思考和判斷，人類大腦的思考過程恰是一個對現實世界以及虛擬世界建模的過程。而作為 OO 建模技術的事實上工業標準，統一建模語言（UML）正好為我們提供了一個運用 OO 思維進行軟件建模和設計的工具。

UML 1.4.2 成為正式國際標準 ISO/IEC 19501，是軟件設計史上的一個重要事件，UML 標準成熟之后的研發進展也比較順利，當前最新版本為 2.1。UML 有什么用？作為一種建?！罢Z言”，促進溝通是一項基本功能，然而很多人忽視了 UML 獨立于傳統具象編程語言、擅長表達抽象 OO 概念的一大特點。事實上，熟練掌握 UML 能夠幫助我們的大腦學會快速、敏捷地 運用 OO 方式進行思考。UML 標準及其相關技術不但是近 10 年來各工程領域 OO 軟件設計與建模的利器，還是當前表達軟件設計模式最形象和最有效的工具。

在我看來，學會運用 UML 思考，抽象地用 UML 表達軟件架構和設計方案，從而能透過現象看本質，是當今世界上任何一名軟件架構師乃至普通 OO 程序員都應該盡快掌握的基本功。所以，這幾年世界各地的大專院校紛紛把 OOAD/UML 列為一門軟件工程專業的必修課也在情理之中了。

建模（modeling）并不是軟件行業所特有的做法，建模幾乎是幾千年來人類所有工程行業所共有的一項最佳實踐。為什么我們要對軟件建模？因為軟件太復雜，難以理解和掌握，我們需要一種能夠簡單而深刻地反映軟件設計本質的方法和工具。如何建模？就像對待建筑模型、機械模型一樣，軟件也是一個多面體（虛擬的），我們也需要選擇視點、視角和視圖，對模型做投影、做切片。Philippe Kruchten 博士提出的著名的 4+1 視圖（邏輯視圖、實現視圖、構件視圖和進程視圖，再加上用例視圖）為我們利用 UML 對復雜軟件的結構和行為建模提供了很好的指導。

軟件設計和 UML 建模既然那么重要，有什么簡單易學、提綱攜領的好方法、好原則嗎？

我曾經編寫了一首建?？谠E，多次在講課、咨詢時與客戶、學員們分享交流，取得了很好的效果。這首太極建模詩（或叫“十六字 OO 建?？谠E”）受到了 Craig Larman（《UML和模式應用》）、Alistair Cockburn（《編寫有效用例》）、3 Amigos（《UML用戶指南》）等世界級專家們睿智大作的啟發，也凝結了我 10 多年來從事 OO 設計和編程的一點小小感悟。

太極建模詩 張恂 由外而內， 層次分明。 動靜結合， 逐步求精。

The Yin-Yang of Modeling Craig Larman (Contributor) Peek from Out to In, grasp High and Low, complement Dynamic with Static, and, unravel the Coarse-grained to the Fine-grained.

我發現“外與內，高與低，靜與動，粗與細”等基本二元辯證關系，不但適用于軟件用例需求的建模，也適用于軟件架構的 OOAD/UML 建模。當然，軟件設計中的二元關系還遠不止這些。充滿了二元辯證、平衡之道的現代軟件工程，竟然與兩千年前中國古典哲學《陰陽太極》中的黑、白對立統一相暗合，這真的是歷史的巧合，還是科學的必然？

由外而內

外與內，即軟件系統本身與其外部環境的關系，大概是軟件開發中最根本的一對關系。在軟件開發之初需求調研時，我們通常視整個軟件系統為一個黑盒子，我們劃地為界，從系統外部來觀察軟件提供給其各個用戶的功能，以及它與外部環境的各種動態關系（包括彼此之間的行為交互和信息數據的交換）。這種方法可以用 UML 用例圖表示如下：

以銀行證券帳戶管理系統（類似于“銀證通”）為例，圖中用例“打印帳戶報告!”的需求簡述是：

主用角：用戶
輔用角：外匯交易中心、證券交易所
范圍：證券賬戶管理系統
層次：用戶目標層
后置條件：
    系統打印客戶帳號下已購買的所有幣種的證券清單，包括每支證券的單價、份數、余額以及該客戶賬戶下的資產總額（轉換成用戶指定的幣種，缺省情況下為美元）。  系統打印客戶帳號下已購買的所有幣種的證券清單，包括每支證券的單價、份數、余額以及該客戶賬戶下的資產總額（轉換成用戶指定的幣種，缺省情況下為美元）。
前置條件：
    用戶已登錄，客戶的賬戶、帳號已知。  用戶已登錄，客戶的賬戶、帳號已知。
觸發事件：
    用戶選擇打印賬戶報告（證券余額清單）。  用戶選擇打印賬戶報告（證券余額清單）。
基本流：
    1. 用戶根據系統提示選擇結算幣種（用于計算資產總額），缺省值為美元。  1. 用戶根據系統提示選擇結算幣種（用于計算資產總額），缺省值為美元。
    2. 系統讀取該客戶帳號下的所有證券信息，打印每支證券的名稱、份數、單價和總價（即證券余額，等于單價 * 份數），總價用原幣種表示。  2. 系統讀取該客戶帳號下的所有證券信息，打印每支證券的名稱、份數、單價和總價（即證券余額，等于單價 * 份數），總價用原幣種表示。
    3. 系統根據該賬戶下的證券幣種讀取相應的結算匯率，把所有證券余額都統一轉換成結算幣種，并通過累加該賬戶下所有證券的余額，計算出以結算幣種表示的客戶資產總額并打印輸出。  3. 系統根據該賬戶下的證券幣種讀取相應的結算匯率，把所有證券余額都統一轉換成結算幣種，并通過累加該賬戶下所有證券的余額，計算出以結算幣種表示的客戶資產總額并打印輸出。
擴展流：
    2a. 系統讀取證券信息（份數、價格）失?。? 2a. 系統讀取證券信息（份數、價格）失?。?
        2a1. 系統報錯，用例結束。  2a1. 系統報錯，用例結束。
    3a. 系統讀取匯率失?。持ёC券的幣種到結算幣種的轉換匯率不存在）：  3a. 系統讀取匯率失?。持ёC券的幣種到結算幣種的轉換匯率不存在）：
        3a1. 系統告知用戶結算匯率不存在，無法計算資產總額，用例結束。  3a1. 系統告知用戶結算匯率不存在，無法計算資產總額，用例結束。

明確需求后，當我們打開軟件系統這只盒子，進入它的內部，把盒子內的一切東西、機關要害都搞清楚、弄明白，也就完成了軟件開發從需求，到分析，到設計，到編程實現的這么一個過程，而我們最終送給客戶的必須是一個高質量的大禮包。

那么，這只盒子內部有何寶物呢？由外而內，由大而小，一個軟件分別由系統，子系統（subsystem）與構件（component），以及對象組成。一個系統由一個或多個子系統組成，而一個子系統可以由一個或更多的子系統（或構件）組成。構件里面裝的則是對象，對象又由屬性和方法（即通常所說的函數）組成。類（對象）正是現代軟件的最小組成單元，就像組成有機人體的基本單元 —— 細胞。下圖用 UML 包圖表現了這樣一種軟件系統的嵌套解剖視圖。

層次分明

“分而治之”是工程界對付復雜技術問題最常用的手段。作為一個復雜的系統，軟件也不例外，清晰而嚴謹分層的結構往往是優秀軟件設計的一個主要特征。

分層有橫切、縱切兩種。軟件設計從系統，到子系統和構件，再到類與對象，再到類的內部屬性和方法，以及某個方法的編程實現，既是由外而內，也是從高到低，從高層的架構設計（系統、子系統），到低層的類與類的關系、類內部的設計，就像山脈與山峰、森林與樹葉的關系。對應著這樣的高、低層關系，在軟件設計中，目前世界上已有大量的架構模式、設計模式、實現模式和各種分層的框架可供我們借鑒、重用。

以上談的是軟件內部的分層。再舉一個軟件外部需求分層的例子。同樣用 UML 用例圖表示：

該圖說明在軟件的外部，軟件需求也是可以分層的?！邦A定酒店!”和“購買機票!”是用戶使用軟件的真正目標，屬核心用例，而特性“顯示賓館列表-”、“保存客戶信息-”、“可用航班排序-”等當然也是需求，但它們不過是更高層的需求 —— 用例當中的一個步驟。我們用 Cockburn 推薦的 “!”、“-” 等符號表示這些需求在層次粒度上的區別。

動靜結合

經常有初學者問：用 UML 建模的時候，我們到底要畫幾張圖才算表達完整，哪些圖最重要？其實有一個非常簡單的回答：動靜結合。

客觀世界是由物質（如微觀粒子）組成的，而物質是運動的。巧合的是，軟件這個虛擬世界也不例外。因此在我們設計軟件的時候，既要說明有哪些“虛擬”物質（如構件、對象、屬性等）存在，也不要忘了描述物質之間的運動（如交互、狀態變遷等），兩者是相輔相成的。

以下我們展現了參與“打印帳戶報告!”用例實現的主要對象之間，為了完成這一功能所結成的靜態關系（用 UML 類圖表示）和動態關系（我們選擇了 UML 協作圖）。





事實上，只有細致考慮了對象之間的靜態和動態關系（不管利用何種媒介，大腦抑或文檔），我們的軟件設計才算是完整的，編程才有正確的依據。不然，您的程序代碼從何而來？

逐步求精

軟件開發從軟件的需求（問題域）到可執行的高級程序設計語言源代碼（解決域），這中間究竟經歷了多少思考步驟和權衡過程？是一步到位嗎？實際上 1）宏觀地從軟件需求，到代碼實現 2）軟件設計中的從分析對象，到設計對象，再到實現對象，或者從設計模式到模式的編程實現，這些都是一個逐步求精的過程。

...

小結

UML 建模對于軟件設計的重要性，對于一名老練的 OO 程序員來說，是不言而喻的。UML 那抽象、簡潔、高于 Java、C++ 諸等高級程序設計語言之上的形象表達，可以讓我們真切領略到蘊藏于軟件那紛繁蕪雜的細節表面之后的一份簡單、和諧之美。

UML 作為一種圖形化建模語言規范，凝聚了世界上許多大師級 OO 建模、設計專家多年來的寶貴經驗，它的表達手段異常靈活和豐富，面對 UML 2.x 十幾種圖符，我們該如何運用？期望我與 Craig Larman 大師合作的《太極建模詩》能給讀者朋友們帶來一些有效的幫助，happy modeling !

原文轉自：http://www.kjueaiud.com