《軟體方法》第1章 模組化和UML

牽着你走進傍晚的風裡，看見萬家燈火下面平凡的秘密。

《情歌唱晚》；詞：黃群，曲：黃群，唱：曹崴；1994

1.1 粗放經營的時代已經遠去

改革開放初期，中國出現了許多農民企業家，他們不用講管理，也不用講方法，隻要膽子大一點，就能獲得成功，因為當時的市場幾乎空白，競争非常少。農民企業家的思路很簡單：人人都要吃飯，是以開飯館能夠賺錢。現在這樣的思路已經行不通了。市場競争已經足夠激烈，十家新開張的飯館恐怕隻有一家能撐下來，是以農民企業家已經很少見（連農民都越來越少了）。軟體業也一樣，最開始的時候，會程式設計就了不得，思路也很簡單：每個公司都要做财務，是以開發财務軟體能賺錢。現在呢？我們想到一個“點子”，可能有上千人同時想到了；我們要做一個系統，可能發現市場上已經有許多類似的系統。你賣高價，他就賣低價，你賣低價，他就幹脆免費。機會驅動、粗放經營的時代已經遠去，為了在激烈的競争中獲得優勢，軟體開發組織需要從細節上提升技能。

本書聚焦于兩方面的技能：需求和設計。關于需求和設計，開發人員可能每天都在做，但是否了解背後的道理呢？我們來做一些題目：

本書不提供練習題答案，請掃碼或通路http://www.umlchina.com/book/quiz1_1.html完成線上測試，做到全對，自然就知道答案了。

1. 軟體開發中需求工作的目的是____。

 A) 讓系統更加好賣

 B) 更好地指導設計

 C) 對系統做概要的描述

 D) 滿足軟體工程需求規範

2. 軟體開發中設計工作的目的是____。

 A) 對系統做詳細的描述

 B) 更好地指導編碼

 C) 降低開發維護成本

 D) 滿足軟體工程設計規範

1.2 利潤＝需求－設計

利潤＝收入－成本。不管出售什麼，要獲得利潤，需要兩個條件：

（1）要賣出好價錢；

（2）成本要低。

妙就妙在，價格和成本之間沒有固定的計算公式，這正是創新的動力之源。放到軟體業上，我也炮制了一個公式：

利潤＝需求－設計

在軟體開發中，需求工作緻力于解決“提升銷售”的問題，設計工作緻力于解決“降低成本”的問題，二者不能互相取代。能低成本生産某個系統，不一定能保證它好賣。系統好賣，如果生産成本太高，最終還是賺不了多少錢。

如果需求和設計不分，利潤就會縮水。從需求直接映射設計，會得到大量重複代碼；如果從設計出發來定義需求，會得到一堆假的“需求”。

拿自古以來就有的一個系統“人肉系統”來舉例。人肉系統的功能（能做什麼）是走路、跑步、跳躍、舉重、投擲、遊泳……但是設計人肉系統的結構時，不能從需求直接映射到設計，得到“走路子系統”、“跑步子系統”、“跳躍子系統”……人肉系統的“子系統”是“呼吸子系統”、“消化子系統”、“循環子系統”、“神經子系統”……“子系統”不是從需求直接映射出來的，需要設計人員的想象力——本例子的設計人員就是造物主了。同樣，也不能從設計推導出需求：因為人有心肝脾肺腎，是以人的用例是“心管理”、“肝管理”。如圖1-1所示。

圖1-1 人肉系統的需求和設計

水店老闆要雇一個民工送水（即租用一個人肉系統），他隻要求這個民工能跑能扛就行，管他體内構造是心肝脾肺腎還是一塊電路闆；民工找工作也要從市場的需要來找，而不是從自己的内部器官出發來找——“老闆，我有心髒管理功能，你請我吧！”

很多時候我們說“本系統分為八大子系統……”，其實說的是“本系統的功能需求分為八大需求包……”需求包是基于涉衆視角對系統功能分包而得到的，子系統是基于内部視角根據系統部件的耦合和内聚情況切割而得到的。

需求和設計的差別簡要列舉如圖1-2所示，在後面的章節中再慢慢闡述這些差別。

圖1-2 需求和設計的差別

高煥堂在他的書《USE CASE入門與執行個體》中說過：用例是收益面，對象是成本面。本書基于他的思想做了擴充。

1.3 模組化工作流

要達到“低成本制造好賣的系統”的目标，并非喊喊口号就可以，需要靜下心來學習和實踐以下各個模組化工作流中的技能。

1. 業務模組化——定位需改進的目标組織以及組織最需要改進的問題。

2. 需求——描述為了改進組織的問題，所引入的系統必須具有的表現。

3. 分析——提煉為了滿足功能需求，系統需要封裝的核心域機制。

4. 設計——考慮品質需求和設計限制，将核心域機制映射到標明非核心域。

軟體開發人員如果缺乏軟體工程方面的訓練，對以上工作流沒有概念，就會把這些工作産生的工件通通稱為“設計”或者“文檔”。例如問開發人員在做什麼，回答“我在做設計”、“我在寫文檔”，其實他的大腦可能正在思考組織的流程（業務模組化），或者在思考系統有什麼功能性能（需求），或者在思考系統要包含的領域概念之間的關系（分析），但他通通回答成“在做設計”、“在寫文檔”。後來又有牛人說了：代碼就是設計。本來“設計”在他腦子裡就是“代碼以外的東西”，這麼一推導，不就變成了：代碼就是一切？

