準則: 軟體架構文件
這個準則提供軟體架構文件內容的概觀。
關係
主要說明

參照

參照區段提供若干外部文件,協助您取得在瞭解系統架構時非常重要的背景資訊。如果參考資料很多,便會分成幾個子區段:

  1. 外部文件
  2. 內部文件
  3. 政府文件
  4. 非政府文件
  5. 其他。

架構目標和限制

架構是經由下列考量而形成:

  • 功能需求,擷取在使用案例模型中
  • 非功能需求,擷取在增補規格中

不過,使結構成形的力量並不只這些:軟體的操作環境、重複使用現有資產的需要、各種標準的施行,以及相容於現有系統的需要等,都會強加一些限制。也可能有一組事先存在的架構原理和原則,可以用來引導開發工作,但必須根據專案來詳述和驗證。 軟體架構文件的這一節會說明這些目標和限制,以及它們所產生而尚未在他處找到現成位置(如同需求)的任何架構決策。 

當建立這份文件時,實作環境的規格是一項重要輸入。目標平台(硬體、作業系統)、視窗系統、開發工具(語言、GUI 建置器)、資料庫管理系統以及元件庫等,都是應該指定的事物範例。可用和不可用的使用者介面技術,也是非常適合指定的項目。許多系統都會選擇不使用特定呈現技術(JavaScript、Applet、Frame、XML 等),讓更多用戶端系統能夠使用應用程式,或選擇使應用程式更容易開發。這些決策會記錄在「軟體架構文件」中,至於如何使用和套用選定的技術,則在 工作成果:特定專案準則中詳細說明。

這些決策的實施是藉由設計一組架構評估準則來完成,評量反覆時會用到這些準則。

評估準則也是從變更案例衍生而來,變更案例用來說明下列項目未來可能出現的變更:

  • 系統的功能和內容
  • 系統的使用方式
  • 系統的操作和支援環境

變更案例會釐清「很容易延伸」、「很容易移轉」、「很容易維護」、「面對變更很健全」和「開發很快」等主觀用語所說明的系統內容。變更案例的焦點在於,重要而可能的是什麼,而不只在於什麼是可能的。

變更案例嘗試預測變更:這些預測很少兌現。

系統的內容由使用者、贊助者、供應商、開發人員和其他關係人來決定。變更有許多來源,例如:

  • 商業驅動:新的和修改過的商業流程和目標
  • 技術驅動:調整系統使用新平台、整合新元件
  • 一般使用者的設定檔變更
  • 與其他系統之整合需求的變更
  • 因從外部系統移轉功能而產生的範圍變更

使用案例視圖

使用案例視圖提供工作成果:使用案例模型的子集來呈現系統含架構重要性的使用案例。它說明一組代表某些重要核心功能的情境和/或使用案例。另外,它也說明一組含有重要架構涵蓋面(處理許多架構元素)或強調或闡明架構的特定精巧要點的情境和/或使用案例。

如果模型比較大,通常會組織成套件;若是如此,為了便於瞭解,使用案例視圖也應該依照套件來組織。每個重要使用案例都要有包含下列資訊的子區段:

  1. 使用案例名稱。
  2. 使用案例的簡要說明。
  3. 使用案例事件流程的重要說明。這可能是整個事件流程說明,也可能是說明使用案例重要流程或情境的子區段。
  4. 包括使用案例之關係的重要說明,如併入關係和延伸關係,或通訊關聯。
  5. 與使用案例相關的重要使用案例圖的列舉。
  6. 使用案例之特殊需求的重要說明。這可能是整個特殊需求說明,也可能是說明重要需求的子區段。
  7. 釐清使用案例的重要使用者介面圖
  8. 邏輯視圖中應該有這些使用案例的實現化。

邏輯視圖

邏輯視圖是工作成果:設計模型的子集,用來呈現含架構重要性的設計元素。它會說明最重要的類別、它們的套件和子系統組織,以及這些套件和子系統在各層中的組織。它也會說明最重要的使用案例實現化,例如,架構的各個動態方面。

