軟體產品線工程方法：如何在OpenExpressApp做客戶化工作

文章目錄

• 版本原則
• 可變性管理
• 考慮模型驅動
• 應用案例情境

　　很多產品都會遇到客戶化問題，也就是在通用產品之上針對一些客戶會進行配置和定製工作，也就是處理721問題（為了簡單描述這類問題，我們簡單的使用721術語，7為通用功能，2為可變功能，3為個性功能，這裡721隻是從數字分布上表明共性和個性的大致比例，實際中並不完全就是按照721比例分配），表示的就是產品線的主注內容，這個在我以前blog中也介紹過多次，本篇重點是介紹如何在OpenExpressApp這種物件導向架構下做客戶化。

版本原則

• 以往的客戶化分支版本原則帶來的問題

　　以往我們做客戶化時，可能會專門弄出一個客戶化小組，並且從SVN中弄出一個代碼分支，然後變更，個性的東西都儲存在各自的分支中，對於共性問題在開發後期再單獨合并到主幹中去，這樣可以帶來一個好處就是在進行客戶化任務時可以獨立於主幹版本，可以較為自由的變更。

　　但是這會帶來後期的合并版本問題：

1. 如果分支功能很多，我們以前的做法時專門用一期任務來做合并工作，這又勢必帶來工作的重複
2. 有時合并過程中說不定還會帶來客戶化與主幹版本之間設計上的衝突
3. 由於沒有明確採用可變性管理而是使用分支版本方式來管理客戶化工作，當客戶化數量增加時勢必勢必會帶來管理的複雜性

　　我想這也就是產品線工程方法中對於代碼一套性說法的原因，產品線工程認為產品所有功能（包括721）在任何時候都可以通過一套原始碼庫擷取，然後通過可變性管理等手段來達到針對客戶化發布。

• OpenExpressApp的產品線版本原則

　　OpenExpressApp是基於產品線工程方法來做的，我畫了一個圖，用來說明一下我擬定項目後期對於客戶化工作的總體版本原則，如所示：

• 只有一個主幹版本，這個產品的所有功能都由同一個程式碼程式庫來管理，包括通用功能、可變功能，並且還包括個性功能，這些功能通過類繼承、模型動態配置、代碼靜態配置等方式來處理可變性
• 通用功能和可變功能由領域工程來完成，將作為產品線的核心資產；個性功能由應用工程完成
• 分支版本只在臨時性的情況下發生，例如馬上需要給客戶示範，並且需要在短時間修複一些bug再次示範時，我們可以臨時性的打出一個分支。需要明確的是，這個分支一定是拋棄型的，並且是短期存在的
• 721中的功能會隨著客戶的增多帶來功能遷移的情況，也就是以前是個性的可能會變為可變性或共性，以前是可變性的可能會變為共性，共性的也可能會變成可變性功能，這就要求我們在產品開發過程中隨時進行重構

可變性管理

• 處理可變性的方法

　　在軟體產品線工程方法 － 四個主要方法原則中介紹過產品線中的可變性管理，在技術架構上來講，存在以下三種基本的處理可變性方式：

中矩形框代表整個軟體，三角矩形代表組件，圓形代表介面。下面我簡單介紹一下這三種方式，後面會把我們現在常用的一些技術對應到這三種方式上。

• 適配

只有一個組件實現，但是該組件提供各種介面方式來改變它的行為，例如可能採用設定檔、運行期參數或者組件原始碼補丁方式。

• 替換

一個組件有多種實現，每個組件都符合該組件介面規範。領域工程中可以提供多種實現，然後在應用工程中選擇其中一個，或者在應用工程中遵循組件規範開發一個個性的組件

• 擴充

擴充需要架構提供一些允許增加新組件的擴充點，添加的組件可以是特定產品或者架構內部的。這些組建不是系統提供的功能，而是由外部插入到系統中的，這就要求系統架構必須考慮清楚有哪些擴充點。

• 具體的可變性機制
  • 繼承(適配)
    子類通過繼承父類來改變一些預設行為，只有一個實現組件
  • 補丁(適配)
    如果可以獲得組件的原始碼，通過補丁方式可以有效地更改部分行為，而不需要維護整個組件。通過這種方式，補丁由應用工程來維護，而組件本身由領域工程來維護
  • 編譯期配置（適配）
    編譯器提供機制在編譯期改變組件，預先處理和宏就屬於這種方式。Makefiles可以編譯多個不同變體的組件，或者選擇一個正確的組件
  • 運行期配置（適配）
    組件內部有多種實現，運行期可以通過配置動態改變組件行為
  • 代碼產生 (替換)
    代碼產生通過讀取一些進階別模型或者指令碼等約定來產生某些組件或者整個產品所需要的代碼
  • 組件替換 (替換)
    預設實現了多個組件，這些組建可以是領域工程實現的，也可以是應用工程特定實現的，只要符合一定介面約定都可以通過替換整個組件來改變具體功能實現方法
  • 外掛程式 (擴充)
    有很多外掛程式為系統提供擴充點，外掛程式只要找到擴充點就可以添加額外需要的功能

考慮模型驅動

在沒有模型驅動時，客戶化工作更多的可能是通過代碼、配置、指令碼來完成，如果考慮模型，則需要對可變性建模，以下是產品線工程中的一種可變性元模型圖例：

如果我們也支援類模型，那麼類模型和可變性模型可以按照以下方式對應：

如果我們採用了代碼產生技術，通過這些模型後，我們可以進一步對特定產品只產生需要的代碼。

應用案例情境

例如清單綜合單價積累可以形成典型清單庫，通過積累過程也可以形成圖集組價庫。對於這種需求來說，從使用者需求以及銷售角度來看，我們可以把對圖集庫的支援作為產品的可選附件。我們實現的理想方案可以是提供一或多個dll，當考到目錄下系統則加入圖集功能，這就需要我們應用上面的可變性技術來解決。

• 採用適配和替換方式，通過從綜合清單類庫繼承下來，增加圖集相關屬性
• 添加相應的一些圖集相關模組
• 把圖集相關的內容部署到獨立於主程式的dll，以便通過簡單的複製功能達到模組的配置
• 當然還有更多的一些方法，這些需要在實際工作中不斷深化......

推薦：你可能需要的線上電子書   

我的微博：http://weibo.com/openexpressapp

敏捷個人sina圍裙：http://q.t.sina.com.cn/135484  

歡迎轉載，轉載請註明：轉載自周金根 [ http://zhoujg.cnblogs.com/]