很多大談“編碼的藝術”的書籍和文章，其實探讨的根本不是編碼的技能，而是分析技能甚至是業務模組化技能，隻是作者的大腦裡沒有建立起這些概念而已。編碼确實有編碼的技能，就像醫院裡護士給患者打點滴也需要經過訓練，但如果患者打點滴後死亡，更應該反思的是護士的打點滴手法不過關，還是醫生的檢查診斷技能不過關？

把工件簡單分割為代碼和文檔（或設計），背後還隐含着這樣的誤解：認為模型（文檔）隻不過是源代碼的另一種比較概要或比較形象的表現形式。這種誤解不隻“普通”的開發人員會有，一些著名的UML書籍作者也有。Martin Fowler 所著的UML暢銷書《UML精粹》，認為UML有三種用法：草稿、藍圖和程式設計語言，也是僅從編碼的角度來說的。從Fowler寫作的其他書籍《重構》、《企業應用架構模式》、《分析模式》等可以知道，他的研究工作集中在分析設計工作流，特别是設計工作流，在業務模組化和需求方面研究不多。

不同工作流産出的工件之間的差別不在于形式，而在于内容，也就是思考的邊界，如圖1-3所示。如果清楚了解這一點，即使用C#也可以表達需求，用Word也可以“編碼”。

圖1-3 模組化工作流思考邊界

有的開發人員思維剛好是颠倒的，先拍腦袋實作，然後再從實作反推前面的内容。例如下面的對話：

顧問：這個不應該是系統的用例。

開發人員：是系統的用例！我都寫好了，運作一下給你看看，系統确實提供了這個用例。

顧問：這兩個類關系不應該是泛化，而是關聯。

開發人員：是泛化，不信我打開代碼給你看，或者逆向工程轉出類圖給你看。

是否系統用例應該以“好賣”來判斷，是否泛化關系應該以“符合領域内涵”來判斷，而不是先寫好代碼，再用代碼來證明。

一些不了解以上概念的軟體開發人員幹脆以“靈活”、“疊代”為名，放棄了這些技能的修煉。就像一名從護士成長起來的醫生，隻掌握了打針的技能，卻缺少檢查、診斷、拟治療方案等技能，索性說：“唉，反正再高明的大夫，也不能一個療程把患者治好，幹脆我也别花那麼多心思了，先随便給患者打一針看看吧，不好再來！“。“疊代”隻是一個底線，确實，再高明的大夫也沒有把握一個療程就治好患者，是以要按療程試試看，但是每一個療程中，依然要盡力檢查、診斷、拟治療方案。檢查、診斷等技能越精湛，所需要的療程就越少。

唱曲的名家，唱到極快之處，吐字依然幹淨利落；快節奏的現代足球，職業球員的一招一式依然清清楚楚；即時戰略遊戲高手要在極短時間内完成多次操作，動作依然井然有序。

有的開發團隊用“項目時間太緊”作為放棄模組化的理由，這個理由是不成立的。以聯考做類比，如果一年之後要聯考，學霸會認真做一年的計劃，再做一周的計劃，再做每天的計劃，找出分值最大而自己又最薄弱的地方先複習，并且随進度調整計劃，不斷提高，最終考了700分。學渣則渾渾噩噩，零敲碎打，最終考400分。假設教育部門突然下令，一周之後就要聯考！學渣可能心裡暗喜，以為自己翻身的機會來了。學霸依然會認真做一周的計劃，再做每天的計劃，找出分值最大而自己又最薄弱的地方先複習，并且随進度調整計劃，不斷提高，最終考得550分。學渣虛度了一周時間，考了350分。有一個著名的學渣，每次失敗後總結教訓“備戰時間倉促”，其實再給學渣四年，它也是混四年，最終還是那個樣子——這個學渣就是中國足球。

在激烈競争的年代需要快速應變，掌握技能才能真靈活。世上無易事，偷懶要不得。不能把“靈活”、“疊代”作為偷懶的庇護所。

有些網際網路開發人員鼓吹“試錯大法”，主張拍腦袋拿出去讓市場試錯，這同樣是很荒謬的。客戶确實不管你怎麼開發的，他隻需要挑好用的就行，但對于開發系統的組織來說，有沒有被挑中則是緻命的。就像奴隸主看角鬥士厮殺，奴隸主無所謂誰勝誰負，反正過程精彩，最終嘉獎冠軍就行，而每一個角鬥士卻要如履薄冰，想方設法讓自己堅持到最後。可悲的是，網際網路公司是角鬥士，卻偏偏有“我是奴隸主”的錯覺。

剛入行的開發人員體會不到模組化的重要性，是正常的。就像下象棋，初學者面對單車對馬雙士、單馬對單士等已經有共識的局面還需要思考良久，最終還拿不下來甚至輸掉。這時中局和布局的書在他看來多半是枯燥無味的，還不如把一本實用殘局彙編看熟了，學到一些雕蟲小技，也能在菜市場赢幾盤棋。不過，要邁向職業棋手的境界，參與更殘酷的競争，就體會到中局和布局的重要了。

