特徵模型和特徵-這是什麼？

  “  大家好，這是【產品線工程（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。

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

 

特徵模型的侷限性

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

 

作者：Danilo Beuche

翻譯：經緯恆潤

 

【產品線工程（PLE）專題】下期預告：產品線配置管理

* 如果您對PLE或pure::variants感興趣，可以透過 撥打電話與我們取得聯絡，同時還能獲得 pure::variants30天的試用申請哦~