軟件設計過程經驗談 之 如何作好領域模型設計

       常常聽到領導教誨，開發的同事應該要往前走一步，去作產品？去作售前？這也是一種方式，只不過是一大步。我的以爲，在邁出這一大步以前，須要先走出一小步：從寫好代碼到作好設計。

       下圖是按照軟件工程的通用作法，梳理出的標準設計指南，已經很是清晰地定義了軟件設計的階段和活動，產物規約，文檔要求以及須要配合的培訓。比較適合於人朋規模大、產品化程度高、外包服務模式。按照這個標準的設計指南，把每一階段的事情作好，這是標準的開發方法論的實踐指導。

       有人會說，如今是移動互聯網的時代，咱們的產品開發要求短、頻、快地上線，這種標準的設計方法已經不適合了，我覺的不徹底正確。個人作法是，根據產品的願景和市場狀況，按照標準的設計指南作一些定製性的剪裁，哪怕文檔所有裁完了，腦子裏分析時仍然要按照這幾個階段開展對應的活動，由於這不只是指南，更是方法論，針對這個幾階段開展過的活動，下面就梳理下個人設計經驗。

        首先是需求捕獲和分析階段，老是感受需求在不斷地變化，總是怪市場和產品經理，其實不少狀況是咱們對需求的理解不到位。既有業務理解不許確，也有支撐方式不合理。還有一點就是將原型與需求沒有進行區分，原型不表明需求。將需求分析劃分爲業務需求與系統需求兩個階段，作好領域分析，才能根本性地適應需求的不斷地變化。 

      接下來談談如何作好系統分析，在這個階段通常又叫建領域模型，又叫概念模型，分析對象模型，它專一於分析問題領域自己，發掘重要的業務領域概念，並創建業務領域概念之間的關係。領域模型設計是需求分析的關鍵步驟。它幫助用戶及需求分析人員創建業務概念，肯定用戶業務的問題域，系統涉及的業務範圍等等。

     領域模型設計的通常步驟爲：

一、從業務描述中提取名詞

二、從提取出來的名詞中總結業務實體，區分名詞中的屬性、角色、實體、實例，造成問題域中操做實體的集合；

三、從業務實體集合中抽象業務模型，創建問題域的概念

四、用UML提供的方法和圖例進行領域模型設計、肯定模型之間的關係。注：實體之間的關係，主要有泛化、依賴和關聯，關聯又分了通常關聯、聚合、組合等

       簡言之，先分析出模型實體，而後找出模型實體之間的關係。

    領域模型與實數據模型的關係：領域模型是與用戶溝通的一個重要工具，是需求分析人員與用戶共同理解的概念，是彼此之間交流的語言。它是一個分析模型，描述的是業務中涉及到的實體及其相互之間的關係，它是需求分析的產物，與問題域相關。同時給咱們需求分析人員和系統功能提供了必定的擴展視野，看到未來需求的可能變化或可能存在的問題。而數據模型是系統設計、實現的一部分，描述的是對用戶需求在數據結構上的實現，固然數據模型中的概念模型設計與領域模型相似，缺少的是實體之間更普遍的關係描述。

 

 

     這裏以開放平臺業務管理爲例，設計出的領域模型圖紙，歡迎你們拍磚。