從我的觀察所得，以上四項技能，大多數軟體組織做得較好的是設計（也就是實作），前面三項都相當差，特别是業務模組化和分析，沒有得到足夠的重視。很多軟體組織拍腦袋編造需求，然後直撲代碼，卻不知“功夫在詩外”。

本書中的“需求”和“設計”兩個術語有兩種用途。一種用于表達模組化得到的結果，例如“需求和設計不是一一對應的”；另一種用于表達模組化的工作流，即需求工作流和設計工作流，例如“我正在做需求”。希望下面的話能幫助了解：為了得到需求，需要做的模組化工作流有業務模組化和需求，為了得到設計，需要做的模組化工作流有分析和設計。

到目前為止，我沒有談到UML。隻要您思考過上面四個工作流的問題，就是在模組化。可以用口頭表達，也可以用文本、UML、其他表示法或自造符号來表達。在每一個項目中，開發團隊肯定會思考和表達上面這些問題，隻不過可能是無意識地、不嚴肅地做。現在，我們要學習有意識地做，而且把它做出利潤來。使用UML來思考和表達是目前一個不壞的選擇。

本書不提供練習題答案，請掃碼或通路http://www.umlchina.com/book/quiz1_2.html完成線上測試，做到全對，自然就知道答案了。

1. 開發人員說“根據客戶的需求，我們的系統分為銷售子系統、庫存子系統、财務子系統……”，這句話反映了開發人員可能有什麼樣的認識錯誤？

 A) 開發人員沒有認識到面向對象設計的重要性

 B) 開發人員直接從設計映射需求

 C) 開發人員直接從需求映射設計

 D) 開發人員沒有用UML模型來描述子系統

2. 打開開發人員寫的需求規約，發現用例的名字都是“學生管理”、“題庫管理”、“課程管理”……，這背後可能隐藏的最大問題是什麼？

 A) 用例的名字不是動賓結構，應改為“管理學生”……

 B) 用例粒度太粗，每一個應該拆解成四個用例，“新增學生”、“修改學生”……

 C) 開發人員直接從需求映射設計

 D) 開發人員直接從設計映射需求

3. 以下這些經常在開發團隊裡使用的詞彙，都是不嚴謹的。其中_______混淆了需求和設計的差別。

 A) 功能子產品

 B) 詳細設計

 C) 使用者需求

 D) 業務架構

4. 以下描述最可能對應于軟體開發中的哪個工作流？

每個項目由若幹活動組成，每項活動又由許多任務組成。一項任務消耗若幹資源，并産生若幹工件。工件有代碼、模型、文檔等。

 A) 業務模組化

 B) 需求

 C) 分析

 D) 設計

5. 以下描述最可能對應于軟體開發中的哪個工作流？

 A) 業務模組化

 B) 分析

 C) 需求

 D) 設計

6. 以下描述最可能對應于軟體開發中的哪個工作流？

系統向會員回報已購買商品的資訊。

 A) 業務模組化

 B) 分析

 C) 需求

 D) 設計

7. 以下描述最可能對應于軟體開發中的哪個工作流？

某集團向優馬神州經理提出舉辦講座的請求後，經理根據請求決定請哪一位專家，并拟定講座計劃，交給組織從業人員執行。組織從業人員根據經理提供的專家資料通過Email、電話等各種方式聯系專家，和專家商議講座的時間和主題。

 A) 業務模組化

 B) 分析

 C) 需求

 D) 設計

8. 如果問開發人員“你在做什麼”，他說“我在寫文檔”，那麼他有可能（本題可多選）______。

 A) 不了解軟體開發各工作流的差別

 B) 把自己的工作簡單分為“代碼”和“文檔”

 C) 認為文檔就是代碼的叙述性檔案

 D) 知道“文檔”和“代碼”的真正差別是什麼

9. 以下說法和其他三個最不類似的是______。

 A) 如果允許一次走兩步，新手也能擊敗象棋大師

 B) 百米短跑比賽才10秒鐘，不可能為每一秒做周密計劃，憑感覺跑就是

 C) 即使是最好的足球隊，也不能保證每次進攻都能進球，是以練習傳球配合是沒用的，不如直接大腳開到對方門前

 D) 雖然大家都考不及格，但考58分和考42分是不一樣的

1.4 UML簡史

随着市場所要求軟體的複雜度不斷增大，軟體開發的方法學也在不斷進化。從沒有方法到簡單的功能分解法，再到資料流/實體關系法。進入20世紀90年代，面向對象分析設計（OOAD）方法學開始受到青睐，許多方法學家紛紛提出了自己的OOAD方法學。流行度比較高的方法學主要有Booch、Shlaer/Mellor、Wirfs-Brock責任驅動設計、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE。

這種百花齊放的局面帶來了一個問題：各方法學有自己的一套概念、定義和标記符号。例如現在UML中的操作（Operation），在不同方法學中的叫法有責任（Responsibility）、服務（Service）、方法（Method）、成員函數（Member Function）……同一個類圖，不同方法學也有各自的符号表達，如圖1-4所示。這些細微的差異造成了混亂，使開發人員無從選擇，也妨礙了面向對象分析設計方法學的推廣。

1994年，Rational公司的James Rumbaugh和Grady Booch開始合并OMT和Booch方法。随後，Ivar Jacobson帶着他的OOSE方法學加入了Rational公司，一同參與合并工作。這項工作造成了很大的沖擊，因為在此之前，各種方法學的擁護者覺得沒有必要放棄自己已經采用的表示法來接受統一的表示法。

