軟體開發的那些事兒：解決之道

前面提出了軟體開發的輪迴：期望——破滅——崩潰——新的輪迴，我們的解決之道在哪裡呢？

我的反思——不在沉默中爆發，就在沉默中滅亡

反思，我在反思……

對於來自客戶的變更，我永遠忘不了的是大學時老師的諄諄教導。上軟體工程課的時候，老師總是一再地反覆強調，一定要將需求變更消滅在需求分析階段。按照過去的瀑布式開發理論的描述，總是要求我們在需求分析階段瞭解清楚客戶的所有需求，並編寫成《軟體需求說明書》，交給客戶簽字。客戶一旦在《軟體需求說明書》上籤字，那麼需求就不能再更改了，軟體就照這個開發了。但隨著時間的推移，軟體理論大師們發現，軟體設計過程中的業務變更越來越不能為人們所忽視。隨後，一個又一個的理論出來了，什麼軟體設計模式、UML、極限編程（XP）、敏捷開發、反覆式開發法，等等等等。按照現在的理論，業務變更貫穿到了從需求分析到後期維護的整個軟體系統生命週期中，我們隨時都在應對著各種不同的業務變更。我們要做的就是通過合理地設計，使我們對業務變更付出的代價達到最小，這也就是我們常說的，設計一個可維護的系統。如果不是應對每一次的業務變更，我們的所有編程理論就變得毫無價值，我們不再需要講究什麼“低耦合、高內聚”，不再需要分層結構，我們將重新回到“天是藍的，生活是美好的，程式設計也是輕鬆愉快的”那樣一個純真的年代。但現實就是，我們必須做出改變，我們必須要努力去設計出一個個靈活多變的、可維護的系統。

如何能夠保證我們設計出的是可維護的系統呢，大師們通過實踐給出了我們一個又一個的方法。總體上說，就是要建立模型，即按照順序依次建立用例模型、領域模型、分析模型和設計模型，採用迭代的方式一步一步地去設計我們的系統。模型是對我們要解決的問題空間的抽象。我們將現實世界抽象成一個個模型，可以協助我們更加有序地認識和分析問題，運用我們所掌握的知識，設計出更加合理的系統。

用例模型和領域模型主要是在需求分析階段完成的，而分析模型和設計模型則主要是在確認需求以後、開始編程以前的分析設計階段完成的。但它們隨著軟體開發的整個過程，隨著需求的每一次變更也在進行著同步更新，從而形成一個又一個的版本。下面我依次對這四個模型的功能及其各自的作用進行一些簡要介紹。

用例模型（Use-Case Model）

用例模型是軟體需求分析的開始。當我們的使用者不論是用書面的形式還是口頭的形式開始向我們表達需求的時候，需求都是淩亂的，需要我們進行整理。我們在整理需求的時候，要將其表達成即能讓客戶看懂又能讓技術人員看懂的圖形和文字。這樣做，一方面是為了進一步與客戶交流，確認需求，另一方面也是為技術人員分析和設計系統提供依據和基礎。為了做到這一點，它包含兩個部分內容：使用案例圖和用例說明。

使用案例圖關注的是三部分內容：用例、參與者和系統邊界。

用例就是一個用來描述參與者如何使用系統來實現其目標的一組情境的集合。聽起來有些抽象，我們不妨理解為功能中的一個模組，如在ATM機上操作是一組情境，也就是銀行管理系統中的ATM機管理子模組。它可以繼續細分成ATM機取款、ATM機查詢、ATM機轉賬等多個情境，也就是ATM機管理子模組下的取款、查詢、轉賬等功能，它們的每一個也就是使用案例圖中的一個個子用例。使用用例分析需求帶給我們的重要作用之一，就是將使用者所要描述的整個問題空間分割成了一個又一個的模組，然後在每個具體模組下再進一步的描述問題。使用用例的另一個作用就是將客戶粗獷的需求描述，轉換成了非常嚴謹的語言表述，詳細描述清楚了情境中每一個操作流程的整個過程。同時，該描述中用到的專業詞彙的外延與內涵都必須表述清楚，避免出現二義性（關於用例模型的作用、意義、設計過程以及準則，我將在《談談用例模型的那些事兒》中詳細描述）。

參與者給大家最直觀的認識就是作業系統的那些人，但更準確的說應當是作業系統的那些角色。用例模型要求系統分析員描述清楚系統中的每一個情境的每一步操作，操作者是什麼角色。然而，參與者除了表示作業系統的人，還表示處於系統邊界之外，與系統邊界內的用例有關聯的其它系統。因此，只有定義好一個系統的邊界，才能定義哪些是這個系統內的用例，哪些是這個系統內外的參與者。

系統邊界是一個軟體系統需要處理的整個問題空間的範圍。一個軟體系統不可能處理所有問題，我們必須得給它定義這個問題空間的範圍。哪些是我們這個軟體可以處理的，哪些則是我們這個軟體不能處理的，也就是專案管理中所說的專案範圍。

