在軟件構造過程中，會用到兩種模型：系統分析模型和系統設計模型。

系統分析模型

系統分析模型又稱為問題空間模型，它根據實物——即準備實現的系統參照物——展開工作。系統分析首先考察實物的結構和組織，然后考察系統行為、方法，對系 統進行逐步分解并對分解出來的組成部分進行研究，理解其內容、形式、組織方式、行為規則等，在這個過程中積累知識，形成系統分析模型。

系統分析從系統的整體和高級知識入手，經過行為、方法的分析到達系統的底層，即數據層次。這個過程是一個思維發散的過程。系統分析要求建模人員盡量多的考慮系統中的各種因素，舉一反三，只要合理的東西都應該在模型中體現。

一般來說，系統分析進行到數據層次，即行為、方法的分析完成之后，其模型就可以做為系統設計的輸入，開始系統設計了。但這個時候系統分析做為一個建模過程 并未停止，對數據層次的建模和系統設計重合，這也就是我們平時所說的（面向對象的）系統分析和系統設計沒有明顯的界限。實際上在這里，在數據建模的層次， 系統分析和系統設計是重合的。

系統設計模型

系統設計模型也叫做解決方案模型，它的構造是針對并不存在的目標系統進行的。根據系統分析的饋入，系統設計和系統分析一起針對系統的數據層次進行建模。對 系統的數據建模，導致基本的實體對象模型產生。在這個基礎上，系統設計針對系統的行為和方法進行建模。在系統行為建模完成后，再對系統的結構和組織進行建 模。可以看到，系統設計建模過程是從系統的較低層次走向系統的高級層次，最終形成系統設計模型。

系統設計建模過程是一個思維收斂的過程。根據系統分析的結果，系統設計人員對多個可選的方案進行取舍，選擇合適的方案實現。如果說系統分析是一顆逐漸長大的樹，則系統設計是對樹的修正，使其成為一個最低成本的實現模型。

我們在軟件構造過程中使用的模型是系統分析模型和系統設計模型的集合，稱為表示模型。

在《小議模型》一文中我已經提到，現今國內軟件開發過程中產生的模型是不完整、不準確的。這也體現在：表示模型并不是由完整的系統分析模型和系統設計模型組成，通常由于種種原因，系統分析模型存在比較大的問題。

一般來說，一個比較好的表示模型應該由相對平衡的系統分析模型、系統設計模型組成。系統分析模型中的某個部分，一定在系統設計模型中有一個對應的部分，它 們共同描述同一組件（集）。這兩個部分是一致的，區別是一個由分析過程生成，一個由設計過程生成。對于這點，最普遍的一個誤解就是：我這邊已經有了，為什 么那邊還要有一套？

這個問題的答案很簡單。在《小議模型》中，我們已經解釋了語義間隙這 個概念，現在來看系統構造過程中的語義間隙。從大的方面來講，系統是這樣產生的：實物->分析模型->設計模型->實現的系統。這中間 基本上都存在語義間隙，尤其以實物到分析模型之間的間隙為最。試想，如果沒有分析模型，沒有分析模型中這看上去似乎多余的東西，這中間的語義間隙會有多 大？這不是猜想，這是曾經發生的事實，這是經驗教訓。

那么對于規模較小的系統，又是怎么樣呢？和大規模的系統是一樣的。小系統就沒有語義間隙嗎？大小只是規模不同而已，實質是一樣的。所謂麻雀雖小，五臟俱全。

模型粒度

最后來談談模型粒度的問題。簡單的說，就是模型到底要做到多細？模型最基本的要求就是要準確、易理解。對于一個過粗的模型，其準確性可能存在問題；對于一個過細的模型，其理解上可能又存在困難。而不粗不細，折中考慮，平衡點又在哪里呢？

其實就系統分析模型來講，主要就是要縮小其與實物之間，與設計模型之間的語義間隙。面對實物，要求模型表達準確；面對設計模型，要求表達清晰。這個基本上 靠個人水平了。我的方式是保證準確性，在這個前提下，用多幾個“包”來分解，這樣也基本上可以做到“清晰”。這個包，當然不是將來要設計實現的東西，僅起 到輔助表達的作用。

而對于設計模型來說，一個非常詳細的設計模型可以直接生成代碼，這就大大縮小了設計和實現之間的語義間隙。但畢竟設計不等于實現，一個精細的算法還是要靠 編碼人員完成，這就不得不考慮設計模型的易理解性。這里我的建議是：設計模型可以做的比較細，但模型在表達上要盡量考慮易理解性。舉例來說：一個EJB可 以在設計模型中對應到四個接口和一個實現類，但是在類圖中，我們完全可以只畫出實現類，使用stereotype標示其為EJB。這樣即可以生成代碼，又 不妨害理解。

后記：這篇隨筆來自于我最近做的一次培訓，刪掉了其中關于“系統知識層次模型”的部分。原因是該模型存在問題，反而可能造成理解上的偏差。如果大家對此感 興趣，或者有什么其他問題，可以討論一下。如果可能（我自己也不是很確定），還會有下一篇，或許應該叫《又議模型》吧。^_^