作業: 架構分析
這項作業的宗旨是定義候選的架構以及要在系統中使用架構技術。
規範: 分析 設計
目的
  • 依據從類似的系統或類似的問題領域獲得的經驗,來定義系統的候選架構。
  • 定義系統的架構型樣、主要機制以及建立使用慣例模型。
關係
主要說明

架構分析的宗旨是定義候選的架構以及要在系統中使用架構技術。這項作業仰賴在類似的系統或問題領域中獲得的經驗,來限制及專注於架構,以避免浪費時間重新探查架構。在已經具有定義完備的架構之系統中,也許可以不用進行架構分析;架構分析在開發新的系統以及前所未有的系統時,最有價值。

步驟
開發架構概觀
目的  透過探查及評估高階的架構選項,來協助建構系統。 
向贊助人、開發團隊以及其他關係人傳達對屬意系統的高階結構之早期規劃。

架構概觀是在專案生命週期的早期時建立,很可能是在初始階段時就已經建立。架構概觀反映出對實作「願景」的早期決定與工作假設,以及關於實體架構與邏輯架構,和功能以外的系統需求決定。它通常是由軟體架構師和專案贊助人合作提出,並且其格式是較不正式的圖片分鏡腳本或圖畫式的圖形。基本上架構概觀旨在彰顯出提議的解決方案之必要本質、傳達主要創意並包括主要的建置區塊。架構概觀的格式層次,是依專案而定。例如,在大型且高度講究形式的專案中,很可能必須在「軟體架構」文件的適當章節中 提出架構概觀,以便能做正式審查。

這時,架構概觀就算是暫時性地首次通過。不過在可執行的架構原型驗證過包括設計、實作方式及部署考量在內等架構元素之前,請不要過度相信架構總覽圖的承諾。

請考慮參考架構、其他架構型樣或其他架構資產,來作為架構基礎。

考慮是否要修正及維護架構總覽圖,來作為溝通工具。

許多系統都受限於必須在現有的軟硬體環境中開發及部署;對於這種系統,軟體架構師就會收集關於現行環境的相關資訊。

例如,在電子商業系統開發中,下列是相關的資訊:

  • 現有的網路邏輯與實體設計
  • 現有的資料庫及資料庫設計
  • 現有的 Web 環境(伺服器、防火牆等等)
  • 現有的伺服器環境(配置、軟體版本、已規劃的更新)
  • 現有的標準(網路、命名、通訊協定)

這類資訊可以用文字形式取得,或是用部署模型

調查可用的資產
目的  指出可能會和專案有關的資產。
分析資產是否適用於專案需求。
決定是否要以資產作為系統的基礎。
找出及列出可以在專案中重複使用的資產。
執行初步的評估,以確保可以取得必要的支援。

您需要瞭解考慮要使用資產的環境需求,以及必要的系統範圍和一般功能。搜尋組織內的資產庫以及工業文件,找出資產或類似的專案。需要考慮的資產有多種類型,例如(但不限定於)工業模型、基礎架構、類別以及經驗等。您需要評估可用的資產是否有助於解決現行專案的主要挑戰,以及資產是否能和專案的限制相容。

您也需要分析資產和客戶需求之間的相容性,看看有哪些需求是可以協議的(以便能使用資產)。

請務必要評估資產是否可以修改或加以擴充,以滿足需求,以及採用資產所引起的成本、風險以及功能方面的缺點。

最後,在原則上,您需要決定是否要使用一或多個資產,並記錄做此決定的原因。

定義子系統的高階組織
目的 建立「設計模型」的起始結構。

在初始階段,主要重點是執行架構合成,但這項作業卻會排除這個步驟。

通常設計模型會組織為層次,這是建立大型系統的常見架構型樣。層數並不會有固定的數目,而是會隨著狀況而不同。

在架構分析期間,您通常會專注於兩個高階層次;也就是應用程式商業專有層次。這就是子系統高階組織代表的意思。其他低階層次則會涵蓋在作業:納入現有的設計元素中。如果您要使用特定的架構型樣,子系統就會根據該型樣的架構範本定義。

如需有關分層的詳細資訊,請參閱工作成果準則:分層

指出主要摘要
目的 指出系統必須處理的主要摘要(代表在若有建立商業模型作業期間以及需求作業期間指出的概念),供進行分析。

當專注於建立架構時,這個步驟會做到足以指引軟體架構師選擇用來建構工作成果:架構概念證明的資產,並支持代表性的使用情境。

需求作業以及若有進行「建立商業模型」作業時,通常會彰顯出系統必須能處理的主要概念;這些概念會將本身呈現為主要的設計摘要。由於這項工作已經做過了,因此在作業:使用案例分析期間,就不需要重複再做這項識別工作。

您可以利用現有的知識,來指出初步的實體分析類別,以對系統的一般知識作為基礎,例如「需求」、名詞解釋以及特別是如果您已經有領域模型商業分析模型存在的話,來呈現這些主要摘要。

當您定義主要摘要時,請同時定義存在實體類別之間的任何關係。將主要摘要呈現在一或多個類別圖中,並建立每個摘要的簡短說明。視領域以及系統的新舊程度,可能已經有分析型樣存在,可以用來擷取建立系統模型所需要的許多主要摘要。透過使用這類型樣(這類型樣應該都已經順利部署在領域中)可以大量減少指出必須呈現的重要概念之搜尋工作。 [FOW97a] 代表可以立即用來建立商業系統模型,但也可能可以用於其他環境定義的分析型樣。另一個範例是 Object Management Group (OMG),這個範例也是嘗試透過其「領域技術協會 (Domain Technology Committee)」的工作以及相關聯的工作小組,來定義多個領域的介面和通訊協定。無可避免的,這個工作會導向指出領域中的重要摘要。

