從需求分類到多檢視架構設計方法

要開發出使用者滿意的軟體並不是件容易的事，軟體架構師必須全面把握各種各樣的需求、權衡需求之間有可能的矛盾之處，分門別類地將不同需求一一滿足。本文從理解需求種類的複雜性談起，通過具體案例的分析，展示瞭如何通過RUP的4+1檢視方法，針對不同需求進行架構設計，從而確保重要的需求一一被滿足。

呼喚架構設計的多重檢視方法

靈感一閃，就想出了把大象放進冰箱的辦法，這自然好。但希望每個架構設計策略都依靠靈感是不現實的——我們需要系統方法的指導。

需要架構設計的多重檢視方法，從根本上來說是因為需求種類的複雜性所致。以工程領域的例子開道吧。比如設計一座跨江大橋：我們會考慮“連線南北的公路交通”這個“功能需求”，從而初步設計出理想化的橋墩支撐的公路橋方案；然後還要考慮造橋要面臨的“約束條件”，這個約束條件可能是“不能影響萬噸輪從橋下通過”，於是細化設計方案，規定橋墩的高度和橋墩之間的間距；另外還要顧及“大橋的使用期質量屬性”，比如為了“能在湍急的江流中保持穩固”，可以把大橋橋墩深深地建在岩石層之上，和大地渾然一體；其實，“建造期間的質量屬性”也很值得考慮，比如在大橋的設計過程中考慮“施工方便性”的一些措施。

和工程領域的功能需求、約束條件、使用期質量屬性、建造期間的質量屬性等類似，軟體系統的需求種類也相當複雜，具體分類如圖1所示。

軟體需求

功能需求

非功能需求

約束

質量屬性

執行期質量屬性

開發期質量屬性

圖1 軟體需求分類的複雜性

超市系統案例：理解需求種類的複雜性

例子是最好的老師。為了更好地理解軟體需求種類的複雜性，我們來分析一個實際的例子。在表1中，我們列舉了一個典型的超市系統的需求子集，從這個例子中可以清晰地看到需求可以分為兩大類：功能需求和非功能需求。

非功能需求			功能需求
約束	執行期質量屬性	開發期質量屬性
專案預算有限 使用者的平均電腦操作水平偏低 要求能在Linux上執行 開發人員分散在不同地點 ……	高效能 易用性 ……	易理解性 模組間鬆散耦合 ……	提高收銀效率 任意商品項可單獨取消 通過收銀終端的按鍵組合，可以使收銀過程從“逐項錄入狀態”進入“選擇取消狀態” ……

表1 超市系統案例：理解需求種類的複雜性

簡單而言，功能需求就是“軟體有什麼用，軟體需要做什麼”。同時，注意把握功能需求的層次性是軟體需求的最佳實踐。以該超市系統為例：

l 超市老闆希望通過軟體來“提高收銀效率”。

l 那麼，你可能需要為收銀員提供一系列功能來促成這個目的，比如供收銀員使用的“任意商品項可單獨取消”功能有利於提供收銀效率（筆者曾在超市有過被迫整單取消然後一車商品重新掃描收費的痛苦經歷）。

l 而具體到這個超市系統，系統分析員可能會決定要提供的具體功能為：通過收銀終端的按鍵組合，可以使收銀過程從“逐項錄入狀態”進入“選擇取消狀態”，從而取消某項商品。

從上面的例子中我們還驚訝地發現，非功能需求——人們最經常忽視的一大類需求——包括的內容非常寬、並且極其重要。非功能需求又可以分為如下三類：

l 約束。要開發出使用者滿意的軟體並不是件容易的事，而全面理解要設計的軟體系統所面臨的約束可以使你向成功邁進一步。約束性需求既包括企業級的商業考慮（例如“專案預算有限”），也包括終端使用者級的實際情況（例如“使用者的平均電腦操作水平偏低”）；既可能包括具體技術的明確要求（例如“要求能在Linux上執行”），又可能需要考慮開發團隊的真實狀況（例如“開發人員分散在不同地點”）。這些約束性需求當然對架構設計影響很大，比如受到“專案預算有限”的限制，架構師就不應選擇昂貴的技術或中介軟體等，而考慮到開發人員分散在不同地點”，就更應注重軟體模組職責劃分的合理性、鬆耦合性等等。

l 執行期質量屬性。這類需求主要指軟體系統在執行期間表現出的質量水平。執行期質量屬性非常關鍵，因為它們直接影響著客戶對軟體系統的滿意度，大多數客戶也不會接受執行期質量屬性拙劣的軟體系統。常見的執行期質量屬性包括軟體系統的易用性、效能、可伸縮性、持續可用性、魯棒性、安全性等。在我們的超市系統的案例中，使用者對高效能提出了具體要求（真正的效能需求應該量化，我們的表1沒體現），他們不能容忍金額合計超過2秒的延時。

