工作成果: Reference Architecture
這個工作成果基本上是一個預先定義的架構型樣,或是一組型樣,可能已部份或完全實例化, 經過設計與實證可用於特定的企業及技術環境,與支援的構件一起合用。
目的

「參照架構」工作成果為組織可重複使用的資料庫的一部份。其目的為形成架構開發的起始點。可能的範圍從現成的架構型樣架構機制組織架構,至具有已知特性,受使用肯定的完整系統。這些可能適用於一般狀況,或適用於橫跨領域的廣泛系統類別,或具有較狹隘、領域特定的焦點。

使用已測試參照架構對提出許多非功能性需求(特別是品質需求)來說,是很有效率的,只需選擇現有已知能滿足這些需求的參照架構。「參照架構」可能存在或用於不同的摘要層次,並且來自不同的觀點。這些對應於「4+1 視圖」(請參閱「典型的架構視圖集」)。這麼做的話,軟體架構師可以選取最適合的架構設計,或設計與實作,以適用於不同的完成度。 

通常,「參照架構」定義成不包括用來建構系統的元件實例(如果它未成為產品線架構的話),但這不是一個嚴格且快速的區分。在 Rational Unified Process (RUP) 中,我們容許「參照架構」概念中包含對現有、可重複使用的元件(也就是實作)之參照。

關係
角色負責: 修改者:
說明
概略輪廓

資產組織

擁有「參照架構」的組織需要決定對資產進行分類的方法,並為新系統依照軟體架構、依照相符的選擇準則進行組織,以便擷取。雖然「參照架構」的建立與儲存目前不在 RUP 的範圍內,建議您依照領域(其中的領域是一個主題區,為系統的某些方面,或系統系列定義知識及概念)中的概念來進行組織。在這裡我們對「領域」這個術語的定義是在應用程式之下的階層。這個用法與部份定義稍有不同(例如在 [HOF99] 中所示的),但與 [LMFS96] 中所示相符:

產品線領域:一組相互綁定的功能(現在或未來),定義來協助溝通、分析以及工程,以識別、設計及管理橫跨整個產品線的共通性。這樣的領域可能包含緊密相關的一般使用者系統群組、跨多個系統共用的功能,或廣泛通用的基本服務分組。」

這個定義中包含了一個概念,也就是用來組成系統的事物可能本身所屬的領域就值得加以研究。下圖(來自 [LMFS96])說明了這個原則。

水平及垂直的美國陸軍領域

美國陸軍的水平及垂直領域

此圖例顯示主要系統系列、「資訊系統」、「指令與控制」,以及「武器系統」,每一個系統皆有部份完全包含的垂直領域,以及與垂直領域及系統系列交錯的水平領域。因此,「即時排程」概念適用於「指令與控制策略領域」,以及所有「武器系統」的垂直領域。所以,若要為所有領域一次解決即時排程問題,並處理知識和資產以開發成個別的領域,之後這個領域會關聯至 例如「電子戰 (Electronic Warfare)」,但不會關聯至「個人資訊系統」。

內容

「參照架構」具有與工作成果:軟體架構文件相同的格式,以及所關聯的模型,分解專案特定參照, 或使專案參照及特性成為通用,好讓「參照架構」能在資產基礎中適當分類。與「軟體架構文件 (SAD)」相關的一般模型為「使用案例模型」、「實作模型」以及「部署模型」。

存取 SAD 和相關模型提供了軟體架構師幾個進入點,軟體架構師可選擇僅使用架構的概念或邏輯部份(如果組織的重複使用原則容許的話)。在其他的極端作法中,能夠從資產基礎完整工作子系統,以及實體層次的「部署模型」(也就是完整的硬體及網路藍圖)取得軟體架構。

需要其他支援工作成果使架構資產成為可用。 

  1. 「使用案例模型」說明了架構的行為,但軟體架構師還需要瞭解其非功能性的品質。這兩項(「使用案例模型」和非功能性的需求)可能先前在「軟體需求規格」中已被擷取。從這裡,軟體架構師將可以判斷「參照架構」與現行需求相符的程度。

  2. 架構的使用,更特定來說,是架構的修改,將需要與原始開發相同的指引。例如,軟體架構師將需要瞭解「參照架構」形成時所套用的規則,以及修改介面的困難度。存取與「參照架構」相關的設計準則可以協助回答這些問題。

  3. (選用)複查任何相關的現有「測試計劃」也有所幫助。這些「測試計劃」將會通知架構師有關先前用來測試類似架構的測試及評估,這樣也會提供對架構中可能的弱點的洞察力。

  4. (選用)複查任何相關的現有「測試自動化架構」和「測試介面規格」也有所幫助。這些工作成果會通知架構師有關組成架構以協助測試的可能要求。