Rational公司的這三位方法學家被大家稱為“三友”（three amigo）。1996年，三友開始與James Odell、Peter Coad、David Harel等來自其他公司的方法學家合作，吸納他們的成果精華。1997年9月，所有建議被合并成一套建議書送出給OMG。1997年11月，OMG全體成員一緻通過UML，并接納為标準。

從2005年起，UML被ISO接納為标準。相當于UML 1.4.2的ISO标準是ISO/IEC 19501，相當于UML 2.1.2的ISO标準是ISO/IEC 19505。2012年，ISO繼續接納UML 2.4.1為ISO/IEC 19505-1:2012 和ISO/IEC 19505-2:2012，接納OCL 2.3.1為ISO/IEC 19507:2012。

2011年，中華人民共和國也釋出了統一模組化語言國家标準GB/T28174。

圖1-4不同方法學圖形比較（同樣一個三角形符号，在Coad/Yourdon方法學中用于表示關聯，而在OMT方法學中用于表示泛化） UML的最新版本是OMG于2015年6月通過的UML 2.5。相關網址如下：

OMG UML 2.5規範：http://www.omg.org/spec/UML/2.5/PDF

ISO UML規範：

http://www.iso.org/iso/home/store/catalogue_tc/catalogue_detail.htm?csnumber=52854

中華人民共和國國家标準：http://www.chinagb.org/ChineseStandardShow-197675.html

時間過去二十年了，UML不斷發展，在表示法上已經獲得了勝利。随便打開一本現在出版的軟體開發書，裡面如果提到模組化，使用的符号基本都是UML，即便在紙上随便畫個草圖，樣子也是UML的樣子。各種主流的開發平台也相繼添加了UML模組化的功能。OMG還和各種行業标準組織如DMTF、HL7等結盟，用UML表達行業标準。

另外，以UML為契機，掀起了一股普及軟體工程的熱潮，在UML出現後的幾年，不但有關模組化的新書數量暴增，包括CMM/CMMI、靈活過程等軟體過程改進書籍數量也出現了大幅度增長。制定UML标準的角色（OMG）、根據标準制作模組化工具的角色（UML工具廠商）、使用UML工具開發軟體的角色（開發人員）這三種角色的剝離，也導緻模組化工具的數量和種類出現了爆炸性的增長。而之前的資料流等方法從來沒有像面向對象分析設計方法一樣，出現UML這樣的統一表示法，進而帶動大量書籍和工具的産生。

最開始一批UML書籍，基本上由方法學家所寫。最近幾年，以“UML”為題的新書大多為高校教材或普及性教材。這并不是說UML已經不重要，而是沒有必要再去強調，焦點不再是“要不要UML”，而是要不要模組化、如何模組化。

根據UMLChina的統計，UML相關工具最多時達168種，經過市場的洗禮，現在還在更新的還有近百種。有錢買貴的，沒錢就買便宜的或者用免費或開源的，可參見UMLChina整理的UML工具大全：http://www.umlchina.com/Tools/search.aspx。

1.5 UML應用于模組化工作流

UML 2.5包含的圖形如圖1-5所示，一共14種（泛化樹上的葉結點）。

圖1-5 UML圖形（根據UML2.5規範繪制）

可能您看了會說，哇，這麼多圖，學起來用起來多複雜啊。其實，UML像一個工具箱，裡面有各種工具。模組化人員隻需要根據目前所開發系統的特點，從這個工具箱中選擇合适的工具就可以，并不需要“完整地”使用UML。這和程式設計語言類似。很多人說“我用Java”，其實隻是用Java的一小部分，而且很長時間内也隻會用這一小部分。

經常有學員問：潘老師，能不能給一個案例，完完整整地實施了整套UML？這是一種誤解，這樣的案例不應該有。這相當于問：有沒有一本經典的小說，把字典裡所有的單詞都用上了？有一些模組化工具自帶的案例模型會造成誤解，一個模型裡把所有的UML圖都給用上了，但這是工具廠商出于展示其工具模組化能力的目的而提供的，不可當真。

各模組化工作流可以選用的模組化圖形以及推薦用法如圖1-6所示。

圖1-6 可選和推薦的模組化元素用法（●表示優先使用，√表示可以使用 ）

觀察圖1-6中标有●的地方可以知道，掌握用例圖、類圖、序列圖這三種圖基本上夠用了，可以先重點學習這三種圖，其他圖形暫時不管。針對特定類型的項目，如果有必要，可以按需添加圖形。例如，開發複雜組織的營運系統，如果在業務模組化時不喜歡用序列圖，可以用活動圖取代；對于系統中的核心類，可以着重畫出狀态機圖來模組化類内部的邏輯；針對品質要求很高的系統，每一個類可能都需要畫狀态機圖，甚至還要畫時間圖。

另外，設計工作流目前推薦的做法是不需要畫UML圖，用文本來表達實作模型，即所謂“代碼就是設計”——編碼就是一種模組化工作。計算機運作的是二進制指令，源代碼實際上也是“模型”。之是以被稱為“源代碼”，是因為它是人腦需要編輯的最低形式模型。這個最低形式模型随着時代的發展不斷變化。

