核對清單: 軟體架構文件
本核對清單有助於確認軟體架構文件是否穩定、正確且完整。
關係
相關元素
主要說明

 

檢查項目
一般事項

整體而言,系統具有完善的架構基礎,因為:

  • 架構情況一切穩定。

    可靠性的需求出自於建構階段的特性,在建構專案期間中,往往會擴編、增援開發人員,他們在產品生產過程中並行工作,密切地相互溝通。若架構不穩定,則無法達到建構所需的獨立性及並行化作業。

    穩定架構的重要性不容誇大。不可抱著得過且過的心態,認為「差不多就算夠好了」,不穩定就是不穩定,應著手修正架構,即使會延後建構時間,也不應貿然進行。架構尚待修正,但開發人員卻急於據此架構進行建構時,協調一旦出問題,將導致原本可加速時程的明確效益 付諸流水。於建構期間變更架構,影響層面較廣,往往代價昂貴,且容易造成干擾並打擊士氣。

    評量架構穩定性的最大困難在於「無從知道的事情便無從判斷」,只能根據預期變更結果來衡量穩定性。因此,穩定性基本上是一種主觀評量。 不過,我們仍應以主觀判斷為重,單純推測為輔。架構本身的開發乃依據架構重要性情境考量,亦即從使用案例中,採取部分最具技術面挑戰行為者,同時也是系統所必須支援者。評量架構穩定性牽涉到確保架構涵蓋面的廣度,乃至於確保架構於後續過程中不會出現突發狀況。

    過去的架構規劃經驗也是值得借鏡的指標:假如架構的變更率低,且在納入新狀況後仍維持低水準,便可讓人相信該架構確實穩定。相對的,若每次遇到新狀況時都會造成架構變更,則表示架構仍在演進階段,基準線尚未確立。

  • 系統的複雜性與其提供的功能多寡成正比。
  • 概念性的複雜程度適當取決於下列對象的技能與經驗:
    • 使用者
    • 操作員
    • 開發人員
  • 系統擁有一致、連貫的單一架構
  • 元件的數量及類型合理
  • 系統具備全系統一致的安全性機能。 所有的安全性元件聯合運作,防衛系統安全。
  • 系統符合其可用性目標。
  • 架構允許讓系統在所需時間內進行故障回復。
  • 系統的產品及技術基礎是否符合其預期壽命?
    • 策略性的臨時系統因使用壽命短,短期內即將被捨棄,故可安心使用舊技術建置。
    • 大部分的系統具有較長的預期壽命,應以最新技術及方法建置,以便維護及擴充,以支援未來需求。
  • 架構提供明確定義的介面,以分割成不同區塊讓開發團隊並行作業。
  • 模型元素設計師能從架構清楚理解設計概念,順利設計開發出模型元素。
  • 套裝方法能降低複雜性,增進對內容的理解。
  • 套件定義為內部高度內聚,與外部套件之間則無緊密耦合性。
  • 對於常用應用程式領域,考量採用相似的解決方案。
  • 對於問題領域具備大體知識者,能夠輕易瞭解提議的解決方案。
  • 團隊全員對架構具有共識,且與軟體架構師的觀點一致。
  • 軟體架構文件正確無誤。
  • 確實遵循設計準則。
  • 所有的技術風險已透過應變計劃減輕或解除。新發現的風險已予記錄並分析其潛在衝擊。
  • 主要效能需求(已編列預算者)已獲得滿足。
  • 測試案例、測試工具及測試配置均已界定。
  • 架構無「過度設計」之情形。
    • 現行機制顯得容易使用。
    • 機制數量適中,且符合系統範圍及問題領域需求。
  • 針對目前的反覆計劃定義的所有使用案例實現化方案,皆可如圖解所示依架構執行:
    • 物件彼此之間互動;
    • 作業與流程之間互動;
    • 實體節點彼此之間互動。
模型