主要說明

資產組織

擁有「參照架構」的組織需要決定對資產進行分類的方法,並為新系統依照軟體架構、依照相符的選擇準則進行組織,以便擷取。雖然「參照架構」的建立與儲存目前不在 RUP 的範圍內,建議您依照術語 定義:領域(其中的領域是一個主題區,為系統的某些方面,或系統系列定義知識及 概念)中的概念來進行組織。在這裡我們對「領域」這個術語的定義是在應用程式之下的階層。這個用法與部份定義稍有不同(例如在 [HOF99] 中所示的),但與 [LMFS96] 中所示相符:

產品線領域:一組相互綁定的功能(現在或未來),定義來協助溝通、分析以及工程,以識別、設計及管理橫跨整個產品線的共通性。這樣的領域可能包含緊密相關的一般使用者系統群組、跨多個系統共用的功能,或廣泛通用的基本服務分組。」

這個定義中包含了一個概念,也就是用來組成系統的事物可能本身所屬的領域就值得加以研究。下圖(來自 [LMFS96])說明了這個原則。

美國陸軍的水平及垂直領域

美國陸軍的水平及垂直領域

此圖例顯示主要系統系列、「資訊系統」、「指令與控制」,以及「武器系統」,每一個系統皆有部份完全包含的垂直領域,以及與垂直領域及系統系列交錯的水平領域。因此,「即時排程」概念適用於「指令與控制策略領域」,以及所有「武器系統」的垂直領域。所以,若要為所有領域一次解決即時排程問題,並處理知識和資產以開發成個別的領域,之後這個領域會關聯至 例如「電子戰 (Electronic Warfare)」,但不會關聯至「個人資訊系統」。

內容

「參照架構」具有與工作成果:軟體架構文件相同的格式,以及所關聯的模型,分解專案特定參照, 或使專案參照及特性成為通用,好讓「參照架構」能在資產基礎中適當分類。與「軟體架構文件 (SAD)」相關的一般模型為「使用案例模型」、「實作模型」以及「部署模型」。

存取 SAD 和相關模型提供了軟體架構師幾個進入點,軟體架構師可選擇僅使用架構的概念或邏輯部份(如果組織的重複使用原則容許的話)。在其他的極端作法中,能夠從資產基礎完整工作子系統,以及實體層次的「部署模型」(也就是完整的硬體及網路藍圖)取得軟體架構。

需要其他支援構件使架構資產成為可用。 

  1. 「使用案例模型」說明了架構的行為,但軟體架構師還需要瞭解其非功能性的品質。這兩項(「使用案例模型」和非功能性的需求)可能先前在「軟體需求規格」中已被擷取。從這裡,軟體架構師將可以判斷「參照架構」與現行需求相符的程度。

  2. 架構的使用,更特定來說,是架構的修改,將需要與原始開發相同的指引。例如,軟體架構師將需要瞭解「參照架構」形成時所套用的規則,以及修改介面的困難度。存取與「參照架構」相關的設計準則可以協助回答這些問題。

  3. (選用)複查任何相關的現有「測試計劃」也有所幫助。這些「測試計劃」將會通知架構師有關先前用來測試類似架構的測試及評估,這樣也會提供對架構中可能的弱點的洞察力。

  4. (選用)複查任何相關的現有「測試自動化架構」和「測試介面規格」也有所幫助。這些構件會通知架構師有關組成架構以協助測試的可能要求。

內容
選用
規劃Yes
調整
表示法選項UML 表示法:數個相關架構視圖:「使用案例」、「邏輯」、「流程」、「部署」、「實作」、「資料」。

除非系統是完全無先例的,否則應檢查「參照架構」對領域及開發類型的適用性,看看這些「參照架構」是否存在,以及是否可被開發組織所存取。「參照架構」的建立是一個應在組織層次中提出的問題。削減以上的內容清單,但仍能達成架構重複使用的部份好處是可能的。例如,雖然在架構修改時,需要重寫測試,但仍可以省略測試模型。最少,可能期望有一個設計模型,以及一些相關的行為說明(可能是「使用案例模型」)。少於這點的話,就難以把該資產稱為「參照架構」。但這仍可為一個有效的型樣。