第1章.建模和UML 
1.1 粗放經營的時代已經遠去
1.2 利潤＝需求－設計
1.3 核心工作流
1.4 UML 簡史
1.5 各工作流中的UML 
1.6 基本共識上的溝通 
1.7 溝通僅限於開發團隊內部 
1.8 方法和過程 
1.9 案例介紹 
1.10 模型的組織 
1.11 工具操作
第2章 願景
2.1 最不可缺的工件 
2.2 願景的定義 
2.3 老大 
2.4 把產品當項目——定位具體的組織（人群） 
2.5 尋找老大：要點和典型錯誤
2.6 可度量的目標 
2.7 揣摩目標度量 
2.8 涉眾利益 
2.9 可以積累的財富
2.10 案例 
2.11 工具操作 
第3章.業務建模之業務用例圖 
3.1 軟件是組織的零件 
3.2 業務建模步驟1-1 ：選定要改進的組織 
3.3 業務建模步驟1-2 ：組織的業務用例圖 
3.3.1 業務執行者 54
3.3.2 業務工人和業務實體 
3.3.3 尋找業務執行者 
3.3.4 業務用例
3.4 案例 
3.5 工具操作
3.6 總結 
第4章.業務建模之業務序列圖
4.1 描述業務流程的手段
4.2 業務序列圖要點
4.2.1 消息代表責任分配而不是數據流動 
4.2.2 聚焦於繫統之間的協作 
4.2.3 隻畫核心域相關的繫統 
4.2.4 把時間看作特殊的業務實體
4.3 業務建模步驟1-3 ：現狀業務序列圖 
4.3.1 錯誤：把“現狀”誤解為“純手工”
4.3.2 錯誤：把“現狀”誤解為“規範” 
4.3.3 錯誤：以待開發繫統為中心拼湊流程
4.4 案例 
4.5 工具操作 
4.6 業務建模步驟1-4 ：改進業務序列圖
4.6.1 改進一：物流變成信息流
4.6.2 改進二：改善信息流轉 
4.6.3 改進三：封裝領域邏輯 
4.6.4 阿布思考法
4.7 案例 
4.8 工具操作
第5章.需求之繫統用例圖
5.1 繫統執行者要點 
5.2 需求步驟2-1 ：識別繫統執行者 
5.3 繫統用例要點
5.4 需求步驟2-2 ：識別繫統用例
5.5 用例的進一步講解
5.5.1 錯誤：玩弄“復用”
5.5.2 錯誤：玩弄“層次”
5.5.3 錯誤：玩弄“子繫統” 
5.5.4 錯誤：模糊的價值
5.5.5 提示：大用例無妨小用例
5.5.6 提示：用例的命名
5.6 案例 
5.7 工具操作 
5.8 總結 
第6章.需求之繫統用例規約
6.1 需求步驟2-3 ：書寫繫統用例規約 
6.1.1 前置條件和後置條件
6.1.2 涉眾利益
6.1.3 基本路徑 
6.1.4 擴展路徑
6.1.5 補充約束 
6.2 案例 
6.3 工具操作 
第7章.需求之需求啟發 
7.1 啟發障礙
7.2 需求啟發手段
7.2.1 研究資料
7.2.2 問卷調查 
7.2.3 訪談 
7.2.4 觀察 
7.2.5 研究競爭對手
7.3 需求工程師
7.3.1 好奇心 
7.3.2 探索力 
7.3.3 溝通力 
7.3.4 表達力 
7.3.5 熱情 

前.言

1999 年還是一名程序員時，我創建了UMLChina，從那時開始關注軟件工程各方面的進展。2001 年12 月，阿裡巴巴的吳泳銘來E-mail詢問是否有UML 方面的訓練，我開始準備訓練材料。2002 年3月，我去杭州給阿裡巴巴做了這個訓練。雖然與後來我給阿裡集團各公司做的許多次訓練相比，這第一次講課從內容到形式都算是糟透了，但是我現在還記得當時的心情——邁出自己事業第一步的心情。

