DSSA特定領域軟件體系結構

1、何爲DSSA

特定領域軟件架構（Domain Specific Software Architecture，DSSA）是一種有效實現特定領域軟件重用的手段。簡單地說，DSSA就是在一個特定應用領域爲一組應用提供組織結構參考的標準軟件體系結構。按照Tracz的說法，DSSA就是一個特定的問題領域中由領域模型、參考需求、參考架構等組成的開發基礎架構，其目標就是支持一個特定領域中多個應用的生成。特定領域軟件架構能夠看做開發產品線的一個方法或理論，它的目標就是支持在一個特定領域中有多個應用的生成。

 

2、DSSA與體系結構之間有何關聯？

一、DSSA是以問題域爲出發點，而軟件體系結構是以解決域爲出發點的；

二、DSSA只對某一個領域進行設計專家知識的提取、存儲和組織，但能夠同時使用多種體系結構風格；而在某個體系結構風格中進行體系結構專家知識的組織時能夠擴展到多個應用領域；

三、DSSA的特定領域參考體系結構一般選一個或多個體繫結構風格，並設計一個專用的體系結構分析設計工具；

四、體系結構風格的定義和應用領域是直交的，提取的設計知識比用DSSA提取的設計專家知識的應用要普遍。

 

3、DSSA的特徵

（1）一個嚴格定義的問題域和問題解域。

（2）具備廣泛性。使其能夠用於領域中某個特定應用的開發。

（3）對整個領域的構件組織模型的恰當抽象。

（4）具有該領域固定的、典型的在開發過程當中可重用元素。

 

4、DSSA領域的含義

從功能覆蓋的範圍角度一般有兩種理解DSSA中領域的含義的方式。

（1）垂直域：定義了一個特定的系統族，包含整個系統族內的多個系統，結果是在該領域中可做爲系統的可行解決方案的一個通用軟件體系結構。

（2）水平域：定義了在多個系統和多個系統族中功能區域的共有部分。在子系統級上涵蓋多個系統族的特定部分功能。

在垂直域上定義的DSSA只能應用於一個成熟的、穩定的領域，但這個條件比較難以知足：若將領域分割成較小的範圍，則更相對容易，也容易獲得一個一致的解決方案。

 

5、DSSA的基本活動

實施DSSA的過程當中包含了一些基本的活動。雖然具體的DSSA方法可能定義不一樣的概念、步驟和產品等，但這些基本活動大致上是一致的。

 

1．領域分析

 

這個階段的主要目標是得到領域模型。領域模型描述領域中系統之間的共同的需求，即領域模型所描述的需求爲領域需求。在這個階段中首先要進行一些準備性的活動，包括定義領域的邊界。從而明確分析的對象；識別信息源，整個領域工程過程當中信息的來源，可能的信息源包括現存系統、技術文獻、問題域和系統開發的專家、用戶調查和市場分析、領域演化的歷史記錄等，在此基礎上就能夠分析領域中系統的需求，肯定哪些需求是領域中的系統普遍共享的，從而創建領域模型。當領域中存在大量系統時，須要選擇它們的一個子集做爲樣本系統。對樣本系統需求的考察將顯示領域需求的一個變化範圍。一些需求對全部被考察的系統是共同的，一些需求是單個系統所獨有的。不少需求位於這兩個極端之間，即被部分系統共享。

 

2．領域設計

 

這個階段的目標是得到DSSA。DSSA描述在領域模型中表示的需求的解決方案，它不是單個系統的表示，而是可以適應領域中多個系統的需求的一個高層次的設計。創建了領域模型以後，就能夠派生出知足這些被建模的領域需求的DSSA，因爲領域模型中的領域需求具備必定的變化性，DSSA也要相應地具備變化性。它能夠經過表示多選一的（alternative）、可選的（optional）解決方案等來作到這一點。模型和DSSA來組織的，所以在這個階段經過得到DSSA，也就同時造成了重用基礎設施的規約。

 

3．領域實現

 

這個階段的主要目標是依據領域模型和DSSA開發和組織可重用信息。這些可重用信息多是從現有系統中提取獲得，也可能須要經過新的開發獲得。它們依據領域模型和DSSA進行組織，也就是領域模型和DSSA定義了這些可重用信息的重用時機，從而支持了系統化的軟件重用。這個階段也能夠看做重用基礎設施的實現階段。

 

值得注意的是，以上過程是一個反覆的、逐漸求精的過程。在實施領域工程的每一個階段中，均可能返回到之前的步驟，對之前的步驟獲得的結果進行修改和完善，再回到當前步驟，在新的基礎上進行本階段的活動。

 