l 開發期質量屬性。這類非功能需求中的某些項人們倒是念念不忘，可惜很多人並沒有意識到“開發期質量屬性”和“執行期質量屬性”對架構設計的影響到底有何不同。開發期質量屬性是開發人員最為關心的，要達到怎樣的目標應根據專案的具體情況而定，而過度設計（overengineering）會花費額外的代價。

什麼是軟體架構檢視

那麼，什麼是軟體架構檢視呢？Philippe Kruchten在其著作《Rational統一過程引論》中寫道：

一個架構檢視是對於從某一視角或某一點上看到的系統所做的簡化描述，描述中涵蓋了系統的某一特定方面，而省略了於此方面無關的實體。

也就是說，架構要涵蓋的內容和決策太多了，超過了人腦“一蹴而就”的能力範圍，因此採用“分而治之”的辦法從不同視角分別設計；同時，也為軟體架構的理解、交流和歸檔提供了方便。

值得特別說明的，大多數書籍中都強調多檢視方法是軟體架構歸檔的方法，其實不然。多檢視方法不僅僅是架構歸檔技術，更是指導我們進行架構設計的思維方法。

Philippe Kruchten提出的4+1檢視方法

1995年，Philippe Kruchten在《IEEE Software》上發表了題為《The 4+1 View Model of Architecture》的論文，引起了業界的極大關注，並最終被RUP採納。

該方法的不同架構檢視承載不同的架構設計決策，支援不同的目標和用途：

l 邏輯檢視：當採用物件導向的設計方法時，邏輯檢視即物件模型。

l 開發檢視：描述軟體在開發環境下的靜態組織。

l 處理檢視：描述系統的併發和同步方面的設計。

l 物理檢視：描述軟體如何對映到硬體，反映系統在分佈方面的設計。

運用4+1檢視方法：針對不同需求進行架構設計

如前文所述，要開發出使用者滿意的軟體並不是件容易的事，軟體架構師必須全面把握各種各樣的需求、權衡需求之間有可能的矛盾之處，分門別類地將不同需求一一滿足。

Philippe Kruchten提出的4+1檢視方法為軟體架構師“一一征服需求”提供了良好基礎，如圖3所示。

圖3 運用4+1檢視方法針對不同需求進行架構設計

邏輯檢視。邏輯檢視關注功能，不僅包括使用者可見的功能，還包括為實現使用者功能而必須提供的“輔助功能模組”；它們可能是邏輯層、功能模組等。

開發檢視。開發檢視關注程式包，不僅包括要編寫的源程式，還包括可以直接使用的第三方SDK和現成框架、類庫，以及開發的系統將執行於其上的系統軟體或中介軟體。開發檢視和邏輯檢視之間可能存在一定的對映關係：比如邏輯層一般會對映到多個程式包等。

處理檢視。處理檢視關注程式、執行緒、物件等執行時概念，以及相關的併發、同步、通訊等問題。處理檢視和開發檢視的關係：開發檢視一般偏重程式包在編譯時期的靜態依賴關係，而這些程式執行起來之後會表現為物件、執行緒、程式，處理檢視比較關注的正是這些執行時單元的互動問題。

物理檢視。物理檢視關注“目標程式及其依賴的執行庫和系統軟體”最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性等要求。物理檢視和處理檢視的關係：處理檢視特別關注目標程式的動態執行情況，而物理檢視重視目標程式的靜態位置問題；物理檢視是綜合考慮軟體系統和整個IT系統相互影響的架構檢視。

裝置除錯系統案例概述

本文的以下部分，將研究一個案例：某型號裝置除錯系統。

裝置除錯員通過使用該系統，可以察看裝置狀態（裝置的狀態資訊由專用的資料採集器實時採集）、傳送除錯命令。該系統的用例圖如圖4所示。

圖4 裝置除錯系統的用例圖

經過研製方和委託方的緊密配合，最終確定的需求可以總括地用表2來表示。

非功能需求			功能需求
約束	執行期質量屬性	開發期質量屬性
程式的嵌入式部分必須用C語言開發 一部分開發人員沒有嵌入式開發經驗	高效能	易測試性	察看裝置狀態 傳送除錯命令

表2 裝置除錯系統的需求

下面運用RUP推薦的4+1檢視方法，從不同檢視進行架構設計，來分門別類地將不同需求一一滿足。

邏輯檢視：設計滿足功能需求的架構