截至目前（2013 年7月），我已經上門為超過190家軟件組織提供需求和設計技能的訓練和咨詢服務。訓練結束後，學員們常會問：“潘老師，上完課後我們應該看什麼書？”我總是回答：“先不用看雜七雜八的書，還是要復習我們留下的資料，那些幻燈片、練習題、模型就已經是最好的書了，按照改進指南先用一點點在具體項目上，帶著出現的具體困惑和我討論。”雖然一再這樣強調了，有的學員還是經常情不自禁地拿著一本《××UML××》之類的書來問我問題，不管書上說得對不對。看來寫在正式出版物上的效果就是不一樣。

其實現在出書也不難，UMLChina一直在和出版社合作推介國外優秀的軟件工程書籍，目前UMLChina的標記已經出現在三十多本軟件工程書籍上。不過我一直沒有自己寫一本書，主要原因還是覺得積累不夠，思考的深度也不夠，對軟件開發的認識還在不斷變化。如果沒有自己成型的東西，不能站在別人的肩膀上看得更遠，隻是摘抄別人的觀點，這樣的書有什麼意義呢？

另外一個原因是，UMLChina後來采取了“隱形、關門”的策略，秉持“內外有別”的原則。我關閉了已經有4萬多人的Smiling電子小組（也是為了降低某些風險），網站不再有公開的社區，在網站上也找不到“客戶名單”，所有更細致的服務以非公開的方式對會員提供。在這種情況下，出一本書也不是那麼迫切。

現在距離第一次提供服務已經超過十年，也有了一些積累，所以硬著頭皮也要開始寫書了。在這些年的服務過程中，和開發團隊談到改進時，我發現一個有趣的現像：很多開發團隊（不是每個團隊）或多或少都會有人（不是每個人）或明或暗地表達出這樣的觀點——自己團隊的難處與眾不同，奇特的困難降臨在他們身上，偏偏別人得以幸免。

盡管UMLChina一直強調自己的服務是“聚焦最後一公裡”，堅信每一個開發團隊都會在細節上和其他團隊有所不同，而且也應該有所不同，但很多時候，我還是感覺到，開發團隊高估了自己的“個性”，低估了“共性”。本書就是歸納這樣一些“共性”，作為我的一家之言，供大家參考。感謝曾經選擇我的服務的伙伴們。他們一次次地給我機會來實踐、發展和錘煉技藝，纔有了這本書。

本書中所講述的技能集合也是我本人身體力行的。例如，您可能已經注意到，為本書寫推薦序的正是本書的“老大”，他不是什麼大師專家名人，而是一名經歷了入職、升職和創業，不斷成長的軟件開發人員。

在每個知識點，我會提供一些針對該知識點的自測題，除了文字版本，還有可以自行測試的Flash版本，請在出版社網站http://www.tupwk.com.cn/downpage或http://www.umlchina.com 下載。

一些書籍作者喜歡在書中每一章的開頭放上和該章內容相關的一幅畫或一句名人名言，我也效仿一下，不過沒那麼“高雅”——每章的開頭放上和該章內容相關的一句歌詞。

書中的模型圖，如果是我為了講解知識而畫的，用的建模工具是Enterprise Architect 9.2；如果是截取真實模型的圖片，可能會涉及各種工具。我不像Robert C.Martin 那樣，女兒已經長大到可以幫畫插圖，所以書中的手繪插圖，我都自己用Wacom 筆來畫，可能丑了一些，請見諒。

歡迎您提供關於本書的任何反饋，我的郵箱是umlchina@gmail.com，QQ是2403816963 ，新浪微博是“UMLChina 潘加宇”，也歡迎您經常訪問www.umlchina.com。

潘加宇

2013.07