架構分析考量

整體
  • 子系統及套件分割與分層合乎邏輯一致性。
  • 已界定並說明所有的分析機制。
子系統
  • 已定義子系統的較高階層服務(介面)。
  • 子系統與套件之間的相依性,對應於其所含類別彼此之間的相依關係。
  • 子系統中的類別支援指定適用於子系統的服務。
類別
  • 已界定主要實體類別及其關係。
  • 已定義主要實體類別之間的關係。
  • 各類別的名稱及說明清晰反映出其所扮演的角色。
  • 各類別的說明確切記述該類別的權責。
  • 實體類別已適當對映至分析機制。
  • 聚集與關聯的角色名稱確實說明相關類別之間的關係。
  • 各種關係的多重對應關係正確。
  • 主要實體類別及其關係,在商業模型(如有)、網域模型(如有)、需求及名詞解釋項目中維持一致。

一般模型考

  • 模型具有一定的詳細程度,為模型制定目標。
  • 如為商業模型,對於詳述階段的需求模型及設計模型無需過度強調實作問題。
  • 如為建構階段的設計模型,模型元素在功能上已達平衡狀態,可使用較單純的組合來建置較複雜的設計。
  • 模型展現人員通曉問題領域的整體建模概念及勝任能力;採用適當的建模技術解決當前問題。
  • 盡可能以最簡單的方式將概念模型化。
  • 模型易於展演;能夠輕鬆融入預期變更。
  • 同時,模型結構尚未過度成熟發展,不至於為了因應意外變更而必須犧牲單純性及綜合性。
  • 模型背後的主要假設均有書面記錄,並可供模型審查人員查閱。若假設情況適用於既定的反覆計劃,則模型應能夠在假設情況下發展,無需刻意排除在外。將假設情況書面化,設計人員便無需關照所有的潛在需求。在反覆流程中,要分析所有的潛在需求,定義出能夠因應各種未來 需求的模型,實屬不可能。
圖解
  • 圖解的意義在於明白陳述、簡單易懂。
  • 圖形化版面能夠以簡潔扼要的方式傳達旨意。
  • 圖解的目標在於點到為止,決不東牽西扯。
  • 有效利用封裝,達到隱藏詳細資料、明確宣達的目的。
  • 有效利用摘要,達到隱藏詳細資料、明確宣達的目的。
  • 模型元素的放置方式能有效傳達其間的關係;將相似或密切關聯的元素歸入同組。
  • 模型元素之間的關係易於明瞭。
  • 模型元素的標籤標示讓人一目瞭然。
文件
  • 每一種模型元素都有其特定目的。
  • 模型元素在系統中各自扮演著必要角色,沒有一個是多餘的。
錯誤更正
  • 針對各種錯誤或異常狀況,透過原則定義將系統還原成「正常」狀態的措施。
  • 針對使用者輸入錯誤或外部系統傳入錯誤資料的可能類型,透過原則定義將系統還原成「正常」狀態的措施。
  • 已套用一貫原則以應付異常狀況。
  • 已套用一貫原則以應付資料庫中的資料毀損。
  • 已套用一貫原則以應付資料庫無法使用的情形,無論該情況下資料是否仍可輸入系統並於後儲存。
  • 於系統之間交換資料時,透過原則定義雙方系統的資料檢視同步化方式。
  • 系統若運用冗餘處理器或節點作為容錯或高可用性的因應措施時,透過策略以避免主要處理器或節點不存在或重複存在的情形發生。
  • 已界定分散式系統的故障模式,並已定義故障的因應策略。
轉換及安裝
  • 已定義能夠在無損資料或作業能力的情況下升級現有系統的流程,且通過測試。
  • 已定義轉換舊版資料的流程,且通過測試。
  • 徹底瞭解升級或安裝產品所需的時間及資源,並有書面記錄。
  • 系統功能一次可啟動一項使用案例。