複雜系統可能需要利用幾個區段來說明邏輯視圖:

  1. 概觀

    本小節透過設計模型的套件階層和層次來說明設計模型整體的分解。如果系統有許多層次的套件,您應該先說明在最上層的重要套件。請併入任何顯示最上層重要套件及其相依性和分層的圖解。之後,請呈現這些圖解內的任何重要套件,並進行到在階層低端的重要套件。

  2. 含架構重要性的設計套件

    每個重要套件都要有包含下列資訊的子區段

    1. 它的名稱。
    2. 簡要說明。
    3. 含有套件所包含的所有重要類別和套件的圖解。如果要更深入瞭解,必要的話,這個圖也可以顯示其他套件的類別。
    4. 對於套件中的每個重要類別,請併入它的名稱和簡要說明,再選擇性地併入它的某些主要責任、作業和屬性的說明。另外,如果需要瞭解併入的圖解,您也要說明它的重要關係。
  3. 使用案例實現化

    本節提供所選取的少量使用案例(或情境)實現化來說明軟體的運作方式,同時也說明各種設計模型元素如何提供它們的功能。這裡所提供的實現化,是因為它們代表最終系統的某些重要核心功能而獲選;或對於它們的結構涵蓋面而言,它們處理了許多架構元素,或強調或說明了架構的特定精巧要點。這些實現化的對應使用案例和情境,應該可以在使用案例視圖中找到。

    每個重要使用案例實現化都要有包含下列資訊的子區段

    1. 已實現化之使用案例的名稱。
    2. 已實現化之使用案例的簡要說明。
    3. 使用案例實現化之事件流程 - 設計的重要說明。這可能是整個事件流程 - 設計說明,也可能是說明使用案例重要流程或情境之實現化的子區段。
    4. 與使用案例實現化相關重要互動或類別圖的列舉。
    5. 使用案例實現化之衍生需求的重要說明。這可能是整個衍生需求說明,也可能是說明重要需求的子區段。

含架構重要性的設計元素

為了協助您決定什麼是含架構重要性,這裡提供了一些限定元素及其特性的範例:

  • 封裝了問題領域主要摘要的模型元素,例如:
    • 空中交通管制系統中的航班計劃。
    • 薪資系統中的員工。
    • 電話系統中的訂閱者。

這些的子類型不必然應該併入,例如,ICAO 標準航班計劃美國國內航班計劃的區分並不重要;它們都是航班計劃,共用大量的屬性和作業。

用資料線路或語音線路來區分訂閱者並不重要,只要呼叫的處理大體上依照相同方式進行即可。

  • 許多其他模型元素所用的模型元素。
  • 封裝了系統主要機制(服務)的模型元素
  • 設計機制
    • 持續性機制(儲存庫、資料庫、記憶體管理)。
    • 通訊機制(RPC、播送、分配管理系統服務)。
    • 錯誤處理或回復機制。
    • 顯示機制和其他共用介面(視窗、資料擷取、信號調整等)。
    • 參數化機制。

一般而言,任何機制都可能供許多不同套件使用(相對於專供單一套件內部使用),在這方面,使整個系統採用單一共用實作是恰當的,至少要用單一介面來隱藏許多實作選擇方案。

  • 利用諸如下列方式來參與系統主要介面的模型元素:
    • 作業系統。
    • 現成產品(視窗系統、RDBMS、地理資訊系統)。
    • 實作和支援架構型樣(例如將模型元素解除耦合的型樣,其中包括模型視圖控制器型樣,或分配管理系統型樣)的類別。
  • 具備本端可見度,但可能嚴重影響系統整體效能的模型元素,例如:
    • 以很高的速率來掃描感應器的輪詢機制。
    • 疑難排解的追蹤機制。
    • 高可用性系統的核對點機制(核對點和性能原則)。
    • 啟動序列。
    • 程式碼線上更新。
    • 封裝了含技術風險之新演算法或具有各種安全關鍵性之演算法(如幅射層次的計算、壅塞領空飛機避撞準則、密碼加密)的類別。

在專案早期反覆中,隨著技術困難的發現以及開始更深入瞭解系統,含架構重要性的準則也會跟著發展。不過,作為一項規則,您應該將最多 10% 的模型元素標示為「含架構重要性」。否則,您會承受架構概念弱化的風險,結果「什麼東西都是架構」。

當您在邏輯視圖中定義和併入含架構重要性的模型元素時,您也應該將下列方面列入考慮。

  • 識別共用和重複使用的可能性。哪些類別可以是共用類別的子類別,或相同參數化類別的實例?
  • 識別參數化的可能性。設計的哪些部分可以利用靜態和執行時期參數(如表格驅動的行為,或啟動時載入的資源資料)而成為更容易重複使用或更有彈性?
  • 識別使用現成產品的可能性。

流程視圖

流程視圖說明系統的流程結構。由於流程結構對架構的影響很大,因此,應該呈現所有流程。在流程內,只需要呈現含架構重要性的輕型執行緒。流程視圖用來說明執行系統時所涉及的作業(流程和執行緒)、作業的互動和配置,以及作業的物件和類別配置。