如圖1-7所示，最初的源代碼是機器語言。程式員在紙帶或卡片上打孔來表達0和1。後來發現這樣太累了，于是發明了一些助記符，這就是彙編語言。今天會有開發人員故意裝低調，“這些我不太懂唉，我是做底層的，用C編碼”，可是C語言卻被歸類為“進階語言”，因為類似C這樣的語言出現的時候，大多數程式員編輯的是彙編語言，C相對于彙編來說，當然很進階。今天的一名企業應用程式員，需要編輯的可能有HTML、CSS、JavaScript、Java、配置腳本、SQL等，這些就是現在的“源代碼”的形式。

圖1-7 “源代碼”的發展曆程

如果人腦隻需要編輯UML模型就可以實作系統，那麼“模型就是源代碼”。例如用帶有設計級調試和強大代碼生成能力的工具IBM Rational Rhapsody開發實時嵌入系統，人腦隻需要編輯和調試UML模型（類圖和狀态機圖）。

1.6 基本共識上的溝通

不少開發人員并不喜歡用UML，更喜歡在白闆上畫個自造的草圖，似流程圖非流程圖，似類圖非類圖，然後說“來，我給大家講講！”這樣的做法有巨大的“優點”：怎麼畫都是對的，關于這個草圖的解釋權歸“我”所有。同僚不好批評“我”，項目要依賴于“我”頭腦中的隐式知識——要是“我”不“給大家講講”，大家就玩不轉了。這樣，“我”在團隊裡的地位就提高了。上面這種現象，在有一定資曆、但又不對項目的成敗承擔首要責任的“高手”身上表現得更明顯。

★開發人員讓我看他的模型時，如果開口說“我先來給你講講”，我都會攔住，“如果還需要你先講講，說明你所想的沒有展現在模型中” 。

這種做法的本質是想通過形式上的醜陋來遮掩内容上的醜陋。動亂年代，數學家在牛棚中用馬糞紙做數學推導，不代表就可以因為演算工具簡陋而允許自己胡亂使用符号和概念；過去的作家沒有電腦，不意味着可以随意寫錯别字和犯文法錯誤。開發人員故意選擇簡陋的形式為簡陋的内容開脫，就如同作家故意選擇不好的紙來掩蓋自己文字功力不足的事實，并不是好現象。UML沒有強調一定要用多麼昂貴的工具來模組化，即使開發人員在海邊用手指在沙灘上模組化，模型所展現的概念依然要清晰。

如圖1-8所示，數學裡的積分符号、五線譜的小豆芽，幼稚園小朋友也會畫，但背後的道理需要經過艱苦的訓練才能了解。就像數學符号背後隐含着數學的基本共識，五線譜背後隐含着基本樂理一樣，UML背後隐含着軟體模組化的一些基本共識，這些共識需要一定的訓練才能掌握。

掌握統一的模組化語言之後，開發團隊在基本共識上溝通，會大大提高溝通的效率和深度，有意無意遮掩的膿包也會強制露出。開發人員如果習慣于畫“草圖”，用“子產品”、“特性”等詞彙含糊不清地表達思想，在嚴謹模組化思維的追問之下，往往會千瘡百孔，暴露許多之前沒有想到的問題。這是一些“高手”潛意識裡不願意直面UML的深層原因——如果有“高手”不同意，歡迎把所畫的草圖發過來，我告訴您背後隐藏的膿包。

圖1-8 符号背後隐含基本共識

面對一個棋局，下一步怎麼走？在業餘棋手看來到處都是正确答案，在職業棋手眼裡，值得讨論的選項隻有兩三種，因為職業棋手針對一些基本的技能形成了共識，大大減少了思考中的浪費。

有些“靈活”軟體組織，抛棄了所有“文檔”（前文已說過，如果使用“文檔”這個詞，說明概念不清楚），更喜歡口頭交流，動不動就開會，你一嘴我一嘴，場面看起來熱熱鬧鬧，其實溝通的效果不好，更談不上思考的深度和知識的沉澱。對比一下街坊老大爺下象棋的熱鬧和職業棋手比賽時的沉靜就知道了。“靈活”的理由也不成立，街坊老大爺判斷局勢的速度快還是職業棋手判斷局勢的速度快？野路子棋手不看棋書不打譜，擺個路邊攤也許夠用，如果參加職業比賽，非被打得落花流水不可。

★有的開發人員的“十年工作經驗”實際上是“一年工作經驗用了十年”，一直在熱熱鬧鬧的民工層次徘徊，沒有積累和成長。

不過要注意一點：使用UML溝通僅限于軟體組織内部，UML模型不是用來和涉衆溝通的！這個道理以及和涉衆溝通的技能将在第7章詳細叙述。

1.7 模組化和靈活（Agile）

靈活運動在20世紀90年代中期興起，當時靈活過程被稱為輕量（lightweight）過程。2001年，Kent Beck、Martin Fowler等人聚集在猶他州的Snowbird，決定把“靈活”作為新的過程家族的名稱，并提出以下宣言：

個體和互動 勝過 過程和工具

可以工作的軟體 勝過 面面俱到的文檔

客戶合作 勝過 合同談判

響應變化 勝過 遵循計劃

靈活運動可以看作是“政治正确”的左翼思想在軟體開發領域的一次演練。這次演練和在人類社會其他領域已發生的左翼演練一樣，迅速取得了成功，帶來了一批“有信仰”的軟體從業者。我有專文《靈活傳播的最佳實踐》]比較兩者在理論背景以及成功經驗方面的共通之處。此處不再細談，隻談談口号和方法的差別。