系統管理
  • 磁碟空間可於系統執行時重組或還原。
  • 已界定系統配置的權責及程序,並有書面記錄。
  • 限定存取作業系統或系統管理功能的權限。
  • 符合版權需求。
  • 診斷常式可於系統執行時執行。
  • 系統能夠自我監視作業效能(例如容量臨界值、重要效能臨界值、資源耗盡等)。
    • 已定義達到臨界值時所應採取的行動。
    • 已定義警報處理原則。
    • 已定義警報處理機制,並建立原型且通過測試。
    • 警報處理機制可加以調整,以防假警報或多餘警報。
  • 已定義網路(LAN、WAN)監視與管理的原則及程序。
  • 可將網路發生的錯誤單獨隔離。
  • 可啟用事件追蹤機能以輔助疑難排解。
    • 瞭解機能的額外負荷。
    • 系統管理人員熟諳有效使用機能的專業知識。
  • 惡意使用者無法:
    • 入侵系統。
    • 毀壞重要資料。
    • 消耗所有資源。
效能
  • 效能需求合理,能反映出問題領域中的實際限制;規格有一定的規範。
  • 設有系統效能預估值(視需要使用工作量分析模型予以模型化),並指出效能需求無重大風險。
  • 已透過架構原型驗證系統效能預估值,尤其針對重要效能需求進行驗證。
記憶體使用率
  • 已定義應用程式的記憶體預算。
  • 已制定記憶體洩漏的偵測及預防措施。
  • 已套用一貫原則,定義虛擬記憶體系統的使用、監視及調整方法。
成本及排程
  • 截至目前里程碑實際開發的程式碼列數,與程式碼的預估列數相當接近。
  • 預估假設事先經過審查且持續有效。
  • 已根據最近的實際專案經驗及生產力效能,重新計算成本及時程預估值。
可攜性
  • 達到可攜性需求。
  • 程式設計準則中針對可攜式程式碼之建立設有特定準則。
  • 設計準則中針對可攜式應用程式之設計提供特定準則。
  • 已透過「測試埠」驗證可攜性訴求。
可靠性
  • 達到品質評量標準(MTBF、未解決問題的數量等)。
  • 架構設有發生災難或系統故障時的回復機制。
安全性
  • 達到安全性需求。
組織問題
  • 團隊結構是否健全?團隊權責劃分是否妥善?
  • 有無任何阻礙團隊效率的政策、組織或管理方面的問題?
  • 同事之間有無衝突?
使用案例觀點

軟體架構文件中的使用案例觀點一節指出:

  • 每一項使用案例皆具有架構重要性,因為使用案例:
    • 對於客戶極為重要
    • 能在其他觀點中激發重要元素
    • 能降低一個或多個主要風險,包括任何非功能性需求方面的挑戰。
  • 使用案例的架構議題不會在其他使用案例中重複探討
  • 使用案例的架構重要性觀點明確,不會遺漏於細節中
  • 使用案例明確,難以因變更而導致架構受影響,或者已有計劃提出達成該明確性及穩定性的具體作法
  • 概無遺漏任何具架構重要性的使用案例(可能需要透過分析篩選不適用於此觀點的使用案例)。
邏輯觀點

軟體架構文件中的邏輯觀點一節指出:

  • 確切並完整呈現設計中具架構重要性的元素概觀。
  • 提出設計中所使用的整套架構機制,並闡述選用該等機制的理由。
  • 提出設計的分層規劃,並闡述該種層次分割的理論依據。
  • 提出設計中使用到的任何架構或型樣,並闡述選用該等型樣或架構的理由。
  • 具架構重要性的模型元素數量與系統大小及範圍成比例,且其大小在可理解的系統中運作下仍得以呈現主要概念。