1999 年還是一名程序員時，我創建了UMLChina ，從那時開始關注軟件工程各方面的進展。2001 年12月，阿裡巴巴的吳泳銘來E-mail 詢問是否有UML 方面的訓練，我開始準備訓練材料。2002年3月，我去杭州給阿裡巴巴做了這個訓練。雖然與後來我給阿裡集團各公司做的許多次訓練相比，這第一次講課從內容到形式都算是糟透了，但是我現在還記得當時的心情——邁出自己事業第一步的心情。
截至目前（2013 年7月），我已經上門為超過190家軟件組織提供需求和設計技能的訓練和咨詢服務。訓練結束後，學員們常會問：“潘老師，上完課後我們應該看什麼書？”我總是回答：“先不用看雜七雜八的書，還是要復習我們留下的資料，那些幻燈片、練習題、模型就已經是最好的書了，按照改進指南先用一點點在具體項目上，帶著出現的具體困惑和我討論。”雖然一再這樣強調了，有的學員還是經常情不自禁地拿著一本《××UML××》之類的書來問我問題，不管書上說得對不對。看來寫在正式出版物上的效果就是不一樣。
其實現在出書也不難，UMLChina 一直在和出版社合作推介國外優秀的軟件工程書籍，目前UMLChina的標記已經出現在三十多本軟件工程書籍上。不過我一直沒有自己寫一本書，主要原因還是覺得積累不夠，思考的深度也不夠，對軟件開發的認識還在不斷變化。如果沒有自己成型的東西，不能站在別人的肩膀上看得更遠，隻是摘抄別人的觀點，這樣的書有什麼意義呢？

另外一個原因是，UMLChina 後來采取了“隱形、關門”的策略，秉持“內外有別”的原則。我關閉了已經有4萬多人的Smiling電子小組（也是為了降低某些風險），網站不再有公開的社區，在網站上也找不到“客戶名單”，所有更細致的服務以非公開的方式對會員提供。在這種情況下，出一本書也不是那麼迫切。
現在距離第一次提供服務已經超過十年，也有了一些積累，所以硬著頭皮也要開始寫書了。在這些年的服務過程中，和開發團隊談到改進時，我發現一個有趣的現像：很多開發團隊（不是每個團隊）或多或少都會有人（不是每個人）或明或暗地表達出這樣的觀點——自己團隊的難處與眾不同，奇特的困難降臨在他們身上，偏偏別人得以幸免。
盡管UMLChina一直強調自己的服務是“聚焦最後一公裡”，堅信每一個開發團隊都會在細節上和其他團隊有所不同，而且也應該有所不同，但很多時候，我還是感覺到，開發團隊高估了自己的“個性”，低估了“共性”。本書就是歸納這樣一些“共性”，作為我的一家之言，供大家參考。感謝曾經選擇我的服務的伙伴們。他們一次次地給我機會來實踐、發展和錘煉技藝，纔有了這本書。
本書中所講述的技能集合也是我本人身體力行的。例如，您可能已經注意到，為本書寫推薦序的正是本書的“老大”，他不是什麼大師專家名人，而是一名經歷了入職、升職和創業，不斷成長的軟件開發人員。
在每個知識點，我會提供一些針對該知識點的自測題，除了文字版本，還有可以自行測試的Flash 版本。
一些書籍作者喜歡在書中每一章的開頭放上和該章內容相關的一幅畫或一句名人名言，我也效仿一下，不過沒那麼“高雅”——每章的開頭放上和該章內容相關的一句歌詞。

書中的模型圖，如果是我為了講解知識而畫的，用的建模工具是Enterprise Architect 9.2；如果是截取真實模型的圖片，可能會涉及各種工具。我不像Robert C. Martin那樣，女兒已經長大到可以幫畫插圖，所以書中的手繪插圖，我都自己用Wacom 筆來畫，可能丑了一些，請見諒。
歡迎您提供關於本書的任何反饋。
潘加宇
2013.07