軟件企業追求長遠的發展，通常采用產品線模型及系統演化策略，它實質上是用架構技術構建產品線，并在此基礎上借助復用技術持續演化，不斷地推出新產品，滿足市場追求產品升級換代的需求。

(相關資料圖)

1 復用與產品線

軟件產品線是指一組軟件密集型系統，它們共享一個公共的 、 可管理的特性集，滿足某個特定市場或任務的具體需要，是以規定的方式用公共的核心資產集成開發出來的。即圍繞核心資產庫進行管理 、 復用 、 集成新的系統。

核心資產庫包括軟件架構及其可剪裁的元素，更廣泛地，它還包括設計方案及其文檔 、 用戶手冊 、 項目管理的歷史記錄（如預算和進度） 、 軟件測試計劃和測試用例。復用核心資產（特別是軟件架構），產品線將會驚人地提高生產效率 、 降低生產成本和縮短上市時間。

創建一個成功的產品線取決于軟件工程 、 技術管理和組織管理等多個方面的協調，這里只對軟件架構方面進行討論。

基于產品間共性的 “ 軟件 ” 產品線代表了軟件工程中一個創新的 、 不斷發展的概念。

軟件產品線的本質是在生產產品家族時，以一種規范的 、 策略性的方法復用資產。可復用的資產非常廣，包括以下幾點。

需求：許多需求與早期開發的系統相同或部分相同，如網上銀行交易與銀行柜面交易。架構設計：原系統在架構設計方面花費了大量的時間與精力，系統成功驗證了架構的合理性，如果新產品能復用已有的架構，將會取得很好的效益。元素：元素復用不只是簡單的代碼復用，它旨在捕獲并復用設計中的可取之處，避免（不要重復）設計失敗的地方。建模與分析：各類分析方法（如性能分析）及各類方案模型（如容錯方案 、 負載均衡方案）都可以在產品中得到復用。測試：采用產品線可積累大量的測試資源，即在考慮測試時不是以項目為單位，而是以產品線為單位，這樣，整個測試環境都可以得到復用，如測試用例 、 測試數據 、 測試工具，甚至測試計劃 、 過程 、 溝通渠道都可以得到復用。項目規劃：利用經驗對項目的成本 、 預算 、 進度及開發小組的安排等進行預測，即不必每次都建立工作分解結構。過程 、 方法和工具：有了產品線這面旗幟，企業就可以建立產品線級的工作流程 、 規范 、 標準 、 方法和工具環境，供產品線中所有產品復用。如編碼標準就是一例。人員：以產品線來培訓的人員，適應于整個系列的各個產品的開發。樣本系統：將已部署（投產）的產品作為高質量的演示原型和工程設計原型。缺陷消除：產品線開發中積累的缺陷消除活動，可使新系統受益，特別是整個產品家族中的性能 、 可靠性等問題的一次性解決，能取得很高的回報。同時也使得開發人員和客戶心中有 “ 底 ”。

2 基于產品線的架構

軟件產品線架構是針對一系列產品而設計的通用架構，并在此基礎上，進一步將系列產 品共用的模塊事先實現，供直接重用；將架構用框架的形式予以實現，供定制使用。這就是 通常所說的“平臺”。

產品線架構較之單個產品架構，有如下三點特別之處： （1）產品線架構必須考慮一系列明確許可的變化； （2）產品線架構一定要文檔化； （3）產品線架構必須提供“產品創建者指南”（開發指南），描述架構的實例化過程。

產品線的軟件架構應將不變的方面提出來（正因為有不變，才產生了產品線），同時，識別允許的變化，并提供實現它們的機制。通常應考慮三個方面。 （1）確定變化點：確定變化是一項需要持續進行的活動，可以在開發過程的任何時間確定變化。 （2）支持變化點：對變化的支持可以有多種形式，舉例如下。包含或省略元素：如條件編譯。包含不同數量的復制元素：如通過添加更多的服務器產生高容量的變體。具有相同的接口但具有不同的行為或質量特性的元素版本的選擇：如靜態庫和動態鏈接庫的使用。在面向對象的系統中，通過特化或泛化特定的類實現變化。通過參數配置來實現變化。 （3）對產品線架構的適宜性進行評估。 評估的內容：必須把評估的重點放在變化點上，以確保它（變化點）提供了足夠的靈活性，從而能復蓋產品線的預期范圍；它們支持快速構建產品。 評估的時間：應該對用于構建產品線中的一個或多個產品的架構的實例或變體進行評估。產品架構評估的結果通常能提供有用的反饋，推動架構的改進。當提議開發的一個新產品不在最初的產品線的范圍內時，則可以重新對產品線架構進行評估，看如何使其容納新的產品或是否有必要產生一個新的產品線。

3 產品線的開發模型