流程觀點
資源使用率
  • 已界定潛在競爭條件(流程爭取重要資源的競爭),並已制定規避及解決策略。
  • 已定義策略來應付「I/O 佇列已滿」或「緩衝區已滿」的情形。
  • 系統能夠自我監視(容量臨界值、重要效能臨界值、資源耗盡),並於偵測到問題時採取修正措施。
效能
  • 已定義各項訊息的回應時間需求。
  • 系統具有診斷模式,能夠測量訊息的回應時間。
  • 已針對重要作業指定最大標定效能需求。
  • 可透過一組效能測試,測量是否合乎效能需求。
  • 效能測試涵蓋系統的正常及異常行為(啟動及關機、使用案例的備用及異常狀況事件流程、系統故障模式)。
  • 已找出潛在導致效能瓶頸的架構弱點。特別強調下列事項:
    • 使用部分管制性的共用資源,例如(但不限於)符號、檔案控點、鎖定、閂鎖及共用記憶體等。
    • 跨程序通訊。跨越流程界限的溝通總是比流程內部溝通來得工程浩大。
    • 處理程序間溝通。跨程序溝通總是比程序間的溝通來得工程浩大。
    • 實體及虛擬記憶體用量;當系統的實體記憶體用盡,開始使用虛擬記憶體時,通常會造成系統效能急遽降低。
容錯
  • 當主要及備援流程同時存在時,考量到避免多個程序同時認定為主要(或無任何程序認定為主要)程序的情形發生,並採取特定的設計方案以解決衝突。
  • 萬一系統發生程序失敗等事件,導致系統產生不一致的狀態時,會由外部程序將系統還原成一致狀態。
  • 當系統發生錯誤或異常狀況時,可透過容錯機制將系統回復到一致狀態。
  • 診斷測試可於系統運作下執行。
  • 如有必要,可在系統運作下同時進行系統升級(包括軟硬體)。
  • 系統設有處理警報的一貫原則,且貫徹實施。 警報原則的作用在於:
    • 維護警報通報機制的敏感度;
    • 防止假警報或多餘警報;
    • 免除警報通報機制操作人員訓練及使用者介面需求。
  • 已評量警報通報機制的效能,且評量結果在效能需求所訂的效能臨界值接受範圍內。
  • 已查驗工作量/效能需求且符合標準。若效能需求不合乎實際,應重新商議。
  • 已界定最大可能範圍的記憶體預算,並驗證軟體以符合該項需求。已實施記憶體洩漏的偵測及預防措施。
  • 透過原則控制使用虛擬記憶體系統,包括監視及調整用量的方式。
模組化
  • 程序彼此具有足夠的獨立性,能夠於必要時分送至處理器或節點。
  • 基於效能及產能需求或程序間溝通機制,而必須維持並行配置的程序(例如符號或共用記憶體等)均已界定,對於無法分送此工作量時的影響亦已納入考量。
  • 已界定可不同步處理的訊息,留待資源較充裕時再做處理。
部署觀點
  • 已藉由節點分散式處理達到產能需求,並解決潛在的效能瓶頸。
  • 只要將資訊分送並抄寫至數個節點,即確保資訊整合性。
  • 因應可靠訊息傳輸的要求,達到該可靠性需求標準。
  • 因應安全訊息傳輸的要求,達到該安全性需求標準。
  • 因應一致性及資源限制將網路流量與回應時間降至最低,以此方式將處理程序分送至各節點。 
  • 因應系統可用性的要求,達到該可用性需求標準。
    • 已確立發生伺服器或網路故障時的系統停機時間上限,且合乎需求所訂的可接受限度。
    • 已定義備用及待命伺服器,以免同時有多台伺服器指定為主要伺服器的情形發生。
  • 已書面記錄所有潛在可能的故障模式。
  • 網路發生的錯誤可單獨隔離、診斷並解決。
  • 已界定 CPU 使用率中的「預留空間」量,並已界定測量方法。
  • 當 CPU 使用率超過上限時,可遵循既定原則採取因應措施。