有口号有方法，有口号無方法，無口号無方法，這三種情況哪一種最壞？可能有的人認為無口号無方法最壞，其實不然，無口号無方法地呆在原地，可能會慢慢衰落，但不是最壞的。曆史上各種最壞的大悲劇往往和“有口号無方法”有關。

最壞的事是“有口号無方法”的“好人”做的。偷盜搶劫的壞人知道自己做的是壞事，會暗自收斂，事後會内疚，甚至做一些善事來彌補以求心安；而“好人”認為自己是做好事，是以會做得很極端，如果有口号無方法，大悲劇就發生了。例如，有人談論社會上存在的(□□此處作者删去三十二字□□)問題，列舉的大都是事實，結果給出的解決方案卻是(□□此處作者删去二十八字□□)。有一句名言“通往地獄的道路通常是由善意鋪就的”，就是這個意思。

軟體開發領域也有不少有口号無方法的場景。

口号：我們隻做最重要的需求，盡快把系統推向市場。問題來了：怎麼知道哪個需求最重要？拍腦袋？口号：設計要分離變和不變，這樣可以減少變更的成本。問題來了：怎麼知道哪些變哪些不變？抓阄？

模組化為口号提供了方法。願景、業務模組化方法，幫助迅速定位最重要的需求；領域分析方法，幫助厘清各種概念的變和不變。

開發團隊要警惕有口号無方法的成員。這些害群之馬擅長喊口号打雞血，上班時間端着茶杯大談老子、莊子、孫子、禅、道……吐槽軟體項目中的各種痛苦。這些痛苦确實是事實，結果給出的解決方案卻是荒謬的。

有兩幢大樓，地震中一幢倒塌了，另一幢沒倒塌。倒塌的直接因素可能有大樓的結構、所用的材料、所在位置的地質環境等，但這些都涉及比較艱深的工程力學、材料學和地質學知識。有人懶得思考，幹脆就直接嚷“有人吃回扣了”，就算經過調查沒人吃回扣，他也會從工作服的顔色，勞工是否結對洗澡，施工隊開會時是否站立等方面來找原因，因為這相對容易。

本書内容針對的是影響軟體品質的直接原因——缺少各種模組化技能。許多團隊實施過程改進容易流于形式，根源往往就在于模組化技能的不足。如果把改進的焦點先放在模組化技能上，開發人員技能提升了，适用什麼樣的過程自然就浮出水面，沒有必要去生搬硬套某過程。或者說，技能增強了，更能适應不同的過程。UML模組化沒有綁定到特定過程。目前主流的軟體過程都是強調增量和疊代開發，應該把前面所講的業務模組化、需求、分析、設計看作是一個疊代周期裡的工作流，做一點業務模組化，做一點需求，做一點分析，做一點設計……不可誤解成“做完了所有的業務模組化才能做需求”……

很多時候方法和過程經常被混淆，有人會把“靈活”說成“靈活方法”，其實“靈活”是一個過程家族。之是以造成這個誤解，也許和Martin Fowler把他介紹靈活過程家族的文章起名為“新方法學（The New Methodology）”有關。另一個常見的誤解來自Robert C. Martin的書《靈活軟體開發——原則、方法與實踐》，書中主要講的是面向對象設計的一些方法（原理、原則和模式），這些方法并非Robert C. Martin首先提出，而且和靈活過程沒有必然關系，但是，經常會有開發人員誤解面向對象設計的這些思想是靈活人士提出來的。更有一些靈活人士在沒有學習和掌握軟體工程知識的情況下，先高喊“砸爛一切”吸引熱血青年，然後發現砸爛一切是不行的，又偷偷拾起過去被自己砸爛的東西，加上自己的“靈活”包裝，有意無意地給不了解曆史的新入行開發人員造成“這是靈活發明的，那是靈活發明的，是以把靈活挂在嘴邊的人最懂”的印象。

我剛開始為軟體組織提供服務時，有一次和一個軟體組織的經理交流，經理說“我們用的是面向過程方法”。我一開始信以為真，認為如果能做到用面向過程方法，從組織級、系統級到子產品級層層分解也不錯的。後來發現，經理所說的“面向過程方法”其實是随意的功能分解，也就是沒有方法。

類似的場景還有：軟體組織負責人說“我們現在采用的是靈活過程”，稍為深入了解，多半會發現其實他所說的“靈活過程”就是沒有過程。不要讓“面向過程”、“靈活”成為偷懶的庇護所。

1.8 什麼樣的系統不需要模組化

這是經常被問到的一個問題。前文已經說過，編碼就是模組化，是以什麼樣的系統都需要模組化。這個問題真正要問的是“什麼樣的系統可以不用業務模組化、需求、分析，而直接設計（編碼）”。

1.8.1 市場沒有小系統

過去的軟體工程書籍中，談到模組化的重要性時，常會說：“自己搭個狗屋不需要模組化，蓋摩天大樓需要模組化，因為後者更複雜。”這樣的說法并不正确。在市場經濟的環境下，如果要掙到錢，搭狗屋和蓋摩天大樓的複雜度是一樣的。狗屋有狗屋的品牌，摩天大樓有摩天大樓的品牌，蓋摩天大樓的公司要搶搭狗屋公司的市場可沒那麼容易——世上無易事，市場沒有小系統，見圖1-9。