在這個階段指出的分析類別在專案進行過程中,很可能會更改及衍變。因此這個步驟的目的並不是要指出在整個設計過程中會持續存在的一組類別,而是要指出系統必須處理的主要概念。在這個起始階段不要花費過多時間於詳細描述實體類別,因為使用案例並不一定真的需要使用您現在指出的類別和關係。請記得,當您在看使用案例時,將會找出更多實體類別和關係。

指出原型交互作用

只有在初始階段執行這項作業時才會加入這個步驟。

這個步驟的目的是要指出在系統內的主要摘要之間的交互作用,這些會將系統的重要活動分類,或作為其活動代表。這些交互作用會擷取作為「使用案例實現化」。

開發部署概觀

目的

提供用來評估系統實作是否可行的基準。
瞭解系統的地區分佈與作業複雜度。
提供早期投入作業及成本預估基準。

開發如何部署軟體的高階概觀。例如,判斷系統是否需要從遠端存取,或其需求是否指出分佈到多個節點。需要考慮的一些資訊來源如下:

  • 使用者設定檔(在願景中)以及使用案例(在「使用案例模型」中)定義的使用者(在各個位置)
  • 商業資料的組織方式(在可用的「商業分析模型」以及「設計模型」中)
  • 服務層次需求(在「增補規格」中)
  • 限制(在「增補規格」中,例如與舊版系統的介面需求)

如果需要非瑣碎的分散式系統,則可以使用「部署模型」來擷取節點之間的關係。這項關係應該要包括先前指定給節點的元件和資料,並指出使用者存取元件以存取資料的方式。節點及連線的詳細規格可以延後再定,除非必須有節點及連線規格才能預測或評估可行性時例外。如果有適當的現有資產可用,則可以使用現有的資產。雖然這是專案建立的第一個部署模型,並且是很快速建立的高階模型,但這個模型極可能會指出已知的實際軟硬體產品,或是在這個階段一定要確定這些軟硬體選擇。

檢驗部署模型不但可以支援使用者(尤是是需要從遠端位置進行存取的使用者) 執行一般的使用案例,同時也符合非功能方面的需求和限制。檢驗節點和連線足以支援位在不同節點上的各個元件之間的交互作用,以及元件和元件所儲存的資料之間的交互作用。

指出分析機制
目的 定義設計師用來賦予物件對象生命所用的分析機制和服務。

在初始階段,主要重點是執行架構合成,但這項作業卻會排除這個步驟。

分析機制可以是由上而下(具有先前的經驗)或由下而上(一面做一面找)。在由上而下的模式中,經驗讓軟體架構師瞭解領域中存在的特定問題,並且需要特定的解決方案。在分析期間,會呈現作為機制的一般性架構問題範例包括:持續性、交易管理、錯誤管理、傳訊以及推論引擎。所有這些架構元素的共同特徵,是每個架構元素 都是系統的一個一般性的廣泛類別功能,並且每個架構元素都會提供功能 來和基本應用程式功能互動,或支援基本應用程式功能。分析機制支援系統的基本功能需求所需要的功能,不論系統部署的平台或實作的語言為何。分析機制也可以用多種不同的方式設計和實作;一般而言,每種分析機制都會有多個相對應的設計機制,並且每種分析機制也可能會有多種實作方式。

由下而上方法是實際產生分析機制,分析機制會建立成軟體架構師從多個問題的一組解決方案所衍生的共同主題中,所看到的分析機制,一開始時,這個機制可能還很模糊。這裡需要提供一種方式,讓不同頭緒中的各個元素能將時鐘同步化,並且需要一種共同的方式來分配資源。用來將分析語言簡化的分析機制,就是從這些型樣中洐生出來的。

指出分析機制表示您指出有共同的,但可能是隱含的次問題(系統的需求暗示這一點)存在,並且您加以命名。開始時,名稱可能是所有存在的問題,例如「軟體架構師認為系統需要一項持續性機制」。最後這個機制會透過合併類別群集實作(請參閱 [BOO98]),其中有些並不直接提供應用程式功能,只是單純做為支援用途。這些支援類別通常是位於分層式架構的中下層,因此可以對所有應用程式層的類別提供共同的支援服務。

如果指出的次問題相當普遍,或許已經有型樣存在,可以透過連結現有的類別,以及實作型樣所需的新機制,來建立機制。用這種方式產生的分析機制是抽象的分析機制,需要經過進一步的設計和實作來修飾。

如需詳細資訊,請參閱概念:分析機制

審查結果
目的 確定架構分析的結果是完整且一致的。

訂好「架構分析」時,請審查所指出的架構機制、子系統、套件以及類別,以確保它們都完整且一致。由於「架構分析」只是初步的,且形式極不正式,因此審查形式也是非正式的。可以使用情境或使用案例驗證在多個階段選擇的架構,這包括從商業視景開始,往下到所發生的特定交互作用。

如需有關評估這項作業結果的詳細資訊,請參閱核對清單:軟體架構文件 - 架構分析注意事項



詳細資訊