開發（確定）產品線的方法有兩種模型： （1） “ 前瞻性 ” 產品線：利用在應用領域的經驗 、 對市場和技術發展趨勢的了解及商業判斷力等進行產品線設計，它反映了企業的戰略決策。通常是自上而下地采用產品線方法。 （2） “ 反應性 ” 模型：企業根據以前的產品構建產品家族，并隨著新產品的開發，擴展架構和設計方案，它的核心資產庫是根據 “ 已經證明 ” 為共有 、 而非 “ 預先計劃 ” 為共有的元素構建的。通常是自下而上地采用產品線方法。

一旦確定了產品線，就進入其演變階段，它是產品線不斷向前的發展過程。

4 特定領域軟件架構

架構的本質在于其抽象性。它包括兩個方面的抽象：業務抽象和技術抽象。其中業務抽象面向特定的應用領域。

特定領域軟件架構（ Domain Specific Software Architecture ， DSSA ）可以看做開發產品線的一個方法（或理論），它的目標就是支持在一個特定領域中有多個應用的生成。

DSSA 的必備特征有： （1）一個嚴格定義的問題域或解決域； （2）具有普遍性，使其可以用于領域中某個特定應用的開發； （3）對整個領域的合適程度的抽象； （4）具備該領域固定的 、 典型的在開發過程中的可復用元素。

從功能復蓋的范圍角度理解 DSSA 中領域的含義有兩種方法： （1）垂直域。定義了一個特定的系統族，導出在該領域中可作為系統的可行解決方案的一個通用軟件架構。（2）水平域。定義了在多個系統和多個系統族中功能區域的共有部分，在子系統級上涵蓋多個系統（族）的特定部分功能。

DSSA 的活動階段如下。 （1）領域分析：主要目標是獲得領域模型。即通過分析領域中系統的需求（領域需求），確定哪些需求是被領域中的系統廣泛共享的，從而建立領域模型。 （2）領域設計：這個階段的目標是獲得 DSSA ，它是一個能夠適應領域多個系統的需求的一個高層次的設計。由于領域模型中的領域需求具有一定的變化性， DSSA 也要相應地具有變化性，它可以通過表示多選一的 、 可選的解決方案等來做到這一點。 （3）領域實現：主要目標是依據領域模型和 DSSA 開發與組織可復用信息。這些復用信息可以是從現有系統中提取得到的，也可能通過新的開發得到。這個階段可以看作復用基礎設施的實現階段。在上述工作中，獲得領域模型是基礎也是關鍵，領域建模專注于分析問題領域本身，發掘重要的業務領域概念，并建立業務領域概念之間的關系。通常領域模型可用 UML 的類圖和狀態圖表示。

領域模型的主要作用如下： （1）領域模型為需求定義了領域知識和領域詞匯，這較之單一的項目需求更有較好的大局觀； （2）軟件界面的設計往往和領域模型關系密切； （3）領域模型的合理性將嚴重影響軟件系統的可擴展性； （4）在分層架構的指導下，領域模型精化后即成為業務層的骨架； （5）領域模型也是其數據模型的基礎； （6）領域模型是團隊交流的基礎，因為它規定了重要的領域詞匯表，并且這些詞匯的定義是嚴格的 、 大家共同認可的。

5 架構及系統演化

架構雖然為系統的變化提供了一定的自由度，但是系統的較大變化必然導致架構的改變。架構（系統）演化是指向既定的方向 、 可控地改變。架構（系統）演化可以形成產品線，反過來，架構（系統）可以在規劃的產品線中進行演化。

架構（系統）演化過程包含7個步驟，如圖 1 所示。 （1）需求變動歸類。首先，必須對用戶需求的變化進行歸類，使變化的需求與已有構件對應。對找不到對應構件的變動，也要做好標記，在后續工作中，將創建新的構件，以對應這部分變化的需求。 （2）制訂架構演化計劃。在改變原有結構之前，開發組織必須制訂一個周密的架構演化計劃，作為后續演化開發工作的指南。 （3）修改 、 增加或刪除構件。在演化計劃的基礎上，開發人員可根據在第（1）步得到的需求變動的歸類情況，決定是否修改或刪除存在的構件 、 增加新構件。最后，對修改和增加的構件進行功能性測試。 （4）更新構件的相互作用。隨著構件的增加 、 刪除和修改，構件之間的控制流必須得到更新。 （5）構件組裝與測試。通過組裝支持工具把這些構件的實現體組裝起來，完成整個軟件系統的連接與合成，形成新的架構。然后，對組裝后的系統整體功能和性能進行測試。 （6）技術評審。對以上步驟進行確認，進行技術評審。評審組裝后的架構是否反映需求變動，符合用戶需求。如果不符合，則需要在第（2）到第（6）步之間進行迭代。 （7）產生演化后的架構。在原來系統上所作的所有修改必須集成到原來的架構中，完 成一次演化過程。