要是我問您，跑百米容易還是跑馬拉松容易？這還用問！當然是跑百米容易了，是吧？其實我想問的是：亞洲運動員要拿奧運冠軍，是跑百米容易還是跑馬拉松容易？答案似乎就颠倒過來了。近鄰南韓和日本都已經出過奧運馬拉松冠軍，比起拿百米冠軍，機率要大多了。

不同形态的系統各自有各自的複雜性，看起來做一個電廠管理資訊系統好像很牛，但做一塊電表的學問也不小。到現在為止，我服務的組織覆寫了國内各個領域的領袖企業，包括通信、企業管理、電子商務、房地産、網絡遊戲、地理資訊、物流、數位裝置、醫療裝置、工業控制等領域。業務模組化、需求、分析等模組化技能都适用于這些企業的項目。無論是上千萬人同時使用的社交系統，還是行政人員使用的内部辦公系統，還是埋藏在人體内的小裝置，模組化是否值得，和系統的運作形态無關，而是看軟體組織有沒有一顆冠軍的心。

圖1-9 商城中的貓狗窩品牌

1.8.2 你的系統不特别

還有一種以為不需要模組化的情況是，開發團隊經常認為自己做的系統“比較特别”，以此作為懶得深入思考的理由。如果學習了本書的模組化技能，就會發現之前認為特别的項目其實沒有什麼特别，包括所謂的“遺留系統”、二次開發系統、内部系統、移動網際網路系統、政績工程……一些網際網路開發人員動不動就鼓吹“網際網路思維”，拼命強調自己所開發系統有多特别，無非是偷懶和為失敗尋找借口而已。

★見識少的病人總以為自己得了怪病，其實到醫院讓醫生一看，太普通了。

還有一個常聽到的偷懶庇護所是“軟體開發是藝術”。軟體開發是不是藝術，我不知道，不過就算軟體開發到了極高境界真的是藝術，恐怕也不是大多數人目前有資格談的。下棋到很高境界，也有各種流派風格，但那是在通曉了基本棋理的基礎上演變出來的，連基本棋理都沒有掌握的初學者，把自己的胡思亂下也當成“流派”就不合适了。

我在指點模組化人員改正他所畫的模型的時候，偶爾會有下面的現象。模組化人員拿出他所做的模型，我逐個評點錯誤的地方，讓他回去好好複習相關知識點——這不是所有人都能靜下心來做到的，有的人随便掃兩眼，改一改又拿給我看，我又打回去。三四次之後，哪位模組化人員洩氣了，“老師，是不是你這個方法不适合我？我自己搞一套規範行不行？”不是規範的問題，是背後的基本道理。

師父糾正少林弟子武功招數的細節，弟子懶得去了解為什麼按師父教的會好一點，反而說：“師父，可能少林武功不适合我，我去武當派當武當高手算了”，以為這樣一說，自己就可以搖身一變成為武當派高手了。其實，基本功都是一樣的。少林派武功學精了，如果對武當派武功感興趣，轉起來容易很多。如果某人學少林派武功時面對細節總是以“不糾結”為由拒絕進一步思考，很難相信他學習武當派武功時會好到哪裡去。

本書到現在為止，已經說了很多回“偷懶”，就是強調世上無易事，好的方法應該能強迫您思考，強迫您付出心血和汗水來獲得競争優勢，反之就是忽悠，就像前些年一些甜得發膩的靈活宣傳。

1.9 案例介紹

本書的案例講述UMLChina如何改進其内部業務系統的故事。我在序言說到，UMLChina秉持“内外有别”的原則。在外面看來，UMLChina的網站其貌不揚，十幾年如一日，UMLChina組織的資訊化其實藏在背後。

UMLChina一開始把領域放在軟體工程，後來發現，這個領域已經太大了，沒有能力在這麼大的範圍内做到最好，于是縮小範圍，專注于和UML相關的模組化技能。2002年-2004年間我們和出版社合作翻譯了《人月神話》、《人件》等軟體工程書籍，這方面的書籍後來不再做了，隻做模組化相關的書籍。

我為UMLChina所做的定位是：做世界上最小和最好的模組化咨詢公司。咨詢工作适合做精，不适合做大。UMLChina沒有招攬或培養滿屋子的“年輕資深咨詢師”，通過擴大規模來提高收入，有的機構這樣做了，也獲得了更多的收益，但那不是我們的路。

一旦從深度上定位，就會發現要做的事情非常多，2005年，我決定着手開發UMLChina的業務系統。經過這些年持續改進和更新（也仍将繼續改進和更新），雖然現在離我希望的“武裝到牙齒”的境界還有很大的距離，但這個和UMLChina業務結合在一起的系統确實能夠讓UMLChina不必請更多的人就可以保持正常運作。因為很多業務邏輯已經封裝在系統中，是以也比較容易分權給助理。

後面給出的素材絕大部分是真實的，如果有一些地方做了模糊處理，那是出于商業上的考慮。UMLChina在商業方面的事宜有公司負責運作，本書隐去公司真實名字，仍把這個公司叫做UMLChina。

1.10 模型的組織

