“大家好，這是【產品線工程（PLE）專題】更新的第四篇，上一篇我們介紹了‘版本、變體和其他的基礎定義’，這一篇我們介紹特征模型和特征-這是什么”

非正式地談論可變性是很有趣的一件事，但最終還是需要以一種“標準”的方式來捕獲可變性的信息。在研究和工業界中有很多方法來捕獲可變性信息，其中較流行的方法被稱為特征建模。本文將對特征模型的基本概念進行解釋，并且對于回答“什么是特征？”這個有趣的問題給出一些提示。

? pure-systems GmbH

問題空間的特征

簡而言之，特征模型是簡單的、分層的模型，其可以捕獲到產品線的共性和特異性。問題空間（Problem Space）中的每個相關特性都會成為特征模型中的一個特征。這意味著，特征是系統中與利益攸關者（Stakeholder）相關特性。根據利益攸關者的利益不同，一個特征可以是一個需求、一個技術功能、一個功能組，或一個非功能（質量）特征。壞消息是：特征模型是一個用于描述共性和特異性的抽象概念。需要為每條產品線單獨決定特征究竟是什么。不過，特征的定義一般是與它們的實現是解耦的，即與解空間（Solution Space）解耦。

例如，如果汽車顏色是一個特征，其有個不錯的名字“深海藍”。這個名字永遠不會提到特定的油漆供應商的訂單號。這是因為特定的供應商與其訂單號是存在于解空間的。對軟件來說也是一樣的：特征是映射到單個功能還是分布在數十個組件中，是無關緊要的。如果利益攸關者認為它是一個相干的屬性并且其代表了特異性，那么它就是一個特征。

特征樹和變形類型

特征模型有一個樹狀結構：特征構成樹的節點，可變性由節點之間的弧及其通過變形類型分到的組中表示（譯者注：特征是節點，特征之間的關系是邊。特征的父節點可以有多個子節點，每個特征都具有變形類型并且會按照變形特征分組）。目前在大多數特征建模方法中，有四種的變形類型可供選擇。“強制”（Mandatory）、“可行”（Optional）、“多選一”（Alternative）、“或”（Or）。每個特征可以有多個具有不同變形類型的特征組作為子組（假設某個變形類型子組中特征總數為n）。在進行某一個變體的特征選擇時，規則為：當一個父特征在該變體中被選擇時，其子特征中：

???? 所有“強制”類的子特征必須被包含（n from n）

???? 選擇任何數量的“可選”類的子特征（m from n,0≤m≤n）

???? 必須從“多選一”類的子特征中準確地選擇一個特征（1 from n）

???? 至少有1個類型為“或”類的子特征被選擇（m from n,m≥1）

顯然，所有這些術語（例如可選或多選一）都被映射到一個可以被有效選擇的特征組的上下限上（譯者注：可選，0≤m≤n，即上限n，下限0）。上述這四個特殊的例子是較常用的變形類型。一般來說，即使在沒有看到形式化的定義時，也可以通過這些詞的概念正確的理解（除了“或”，因為人們通常認為它與“多選一”是同義的）。

當層級結構和變形類型還不夠的時候

???? 跨樹約束

大多數方法都允許您指定附加的約束，譬如特征之間的互斥關系（“正式襯衫”與“粉紅色”相沖突）以及需要關系（“正式襯衫”需要“白色”或“黑色”）。如果使用了多個特征模型，這些約束就會橫跨樹的不同層級，甚至跨樹。根據不同的方法和工具，表達這種約束的語言可以是簡單的專用語言或普遍可用的語言，如XPath或OCL。這些語言具有不同的表達能力和復雜性。但是，我們應該少用這些約束語言，這是因為約束條件越多，用戶就越難可視化和理解模型中的關系。

???? 復用特征子樹

一些方法有特征基數的概念，其允許表達特征模型子樹的多重性規則。例如，如果您有一個系統，其連接多個可配置的傳感器，那么不需要為每個傳感器創建一個（結構相同的）特征子樹，只需要創建一個特征子樹，并給它一個類似于（1-3）的基數聲明來表示需要傳感器子樹至少配置一個，最多配置三個。

特征模型的圖形化表達

對于特征模型的圖形符號，目前還沒有一個統一的標準，因此有許多不同的符號，在文獻中，較常用的是原始FODA方法的圖形符號的擴展形式。但是在標準文本工具和圖形庫中使用這種符號時會導致困難，這就是為什么我們中的一些人更喜歡更簡單的符號 - 就像我們在pure::variants中使用方式的原因。