每個流程網路都要有包含下列資訊的子區段:

  1. 它的名稱。
  2. 所包含的流程。
  3. 程序之間的互動,以通訊圖的形式來表達,其中物件是包含了自己的控制執行緒的實際流程。 請簡要說明每個流程的行為、生命期限和通訊特性。

部署視圖

本節說明在其中部署和執行軟體的一或多個實體網路(硬體)配置。 它也說明將作業(從流程視圖)配置到實體節點。每個實體網路配置都要有包含下列資訊的子區段:

  1. 它的名稱。
  2. 說明配置的部署圖,後面接著將各個流程對映到每個處理器。
  3. 如果有許多可能的實體配置,只要說明一個典型配置,之後,再說明定義其他配置時所遵循的一般對映規則。另外,在大部分情況下,您也應該併入執行軟體測試和模擬之網路配置的說明。

這個視圖是工作成果:部署模型所產生的。

實作視圖

本節說明在實作模型中,將軟體分解成各個層次及實作子系統。另外,它也提供(從邏輯視圖中)將設計元素配置給實作的概觀。它包含兩小節:

  1. 概觀

    本小節命名和定義各個層次及其內容、控管併入給定層次的規則,以及各層次之間的界限。其中包括一個顯示層次關係的元件圖。

  2. 層次

    每個層次都要有包含下列資訊的子區段:

    1. 它的名稱。
    2. 顯示實作子系統及其匯入相依性的元件圖。
    3. 層次與邏輯或流程視圖元素的關係概要(適當的話)。
    4. 層次中實作子系統的列舉。對於每個實作子系統,請執行下列動作:
      • 提供它的名稱、縮寫或暱稱、簡要說明,以及存在的理由;
      • 適當的話,請指出實作子系統與邏輯或流程視圖元素的關係。在許多情況下,實作子系統都會實作邏輯視圖中的一或多個設計子系統。
      • 如果實作子系統包括含架構重要性的實作子系統和/或
        目錄,請考慮在子區段階層反映這個情況。
      • 如果實作子系統與實作目錄沒有一對一的對映關係,請併入如何透過實作目錄和/或檔案來定義實作子系統的說明。

資料視圖

這個視圖只與涉及資料庫支援的持續性之系統相關。它用來說明資料模型中含架構重要性的持續性元素。它會透過向系統提供持續性的表格、概略表、索引、觸發程式和儲存程序來概述資料模型及其組織。它也會說明持續性類別(從邏輯視圖)到資料庫資料結構的對映

它通常包含:

  • 以主要持續性設計類別為起點的對映,當對映並非無關緊要時,尤其如此。
  • 在資料庫中,以儲存程序和觸發程式的形式來實作的含架構重要性的系統組件。
  • 在其他系統中,可能會有資料連帶作用的重要決策,如對於交易策略、分送、並行、容錯等的選擇。比方說,如果選擇使用以資料庫為基礎的交易管理(依賴資料庫來確定或捨棄交易),則架構中用來處理錯誤的機制,必須併入藉由重新整理應用程式記憶體中快取持續性物件的狀態來回復失敗交易的策略。

您應該提供含架構重要性的資料模型元素,說明它們的責任,以及少數非常重要的關係和行為(觸發程式、儲存程序等)。

大小和效能

本節說明系統用來進行架構定義的容積和回應特性。提供的資訊可能包括:

  • 系統需要處理的主要元素數目(如空中交通管制系統的並行航班數目、電信交換機的並行電話數目、航空訂位系統並行線上使用者的數目等)。
  • 系統的主要效能測量,如主要事件的平均回應時間;最大傳輸率、最小傳輸率和平均傳輸率等。
  • 可執行程式的覆蓋區(磁碟和記憶體)- 如果系統是必須在很狹窄的限制內存活的內嵌系統,便非常重要。

這些品質大部分都會擷取成各項需求;在這裡提出它們是因為它們以重要方式形成架構,且證明特殊焦點是合理的。對於每一項需求,請討論架構支援這項需求的方式。

品質

這個區段列出形成架構的系統主要品質維度。提供的資訊可能包括:

  • 作業效能需求,如平均失敗時間 (MTBF)。
  • 品質目標,如「無非排程當機時間」
  • 延伸目標,如「當系統在執行中,軟體可以升級」。
  • 可攜性目標,如硬體平台、作業系統、語言。

對於每一個維度,請討論架構支援這項需求的方式。您可以依不同的視圖(邏輯、實作等)或品質來組織這個區段。當系統中的特定特性很重要時,如安全或私密性,應該在這個區段小心描述它們的架構支援。