6、參與DSSA的人員

 

參與DSSA的人員能夠劃分爲4種角色：領域專家、領域分析師、領域設計人員和領域實現人員。

 

1．領域專家

 

領域專家可能包括該領域中系統的有經驗的用戶、從事該領域中系統的需求分析、設計、實現以及項目管理的有經驗的軟件工程師等。領域專家的主要任務包括提供關於領域中系統的需求規約和實現的知識，幫助組織規範的、一致的領域字典，幫助選擇樣本系統做爲領域工程的依據，複審領域模型、DSSA等領域工程產品等。領域專家應該熟悉該領域中系統的軟件設計和實現、硬件限制、將來的用戶需求及技術走向等。

 

2．領域分析人員

 

領域分析人員應由具備知識工程背景的有經驗的系統分析員來擔任。領域分析人員的主要任務包括控制整個領域分析過程，進行知識獲取，將獲取的知識組織到領域模型中，根據現有系統、標準規範等驗證領域模型的準確性和一致性，維護領域模型。領域分析人員應熟悉軟件重用和領域分析方法；熟悉進行知識獲取和知識表示所需的技術、語言和工具；應具備必定的該領域的經驗，以便於分析領域中的問題及與領域專家進行交互；應具備較高的進行抽象、關聯和類比的能力；應具備較高的與他人交互和合做的能力。

 

3．領域設計人員

 

領域設計人員應由有經驗的軟件設計人員來擔任。領域設計人員的主要任務包括控制核個軟件設計過程，根據領域模型和現有的系統開發出DSSA，對DSSA的準確性和一致性進行驗證，創建領域模型和DSSA之間的聯繫。領域設計人員應熟悉軟件重用和領域設計方法；熟悉軟件設計方法；應有必定的該領域的經驗，以便於分析領域中的問題及與領域專家進行交互。

 

4．領域實現人員

 

領域實現人員應由有經驗的程序設計人員來擔任。領域實現人員的主要任務包括根據領域模型和DSSA，或者從頭開發可重用構件，或者利用再工程的技術從現有系統中提取可重用構件，對可重用構件進行驗證，創建DSSA與可重用構件間的聯繫。領域實現人員應熟悉軟件重用、領域實現及軟件再工程技術；熟悉程序設計；具備必定的該領域的經驗。

 

7、DSSA的創建過程

 

因所在的領域不一樣，DSSA的建立和使用過程也各有差別，Tract曾提出了一個通用的DSSA應用過程，這些過程也須要根據所應用到的領域來進行調整。通常狀況下，須要用所應用領域的應用開發者習慣使用的工具和方法來創建DSSA模型。同時Tracz強調了DSSA參考體系結構文檔工做的重要性。由於新應用的開發和對現有應用的維護都要以此爲基礎。

 

DSSA的創建過程分爲5個階段，每一個階段能夠進一步劃分爲一些步驟或子階段。每一個階段包括一組須要回答的問題，一組須要的輸入，一組將產生的輸出和驗證標準。本過程是併發的（concurrent）、遞歸的（recursive）、反覆的（iterative）。或者能夠說，它是螺旋模型（spiral）。完成本過程可能須要對每一個階段經歷幾遍，每次增長更多的細節。

 

（1）定義領域範圍。本階段的重點是肯定什麼在感興趣的領域中以及本過程到什麼時候結束。這個階段的一個主要輸出是領域中的應用須要知足一系列用戶的需求。

 

（2）定義領域特定的元素：本階段的目標是編譯領域字典和領域術語的同義詞詞典。在領域工程過程的前一個階段產生的高層塊圈將被增長更多的細節，特別是識別領域中應用間的共同性和差別性。

 

（3）定義領域特定的設計和實現需求約束：本階段的目標是描述解空間中有差異的特性。不只要識別出約束，而且要記錄約束對設設計和實現決定形成的後果，還要記錄對處理這些問題時產生的全部問題的討論。

 

（4）定義領域模型和體系結構：本階段的目標是產生通常的體系結構，並說明構成它們的模塊或構件的語法和語義。

 

（5）產生，蒐集可重用的產品單元：本階段的目標是爲DSSA增長構件，使它能夠被用來產生問題域中的新應用。

 

DSSA的創建過程是併發的、遞歸的和反覆進行的。該過程的目的是將用戶的須要映射爲基於實現限制集合的軟件需求，這些需求定義了DSSA。在此以前的領域工程和領域分析過程並無對系統的功能性需求和實現限制進行區分，而是統稱爲「需求」。

 

DSSA三個層次的系統模型