|
要開(kāi)發(fā)出用戶(hù)滿(mǎn)意的軟件并不是件容易的事，軟件架構(gòu)師必須全面把握各種各樣的需求、權(quán)衡需求之間有可能的矛盾之處，分門(mén)別類(lèi)地將不同需求一一滿(mǎn)足。本文從理解需求種類(lèi)的復(fù)雜性談起，通過(guò)具體案例的分析，展示了如何通過(guò)RUP的4+1視圖方法，針對(duì)不同需求進(jìn)行架構(gòu)設(shè)計(jì)，從而確保重要的需求一一被滿(mǎn)足。
呼喚架構(gòu)設(shè)計(jì)的多重視圖方法
靈感一閃，就想出了把大象放進(jìn)冰箱的辦法，這自然好。但希望每個(gè)架構(gòu)設(shè)計(jì)策略都依靠靈感是不現(xiàn)實(shí)的--我們需要系統(tǒng)方法的指導(dǎo)。
需要架構(gòu)設(shè)計(jì)的多重視圖方法，從根本上來(lái)說(shuō)是因?yàn)樾枨蠓N類(lèi)的復(fù)雜性所致。以工程領(lǐng)域的例子開(kāi)道吧。比如設(shè)計(jì)一座跨江大橋：我們會(huì)考慮"連接南北的公路交通"這個(gè)"功能需求"，從而初步設(shè)計(jì)出理想化的橋墩支撐的公路橋方案；然后還要考慮造橋要面臨的"約束條件"，這個(gè)約束條件可能是"不能影響萬(wàn)噸輪從橋下通過(guò)"，于是細(xì)化設(shè)計(jì)方案，規(guī)定橋墩的高度和橋墩之間的間距；另外還要顧及"大橋的使用期質(zhì)量屬性"，比如為了"能在湍急的江流中保持穩(wěn)固"，可以把大橋橋墩深深地建在巖石層之上，和大地渾然一體；其實(shí)，"建造期間的質(zhì)量屬性"也很值得考慮，比如在大橋的設(shè)計(jì)過(guò)程中考慮"施工方便性"的一些措施。
和工程領(lǐng)域的功能需求、約束條件、使用期質(zhì)量屬性、建造期間的質(zhì)量屬性等類(lèi)似，軟件系統(tǒng)的需求種類(lèi)也相當(dāng)復(fù)雜，具體分類(lèi)如圖1所示。
圖1 軟件需求分類(lèi)的復(fù)雜性
回頁(yè)首
超市系統(tǒng)案例：理解需求種類(lèi)的復(fù)雜性
例子是最好的老師。為了更好地理解軟件需求種類(lèi)的復(fù)雜性，我們來(lái)分析一個(gè)實(shí)際的例子。在表1中，我們列舉了一個(gè)典型的超市系統(tǒng)的需求子集，從這個(gè)例子中可以清晰地看到需求可以分為兩大類(lèi)：功能需求和非功能需求。
表1 超市系統(tǒng)案例：理解需求種類(lèi)的復(fù)雜性
簡(jiǎn)單而言，功能需求就是"軟件有什么用，軟件需要做什么"。同時(shí)，注意把握功能需求的層次性是軟件需求的最佳實(shí)踐。以該超市系統(tǒng)為例：
* 超市老板希望通過(guò)軟件來(lái)"提高收銀效率"。
* 那么，你可能需要為收銀員提供一系列功能來(lái)促成這個(gè)目的，比如供收銀員使用的"任意商品項(xiàng)可單獨(dú)取消"功能有利于提供收銀效率（筆者曾在超市有過(guò)被迫整單取消然后一車(chē)商品重新掃描收費(fèi)的痛苦經(jīng)歷）。
* 而具體到這個(gè)超市系統(tǒng)，系統(tǒng)分析員可能會(huì)決定要提供的具體功能為：通過(guò)收銀終端的按鍵組合，可以使收銀過(guò)程從"逐項(xiàng)錄入狀態(tài)"進(jìn)入"選擇取消狀態(tài)"，從而取消某項(xiàng)商品。
從上面的例子中我們還驚訝地發(fā)現(xiàn)，非功能需求--人們最經(jīng)常忽視的一大類(lèi)需求--包括的內(nèi)容非常寬、并且極其重要。非功能需求又可以分為如下三類(lèi)：
* 約束。要開(kāi)發(fā)出用戶(hù)滿(mǎn)意的軟件并不是件容易的事，而全面理解要設(shè)計(jì)的軟件系統(tǒng)所面臨的約束可以使你向成功邁進(jìn)一步。約束性需求既包括企業(yè)級(jí)的商業(yè)考慮（例如"項(xiàng)目預(yù)算有限"），也包括最終用戶(hù)級(jí)的實(shí)際情況（例如"用戶(hù)的平均電腦操作水平偏低"）；既可能包括具體技術(shù)的明確要求（例如"要求能在Linux上運(yùn)行"），又可能需要考慮開(kāi)發(fā)團(tuán)隊(duì)的真實(shí)狀況（例如"開(kāi)發(fā)人員分散在不同地點(diǎn)"）。這些約束性需求當(dāng)然對(duì)架構(gòu)設(shè)計(jì)影響很大，比如受到"項(xiàng)目預(yù)算有限"的限制，架構(gòu)師就不應(yīng)選擇昂貴的技術(shù)或中間件等，而考慮到開(kāi)發(fā)人員分散在不同地點(diǎn)"，就更應(yīng)注重軟件模塊職責(zé)劃分的合理性、松耦合性等等。
* 運(yùn)行期質(zhì)量屬性。這類(lèi)需求主要指軟件系統(tǒng)在運(yùn)行期間表現(xiàn)出的質(zhì)量水平。運(yùn)行期質(zhì)量屬性非常關(guān)鍵，因?yàn)樗鼈冎苯佑绊懼蛻?hù)對(duì)軟件系統(tǒng)的滿(mǎn)意度，大多數(shù)客戶(hù)也不會(huì)接受運(yùn)行期質(zhì)量屬性拙劣的軟件系統(tǒng)。常見(jiàn)的運(yùn)行期質(zhì)量屬性包括軟件系統(tǒng)的易用性、性能、可伸縮性、持續(xù)可用性、魯棒性、安全性等。在我們的超市系統(tǒng)的案例中，用戶(hù)對(duì)高性能提出了具體要求（真正的性能需求應(yīng)該量化，我們的表1沒(méi)體現(xiàn)），他們不能容忍金額合計(jì)超過(guò) 2秒的延時(shí)。
* 開(kāi)發(fā)期質(zhì)量屬性。這類(lèi)非功能需求中的某些項(xiàng)人們倒是念念不忘，可惜很多人并沒(méi)有意識(shí)到"開(kāi)發(fā)期質(zhì)量屬性"和" 運(yùn)行期質(zhì)量屬性"對(duì)架構(gòu)設(shè)計(jì)的影響到底有何不同。開(kāi)發(fā)期質(zhì)量屬性是開(kāi)發(fā)人員最為關(guān)心的，要達(dá)到怎樣的目標(biāo)應(yīng)根據(jù)項(xiàng)目的具體情況而定，而過(guò)度設(shè)計(jì)（overengineering）會(huì)花費(fèi)額外的代價(jià)。
回頁(yè)首
什么是軟件架構(gòu)視圖
那么，什么是軟件架構(gòu)視圖呢？Philippe Kruchten在其著作《Rational統(tǒng)一過(guò)程引論》中寫(xiě)道：
一個(gè)架構(gòu)視圖是對(duì)于從某一視角或某一點(diǎn)上看到的系統(tǒng)所做的簡(jiǎn)化描述，描述中涵蓋了系統(tǒng)的某一特定方面，而省略了于此方面無(wú)關(guān)的實(shí)體。
也就是說(shuō)，架構(gòu)要涵蓋的內(nèi)容和決策太多了，超過(guò)了人腦"一蹴而就"的能力范圍，因此采用"分而治之"的辦法從不同視角分別設(shè)計(jì)；同時(shí)，也為軟件架構(gòu)的理解、交流和歸檔提供了方便。
值得特別說(shuō)明的，大多數(shù)書(shū)籍中都強(qiáng)調(diào)多視圖方法是軟件架構(gòu)歸檔的方法，其實(shí)不然。多視圖方法不僅僅是架構(gòu)歸檔技術(shù)，更是指導(dǎo)我們進(jìn)行架構(gòu)設(shè)計(jì)的思維方法。
回頁(yè)首
Philippe Kruchten提出的4+1視圖方法
1995年，Philippe Kruchten在《IEEE Software》上發(fā)表了題為《The 4+1 View Model of Architecture》的論文，引起了業(yè)界的極大關(guān)注，并最終被RUP采納。如圖2所示。
圖2 Philippe Kruchten提出的4+1視圖方法
該方法的不同架構(gòu)視圖承載不同的架構(gòu)設(shè)計(jì)決策，支持不同的目標(biāo)和用途：
* 邏輯視圖：當(dāng)采用面向?qū)ο蟮脑O(shè)計(jì)方法時(shí)，邏輯視圖即對(duì)象模型。
* 開(kāi)發(fā)視圖：描述軟件在開(kāi)發(fā)環(huán)境下的靜態(tài)組織。
* 處理視圖：描述系統(tǒng)的并發(fā)和同步方面的設(shè)計(jì)。
* 物理視圖：描述軟件如何映射到硬件，反映系統(tǒng)在分布方面的設(shè)計(jì)。
回頁(yè)首
運(yùn)用4+1視圖方法：針對(duì)不同需求進(jìn)行架構(gòu)設(shè)計(jì)
如前文所述，要開(kāi)發(fā)出用戶(hù)滿(mǎn)意的軟件并不是件容易的事，軟件架構(gòu)師必須全面把握各種各樣的需求、權(quán)衡需求之間有可能的矛盾之處，分門(mén)別類(lèi)地將不同需求一一滿(mǎn)足。
Philippe Kruchten提出的4+1視圖方法為軟件架構(gòu)師"一一征服需求"提供了良好基礎(chǔ)，如圖3所示。
圖3 運(yùn)用4+1視圖方法針對(duì)不同需求進(jìn)行架構(gòu)設(shè)計(jì)
邏輯視圖。邏輯視圖關(guān)注功能，不僅包括用戶(hù)可見(jiàn)的功能，還包括為實(shí)現(xiàn)用戶(hù)功能而必須提供的"輔助功能模塊"；它們可能是邏輯層、功能模塊等。
開(kāi)發(fā)視圖。開(kāi)發(fā)視圖關(guān)注程序包，不僅包括要編寫(xiě)的源程序，還包括可以直接使用的第三方SDK和現(xiàn)成框架、類(lèi)庫(kù)，以及開(kāi)發(fā)的系統(tǒng)將運(yùn)行于其上的系統(tǒng)軟件或中間件。開(kāi)發(fā)視圖和邏輯視圖之間可能存在一定的映射關(guān)系：比如邏輯層一般會(huì)映射到多個(gè)程序包等。
處理視圖。處理視圖關(guān)注進(jìn)程、線(xiàn)程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問(wèn)題。處理視圖和開(kāi)發(fā)視圖的關(guān)系：開(kāi)發(fā)視圖一般偏重程序包在編譯時(shí)期的靜態(tài)依賴(lài)關(guān)系，而這些程序運(yùn)行起來(lái)之后會(huì)表現(xiàn)為對(duì)象、線(xiàn)程、進(jìn)程，處理視圖比較關(guān)注的正是這些運(yùn)行時(shí)單元的交互問(wèn)題。
物理視圖。物理視圖關(guān)注"目標(biāo)程序及其依賴(lài)的運(yùn)行庫(kù)和系統(tǒng)軟件"最終如何安裝或部署到物理機(jī)器，以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性、可伸縮性等要求。物理視圖和處理視圖的關(guān)系：處理視圖特別關(guān)注目標(biāo)程序的動(dòng)態(tài)執(zhí)行情況，而物理視圖重視目標(biāo)程序的靜態(tài)位置問(wèn)題；物理視圖是綜合考慮軟件系統(tǒng)和整個(gè)IT系統(tǒng)相互影響的架構(gòu)視圖。
回頁(yè)首
設(shè)備調(diào)試系統(tǒng)案例概述
本文的以下部分，將研究一個(gè)案例：某型號(hào)設(shè)備調(diào)試系統(tǒng)。
設(shè)備調(diào)試員通過(guò)使用該系統(tǒng)，可以察看設(shè)備狀態(tài)（設(shè)備的狀態(tài)信息由專(zhuān)用的數(shù)據(jù)采集器實(shí)時(shí)采集）、發(fā)送調(diào)試命令。該系統(tǒng)的用例圖如圖4所示。
圖4 設(shè)備調(diào)試系統(tǒng)的用例圖
經(jīng)過(guò)研制方和委托方的緊密配合，最終確定的需求可以總括地用表2來(lái)表示。
表2 設(shè)備調(diào)試系統(tǒng)的需求
下面運(yùn)用RUP推薦的4+1視圖方法，從不同視圖進(jìn)行架構(gòu)設(shè)計(jì)，來(lái)分門(mén)別類(lèi)地將不同需求一一滿(mǎn)足。
回頁(yè)首
邏輯視圖：設(shè)計(jì)滿(mǎn)足功能需求的架構(gòu)
首先根據(jù)功能需求進(jìn)行初步設(shè)計(jì)，進(jìn)行大粒度的職責(zé)劃分。如圖5所示。
* 應(yīng)用層負(fù)責(zé)設(shè)備狀態(tài)的顯示，并提供模擬控制臺(tái)供用戶(hù)發(fā)送調(diào)試命令。
* 應(yīng)用層使用通訊層和嵌入層進(jìn)行交互，但應(yīng)用層不知道通訊的細(xì)節(jié)。
* 通訊層負(fù)責(zé)在RS232協(xié)議之上實(shí)現(xiàn)一套專(zhuān)用的"應(yīng)用協(xié)議"。
* 當(dāng)應(yīng)用層發(fā)送來(lái)包含調(diào)試指令的協(xié)議包，由通訊層負(fù)責(zé)按RS232協(xié)議將之傳遞給嵌入層。
* 當(dāng)嵌入層發(fā)送來(lái)原始數(shù)據(jù)，由通訊層將之解釋成應(yīng)用協(xié)議包發(fā)送給應(yīng)用層。
* 嵌入層負(fù)責(zé)對(duì)調(diào)試設(shè)備的具體控制，以及高頻度地從數(shù)據(jù)采集器讀取設(shè)備狀態(tài)數(shù)據(jù)。
* 設(shè)備控制指令的物理規(guī)格被封裝在嵌入層內(nèi)部，讀取數(shù)采器的具體細(xì)節(jié)也被封裝在嵌入層內(nèi)部。
圖5 設(shè)備調(diào)試系統(tǒng)架構(gòu)的邏輯視圖
回頁(yè)首
開(kāi)發(fā)視圖：設(shè)計(jì)滿(mǎn)足開(kāi)發(fā)期質(zhì)量屬性的架構(gòu)
軟件架構(gòu)的開(kāi)發(fā)視圖應(yīng)當(dāng)為開(kāi)發(fā)人員提供切實(shí)的指導(dǎo)。任何影響全局的設(shè)計(jì)決策都應(yīng)由架構(gòu)設(shè)計(jì)來(lái)完成，這些決策如果"漏"到了后邊，最終到了大規(guī)模并行開(kāi)發(fā)階段才發(fā)現(xiàn)，可能造成"程序員碰頭兒臨時(shí)決定"的情況大量出現(xiàn)，軟件質(zhì)量必然將下降甚至導(dǎo)致項(xiàng)目失敗。
其中，采用哪些現(xiàn)成框架、哪些第三方SDK、乃至哪些中間件平臺(tái)，都應(yīng)該考慮是否由軟件架構(gòu)的開(kāi)發(fā)視圖確定下來(lái)。圖6展示了設(shè)備調(diào)試系統(tǒng)的（一部分）軟件架構(gòu)開(kāi)發(fā)視圖：應(yīng)用層將基于MFC設(shè)計(jì)實(shí)現(xiàn)，而通訊層采用了某串口通訊的第三方SDK。
圖6 設(shè)備調(diào)試系統(tǒng)架構(gòu)的開(kāi)發(fā)視圖
在說(shuō)說(shuō)約束性需求。約束應(yīng)該是每個(gè)架構(gòu)視圖都應(yīng)該關(guān)注和遵守的一些設(shè)計(jì)限制。例如，考慮到"一部分開(kāi)發(fā)人員沒(méi)有嵌入式開(kāi)發(fā)經(jīng)驗(yàn)"這條約束情況，架構(gòu)師有必要明確說(shuō)明系統(tǒng)的目標(biāo)程序是如何編譯而來(lái)的：圖7展示了整個(gè)系統(tǒng)的桌面部分的目標(biāo)程序pc-moduel.exe、以及嵌入式模塊rom- module.hex是如何編譯而來(lái)的。這個(gè)全局性的描述無(wú)疑對(duì)沒(méi)有經(jīng)驗(yàn)的開(kāi)發(fā)人員提供了實(shí)感，利于更全面地理解系統(tǒng)的軟件架構(gòu)。
圖7 設(shè)備調(diào)試系統(tǒng)架構(gòu)的開(kāi)發(fā)視圖
回頁(yè)首
處理視圖：設(shè)計(jì)滿(mǎn)足運(yùn)行期質(zhì)量屬性的架構(gòu)
性能是軟件系統(tǒng)運(yùn)行期間所表現(xiàn)出的一種質(zhì)量水平，一般用系統(tǒng)響應(yīng)時(shí)間和系統(tǒng)吞吐量來(lái)衡量。為了達(dá)到高性能的要求，軟件架構(gòu)師應(yīng)當(dāng)針對(duì)軟件的運(yùn)行時(shí)情況進(jìn)行分析與設(shè)計(jì)，這就是我們所謂的軟件架構(gòu)的處理視圖的目標(biāo)。處理視圖關(guān)注進(jìn)程、線(xiàn)程、對(duì)象等運(yùn)行時(shí)概念，以及相關(guān)的并發(fā)、同步、通信等問(wèn)題。圖8展示了設(shè)備調(diào)試系統(tǒng)架構(gòu)的處理視圖。
可以看出，架構(gòu)師為了滿(mǎn)足高性能需求，采用了多線(xiàn)程的設(shè)計(jì)：
* 應(yīng)用層中的線(xiàn)程代表主程序的運(yùn)行，它直接利用了MFC的主窗口線(xiàn)程。無(wú)論是用戶(hù)交互，還是串口的數(shù)據(jù)到達(dá)，均采取異步事件的方式處理，杜絕了任何"忙等待"無(wú)謂的耗時(shí)，也縮短了系統(tǒng)響應(yīng)時(shí)間。
* 通訊層有獨(dú)立的線(xiàn)程控制著"上上下下"的數(shù)據(jù)，并設(shè)置了數(shù)據(jù)緩沖區(qū)，使數(shù)據(jù)的接收和數(shù)據(jù)的處理相對(duì)獨(dú)立，從而數(shù)據(jù)接收不會(huì)因暫時(shí)的處理忙碌而停滯，增加了系統(tǒng)吞吐量。
* 嵌入層的設(shè)計(jì)中，分別通過(guò)時(shí)鐘中斷和RS232口中斷來(lái)激發(fā)相應(yīng)的處理邏輯，達(dá)到輪詢(xún)和收發(fā)數(shù)據(jù)的目的。
圖8 設(shè)備調(diào)試系統(tǒng)架構(gòu)的處理視圖
回頁(yè)首
物理視圖：和部署相關(guān)的架構(gòu)決策
軟件最終要駐留、安裝或部署到硬件才能運(yùn)行，而軟件架構(gòu)的物理視圖關(guān)注"目標(biāo)程序及其依賴(lài)的運(yùn)行庫(kù)和系統(tǒng)軟件"最終如何安裝或部署到物理機(jī)器，以及如何部署機(jī)器和網(wǎng)絡(luò)來(lái)配合軟件系統(tǒng)的可靠性、可伸縮性等要求。圖9所示的物理架構(gòu)視圖表達(dá)了設(shè)備調(diào)試系統(tǒng)軟件和硬件的映射關(guān)系?？梢钥闯觯度氩糠竹v留在調(diào)試機(jī)中（調(diào)試機(jī)是專(zhuān)用單板機(jī)），而PC機(jī)上是常見(jiàn)的桌面可執(zhí)行程序的形式。
圖9 設(shè)備調(diào)試系統(tǒng)架構(gòu)的物理視圖
我們還可能根據(jù)具體情況的需要，通過(guò)物理架構(gòu)視圖更明確地表達(dá)具體目標(biāo)模塊及其通訊結(jié)構(gòu)，如圖10所示。
圖10 設(shè)備調(diào)試系統(tǒng)架構(gòu)的物理視圖
回頁(yè)首
小結(jié)與說(shuō)明
所謂本立道生。深入理解軟件需求分類(lèi)的復(fù)雜性，明確區(qū)分功能需求、約束、運(yùn)行期質(zhì)量屬性、開(kāi)發(fā)期質(zhì)量屬性等不同種類(lèi)的需求就是"本"，因?yàn)楦黝?lèi)需求對(duì)架構(gòu)設(shè)計(jì)的影響截然不同。本文通過(guò)具體案例的分析，展示了如何通過(guò)RUP的4+1視圖方法，針對(duì)不同需求進(jìn)行架構(gòu)設(shè)計(jì)，從而確保重要的需求一一被滿(mǎn)足。
本文重點(diǎn)在于方法的解說(shuō)，因此省略了對(duì)架構(gòu)設(shè)計(jì)中不少具體問(wèn)題的說(shuō)明，同時(shí)本文提供的說(shuō)明架構(gòu)設(shè)計(jì)方案的模型也經(jīng)過(guò)了簡(jiǎn)化。請(qǐng)讀者注意。
|