首先根據功能需求進行初步設計，進行大粒度的職責劃分。如圖5所示。

l 應用層負責裝置狀態的顯示，並提供模擬控制檯供使用者傳送除錯命令。

l 應用層使用通訊層和嵌入層進行互動，但應用層不知道通訊的細節。

l 通訊層負責在RS232協議之上實現一套專用的“應用協議”。

l 當應用層傳送來包含除錯指令的協議包，由通訊層負責按RS232協議將之傳遞給嵌入層。

l 當嵌入層傳送來原始資料，由通訊層將之解釋成應用協議包傳送給應用層。

l 嵌入層負責對除錯裝置的具體控制，以及高頻度地從資料採集器讀取裝置狀態資料。

l 裝置控制指令的物理規格被封裝在嵌入層內部，讀取數採器的具體細節也被封裝在嵌入層內部。

開發檢視：設計滿足開發期質量屬性的架構

軟體架構的開發檢視應當為開發人員提供切實的指導。任何影響全域性的設計決策都應由架構設計來完成，這些決策如果“漏”到了後邊，最終到了大規模並行開發階段才發現，可能造成“程式設計師碰頭兒臨時決定”的情況大量出現，軟體質量必然將下降甚至導致專案失敗。

其中，採用哪些現成框架、哪些第三方SDK、乃至哪些中介軟體平臺，都應該考慮是否由軟體架構的開發檢視確定下來。裝置除錯系統的（一部分）軟體架構開發檢視：應用層將基於MFC設計實現，而通訊層採用了某串列埠通訊的第三方SDK。

在說說約束性需求。約束應該是每個架構檢視都應該關注和遵守的一些設計限制。例如，考慮到“一部分開發人員沒有嵌入式開發經驗”這條約束情況，架構師有必要明確說明系統的目標程式是如何編譯而來的：整個系統的桌面部分的目標程式pc-moduel.exe、以及嵌入式模組rom-module.hex是如何編譯而來的。這個全域性性的描述無疑對沒有經驗的開發人員提供了實感，利於更全面地理解系統的軟體架構。

處理檢視：設計滿足執行期質量屬性的架構

效能是軟體系統執行期間所表現出的一種質量水平，一般用系統響應時間和系統吞吐量來衡量。為了達到高效能的要求，軟體架構師應當針對軟體的執行時情況進行分析與設計，這就是我們所謂的軟體架構的處理檢視的目標。處理檢視關注程式、執行緒、物件等執行時概念，以及相關的併發、同步、通訊等問題。

可以看出，架構師為了滿足高效能需求，採用了多執行緒的設計：

l 應用層中的執行緒代表主程式的執行，它直接利用了MFC的主視窗執行緒。無論是使用者互動，還是串列埠的資料到達，均採取非同步事件的方式處理，杜絕了任何“忙等待”無謂的耗時，也縮短了系統響應時間。

l 通訊層有獨立的執行緒控制著“上上下下”的資料，並設定了資料緩衝區，使資料的接收和資料的處理相對獨立，從而資料接收不會因暫時的處理忙碌而停滯，增加了系統吞吐量。

l 嵌入層的設計中，分別通過時鐘中斷和RS232口中斷來激發相應的處理邏輯，達到輪詢和收發資料的目的。

物理檢視：和部署相關的架構決策

軟體最終要駐留、安裝或部署到硬體才能執行，而軟體架構的物理檢視關注“目標程式及其依賴的執行庫和系統軟體”最終如何安裝或部署到物理機器，以及如何部署機器和網路來配合軟體系統的可靠性、可伸縮性等要求。圖9所示的物理架構檢視表達了裝置除錯系統軟體和硬體的對映關係。可以看出，嵌入部分駐留在除錯機中（除錯機是專用單板機），而PC機上是常見的桌面可執行程式的形式。

我們還可能根據具體情況的需要，通過物理架構檢視更明確地表達具體目標模組及其通訊結構。

小結與說明

所謂本立道生。深入理解軟體需求分類的複雜性，明確區分功能需求、約束、執行期質量屬性、開發期質量屬性等不同種類的需求就是“本”，因為各類需求對架構設計的影響截然不同。本文通過具體案例的分析，展示瞭如何通過RUP的4+1檢視方法，針對不同需求進行架構設計，從而確保重要的需求一一被滿足。

本文重點在於方法的解說，因此省略了對架構設計中不少具體問題的說明，同時本文提供的說明架構設計方案的模型也經過了簡化。請讀者注意。

本文轉自BlogJava 新浪blog的部落格，原文連結：從需求分類到多檢視架構設計方法，如需轉載請自行聯絡原博主。