使用案例圖可以直觀地展現需求中的所有用例、參與者、系統邊界，以及它們之間的關係。但是使用案例圖不能夠詳細描述每個用例、每個參與者、系統邊界，以及它們之間關係的定義。同時，每個用例還要描述它的前置條件、後置條件、基本路徑、擴充路徑等一系列文字。因此，我們需要一個用例說明文檔來詳細說明使用案例圖。

除了使用案例圖和用例說明，在需要的時候還可以畫出一些簡單的活動圖表和狀態圖，來描述一些複雜的或是關鍵性的流程。

查看本欄目更多精彩內容：http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

領域模型（Domain Model）

系統分析員在需求分析階段，除了建立和編寫用例模型以外，還並不足以支援我們後來的系統分析與設計，他還應當建立領域模型。領域模型是在與客戶交流的過程中，整個問題空間包含的所有重要概念，及其相互關係的表述。在領域模型中，問題空間又被表述為業務領域。而業務領域中的所有重要概念被描述成了一個又一個的對象或屬性。比如，學籍管理是學籍管理系統的業務領域，在這個業務領域中的學生被描述成了“學生”對象，而學生的姓名被描述為“學生”對象中的“姓名”屬性。然而，學生的家庭住址，根據客戶的要求，即可以描述為“學生”對象中的“家庭住址”屬性，也可以描述為另一個“家庭住址”對象並包含“城市”、“街道”、“郵寄地址”和“郵編”等屬性。由此可見，領域模型是一堆類圖。

領域模型是對業務領域的如實描述，他不包含任何技術實現，也不包含任何分析設計。領域模型關注的是業務領域中的重要概念及其相互之間的關係。領域模型關注的不是業務領域中的所有概念及所有關係。它關注的是對我們要開發的軟體系統有用的概念及其關係。領域模型中的概念和關係可能是在與客戶交談的過程中擷取（《領域驅動設計》的作者Eric Evans甚至鼓勵我們與客戶一邊交談一邊在紙上畫出領域模型），而另一部分是從用例模型的語言描述中擷取。

領域模型不是一張大圖。一張囊括了業務領域中所有概念和關係的類圖常常讓人困惑。領域模型應當是一個又一個的情境，我們是在某個情境下描述它的相關概念和關係。（關於領域模型的分析與設計，我將在《談談領域模型的那些事兒》中詳細描述。）

分析模型（Analyze Model）

當系統分析員與客戶進行了一段時間的充分溝通，業務需求基本上確認下來以後，項目開始進入分析設計階段了。在分析設計階段的主要工作就是建立分析模型。建立分析模型的工作非常繁雜，它是OOA/D的開始，它需要對需求分析中的每個情境建立靜態模型（一系統的類圖或對象圖，描述系統需要建立的各種類及其相互之間的關係）和動態模型（一系統的行動圖、順序圖表、狀態圖，描述系統中的所有流程，包括主流程、分支流程，以及流程中各種對象的調用關係，對象在流程中的狀態變化）。建立分析模型的工作是一個迭代的過程，起初的迭代是需求的如實描述，接著開始GRASP設計模式以及其它的OO分析理論，對靜態模型和動態模型進行最佳化，尋找更靈活多變、易於維護、高內聚、低耦合的設計方案。

分析模型應當是站在整個系統的高度來看待設計中的每個情境，它必須充分考慮各個模組的協作以及公用代碼的複用。因此，那些各個模組都要使用的功能和商務邏輯被提取出來。但是，分析模型與設計模型最大的區別是，它不包含任何實際的技術。你的系統不論採用J2EE來實現，還是.Net來實現，分析模型都是一樣的。它也不關注你是採用兩層結構還是三層結構，採用的Oracle還是SQL Server資料庫，這些都不是它關心的。運用分析模型，我們可以站在一個更高的高度設計我們的系統，使我們的系統規劃得更加合理。這也就是我們引入分析模型的重要原因之一吧。（分析模型的建立過程、方法、原則，以及GRASP設計模式，我將在《談談分析模型的那些事兒》中詳細描述。）

設計模型（Design Model）

分析模型經過數次迭代以後就逐漸過渡到設計模型，並沒有一個明確的鴻溝。設計模型的重要區別就是它開始考慮到各種具體的技術。設計模型的產出物就是通過Rational Rose這樣的工具正向產生為我們要設計的代碼，但這非常理論而不太現實。設計模型最讓人困惑的就是它到底細化到什麼程度。也就是說，設計模型要設計到多細我們才開始編程。分析設計是系統分析員完成的，而程式設計是程式員完成的。如果設計模型做得太細了，對系統分析員是一個巨大的工作量，而把好多程式員的工作給做了，同時，對程式員的束縛過大。如果當初的設計存在缺陷，將必須返回系統分析員重新修改設計模型，費時費力，得不償失。所以我認為，設計模型不宜太細，從整體上把握主要部分就可以了。同時，程式員在設計程式的過程中可以自己設計自己的設計模型，這時我們常說的GoF設計模式可以派上用場了。它對我們提高設計水平和代碼品質大有協助。（設計模型的過程、理論，以及一些常用的GoF設計模式，我將在《談談設計模型的那些事兒》中詳細描述。）