從前面的圖1-6可以知道，模組化工作流和所用的UML元素不是一一對應的。模型可以按照UML元素的種類組織，也可以按照工作流來組織。

本書推薦的模型組織方式是按工作流組織，如圖1-10所示。本書提供了一個初始Enterprise Architect（以下簡稱EA）模型，該模型已經按照圖1-10的組織方式建好了包，并且添加了一些業務模組化和分析的構造型（Stereotype）。我建議讀者直接從本書提供的初始模型開始做，按部就班填空即可。初始模型的下載下傳位址是http://www.umlchina.com/training/myproject.rar。初始模型使用EA13編輯儲存，使用其他EA版本打開編輯也應該沒有問題。您在熟練掌握本書的模組化技能以後，如果體會出對您的項目更合理的組織方式，可以抛棄本書所推薦的方式。如果您平時使用的工具不是EA，而是RSA、StarUML、VP-UML等，也可以自行按照圖1-10的方式組織模型。UML工具（包括EA）一般都會預置一些模闆，建議先無視它們。

圖1-10 按工作流組織模型（推薦做法）

另外一種常見的模型組織方式是按視圖來組織，如圖1-11所示。以前Rational Rose預設的組織方式就是這樣，最開始我也是這麼做的，但是後來發現開發人員容易出問題的地方不是用什麼圖，而是目前在做什麼。開發人員的思維經常跳來跳去，無意識地改變思考的焦點——正在讨論系統之間的協作流程，突然就跳入某個系統的内部讨論類的關系，甚至類的某個操作内部的實作。是以，本書不推薦按視圖組織模型。

圖1-11按視圖組織模型（不推薦）

本書不提供練習題答案，請掃碼或通路http://www.umlchina.com/book/quiz1_3.html完成線上測試，做到全對，自然就知道答案了。

1. UML三友是哪三位？

A) Messi、Neymar JR和Luis Suárez

B) Luciano Pavarotti、Placido Domingo和Jose Carreras

C) Martin Fowler、Kent Beck和Alistair Cockburn

D) James Rumbaugh、Grady Booch和Ivar Jacobson

2. 以下不屬于OOAD方法學的是_______。

A) Booch方法

B) Demarco方法

C) Rumbaugh OMT

D) Coad/Yourdon方法

3. 以下不屬于UML圖形的是_______。

A) 流程圖

B) 狀态機圖

C) 序列圖

D) 通信圖

4. 以下不屬于本書推薦常用的UML元素的是_______。

A) 用例圖

B) 元件圖

C) 序列圖

D) 類圖

5. 以下不是UML工具的是_______。

A) Enterprise Architect

B) DOORS

C) Astah

D) MagicDraw

E) Plato

F) Rhapsody

6. 一些開發人員更喜歡畫“草圖”，然後說“來！我給大家講講”，深層原因是_______。

A) 這樣更靈活，現在流行“靈活”

B) 草圖更自由，有發揮的空間

C) 想通過形式的粗陋遮掩内容的粗陋

D) 親身講解勝過模型文檔交流

7. 經常被當作“偷懶庇護所”的說辭有（多選）_______。

A) 軟體開發是藝術，藝術是沒有道理可講的

B) 我們靈活了

C) 模組化帶來競争優勢

D) 不管用什麼方法，把項目做成功就是好方法

8. 以下軟體開發名人中，和前央視主持人小崔（崔永元）同齡的是_______。

A) Martin Fowler

B) Kent Beck

C) Ivar Jacobson

D) Peter Coad

E) James Rumbaugh

F) Grady Booch

9. 以下說法正确的是_______。

A) 在項目中可以隻挑選一部分UML元素來使用

B) UML模型的最佳案例就是模組化工具附帶的例子

C) 團隊引進UML時，努力達到的最終目标應該是完整應用所有的UML元素

D) UML是軟體開發人員和客戶之間溝通的絕佳工具

10. 以下說法正确的是_______。

A) 功能很少的系統不需要模組化

B) 類很少的系統不需要模組化

C) 市場上已經有很多現存産品的系統不需要模組化

D) 不參加競争的系統不需要模組化

1.11 工具操作

在開始項目實作的講解之前，我們先建立模型，并對Enterprise Architect做一些設定。

【步驟1】在Windows資料總管輕按兩下模闆檔案myproject.eap， Enterprise Architect啟動并打開myproject.eap，如圖1-12所示。

圖1-12 啟動EA

【步驟2】在左上角

菜單選擇Save Project As...，在對話框Target Project欄中設定建立模型檔案的位置和名稱，确認選中Reset New Project GUIDs複選框，單擊Save As按鈕。與在資料總管裡複制模闆檔案相比，以上做法可以重置所有辨別值，保證模型元素不沖突。如圖1-13所示。

圖1-13 從模闆項目建立新項目

【步驟3】單擊CONFIGURE菜單，選擇Model組中的Options，在Manage Project Options對話框中選擇General頁簽，設定Font Face和Font Size為合适的預設字型。本書的選擇是大小為14的微軟雅黑。如圖1-14所示。

圖1-14 設定預設字型

【步驟4】單擊START菜單，選擇Workspace組中的Preferences，在Diagram|Theme頁簽的Diagram Theme欄選擇Monochrome for printing，單擊Save。這一步把圖形風格設成黑白色，如果不喜歡，可以跳過。如圖1-15所示。

圖1-15 設定圖形顔色風格