什么是好的特征模型？

通過上面給出的特征定義（比較抽象），幾乎所有的東西都可以作為一個特征。從某種意義上說，這確實是事實。接下來的問題是：什么是特征？如何才能知道哪些要被選入特征模型？

比較重要的行動是要明確特征模型是針對利益攸關者而制定的。如果特征被終端用戶用來定義他們所擁有的獨特的產品變體，顯然特征必須是容易理解的。一個很好的例子是在大多數汽車制造商在其網站上提供的汽車配置。除了特征名稱之外，特征模型的結構也應該遵循終端用戶的思路。雖然聽起來很簡單，但創建這樣一個結構實際上是困難的。或者嚴格的說，這是不可能的。

???? 特征模型結構

創建一個結構較完美的特征模型之所以如此困難，原因在于很多情況下，有不同的方法來對系統進行配置。根據您的用戶類型，您可能要尋找一些小的、專業的功能，或者您可能要做一些一般性的決定，例如發動機的類型和尺寸，汽車的顏色等等。雖然一個特征模型確實允許自由導航（它沒有規定選擇特征的具體順序），但更一般性的決定是傾向于更接近模型樹的根部的，這反過來又會引導用戶深入到樹的這個部分或那個部分。

???? 一個模型或幾個模型

如果有不同的利益攸關者有不同的“語言”怎么辦？我們是應該建立多個特征模型（為每一組利益攸關者）還是只為重要的利益攸關者群體建立一個模型（誰是重要的呢）？同樣，針對這個問題給出一個明確的答案也是近乎不可能的。您使用的依賴關系越少，則模型越簡單越好。對于許多產品線的應用，使用一個特征模型是一個很好的選擇。然而，如果產品線的一部分本身形成了另一個獨立的產品線，那么多個特征模型幾乎是不可避免的。我們可以想象一下，一個在可配置的中間件上運行的應用。中間件的可變性必須使用應用開發者的語言來捕捉，并且應該對所有使用改中間件的應用使用相同的特征模型。在這種情況下，應用領域的變量與中間件領域的變量之間必須有一個映射關系。創建這種映射是應用產品線工程師的責任。在某些情況下，譬如中間件只在一個特定的配置中使用，因此可能沒有映射；在其他情況下，映射可能是非常復雜的。例如，如果應用層提供了安全應用操作和非安全應用操作的選擇，那么只要選擇了“安全應用操作”特征，中間件中的某些功能（如加密支持、基于證書的認證和SSL支持）就必須被啟用--除非該應用是為移動電話設計的，因為它不支持基于證書的認證。

???? 顆粒度

另一個需要考慮的方面是特征的顆粒度。如果特征的顆粒度太粗，有效配置的單個實例可能無法足夠詳細地描述系統，進而無法發揮預期作用；如果特征的粒度太細，那么特征的數量就會增加，管理和維護這些特征的復雜性和工作量也會增加。再一次地，我們考慮一下背景信息：自動產品配置比產品路線圖規劃和范圍需要更詳細的信息，同時也需要記得，后續增加細節比刪除細節更容易。

???? 迭代的方法

根據我的經驗，如果要獲得一個好的特征模型，那么較簡單的方法就是創建一個，并嘗試用它來描述產品線中已知的/設想的產品變體。在大多數情況下，我們很快就會發現現有的一些決定并不是很明智：有時所選擇的特征并不能很好地描述可變性（細節水平），或者樹狀結構是錯誤的，例如，建模中特征B是特征A的子特征，但是事實上，您也希望能夠只選擇特征B而不是特征A。

不要怕，這些錯誤有助于我們在下一輪創建更好的特征模型。在大多數情況下，有問題的是結構而不是特征本身。關于特征和特征模型，還可以寫很多，此時我們按下不表，在后續文章中將會介紹。

特征模型的局限性

還有一件事要提：雖然我確實認為特征模型是描述產品線可變性的一種比較重要的技術，但在某些情況下，僅僅靠特征模型是不夠的。甚至在某些情況下，特征模型根本不是可行的方法！如果可變性是組合類型，即有許多基本元素（想想用于建造房屋的磚石）可以按照一些正式規則進行組合。這些規則允許使用潛在的無限數量的磚塊。那么在這種情況下，特征模型根本不允許您有效地描述這一點。然而，當談到描述磚石的潛在屬性（顏色、磚材料等）時，特征模型就非常適合用于描述可變性。這些只是為了表明：在很多情況下，特征模型只是可行的方法。