52浙江大學(xué)王燦《軟件體系結(jié)構(gòu)》視頻課程PPT7-構(gòu)架設(shè)計案例(1)

1、2021/8/141設(shè)計構(gòu)架 (1)2021/8/142簡短回顧n在前幾節(jié)課我們學(xué)習(xí)了q構(gòu)架的商業(yè)性方面q構(gòu)架視圖和結(jié)構(gòu)q質(zhì)量屬性q實現(xiàn)質(zhì)量屬性的構(gòu)架戰(zhàn)術(shù)和模式n這些構(gòu)成了我們進(jìn)行構(gòu)架設(shè)計的背景知識q生命周期中的構(gòu)架q設(shè)計構(gòu)架q形成團隊結(jié)構(gòu)q創(chuàng)建骨架系統(tǒng)2021/8/143軟件生命周期n常見的軟件生命周期模型q瀑布模型n瀑布模型將軟件生命周期的各項活動規(guī)定為依固定順序聯(lián)接的若干階段工作，形如瀑布流水，最終得到軟件產(chǎn)品q演化模型n用戶可以給出待開發(fā)系統(tǒng)的核心需求，并且當(dāng)看到核心需求實現(xiàn)后，能夠有效地提出反饋，以支持系統(tǒng)的最終設(shè)計和實現(xiàn)。q螺旋模型 n瀑布模型與演化模型相結(jié)合，并加入兩者所忽略的風(fēng)

2、險分析所建立的一種軟件開發(fā)模型。n構(gòu)架在軟件生命周期中處于一個什么位置？2021/8/144演化模型生命周期軟件概念軟件概念初步的初步的需求分析需求分析構(gòu)架和構(gòu)架和系統(tǒng)核心系統(tǒng)核心的設(shè)計的設(shè)計交付最交付最終版本終版本獲取客獲取客戶反饋戶反饋開發(fā)一開發(fā)一個版本個版本匯總客匯總客戶反饋戶反饋交付交付該版本該版本2021/8/145何時可以開始構(gòu)架設(shè)計n首先要有需求q但我們并不需要太多的需求來開始構(gòu)架設(shè)計n形成構(gòu)架的因素包括q功能需求q質(zhì)量需求q商業(yè)需求n這些需求我們成為構(gòu)架驅(qū)動因素q例如：第三章案例中介紹的A-7E航空電子系統(tǒng)的可修改性和性能需求q第六章案例中的空中交通管制系統(tǒng)的可用性需求2021

3、/8/146決定構(gòu)架驅(qū)動因素n識別構(gòu)架驅(qū)動因素q識別最高優(yōu)先級的商業(yè)目標(biāo)n應(yīng)該只有幾個q將這些商業(yè)目標(biāo)轉(zhuǎn)化為質(zhì)量屬性場景或使用使用案例案例q從中選擇對構(gòu)架產(chǎn)生最大影響的部分n這些就是構(gòu)架驅(qū)動因素n應(yīng)該不多于10個使用案例是對一個系統(tǒng)所執(zhí)行的一系列動作的描述，通常功能屬性的需求都可以由用戶案例表達(dá)2021/8/147屬性驅(qū)動的設(shè)計 (ADD)nADD是一種設(shè)計軟件構(gòu)架的方法，該方法根據(jù)軟件的質(zhì)量屬性需求對系統(tǒng)進(jìn)行分解q一個遞歸的分解過程q系統(tǒng)分解基于系統(tǒng)必須滿足的質(zhì)量屬性q每個階段都選擇戰(zhàn)術(shù)和構(gòu)架模式來滿足一組質(zhì)量屬性的場景，然后對功能進(jìn)行分配，以實例化由該模塊所提供的模塊類型nADD結(jié)果：得到

4、一種粗粒度的劃分，即模塊分解視圖和其他視圖的最初的幾個層次q系統(tǒng)被描述為功能和功能之間交互的一組容器2021/8/148案例分析車庫門開關(guān)器 (1)n目標(biāo)：為家庭信息系統(tǒng)(HIS)中的車庫門開關(guān)器設(shè)計一個產(chǎn)品線構(gòu)架q開關(guān)器負(fù)責(zé)通過開關(guān)、遠(yuǎn)程控制或家庭信息系統(tǒng)來實現(xiàn)車門的升起或下降nADD的輸入：一組需求q使用用戶案例表達(dá)的功能需求q限制q使用質(zhì)量屬性場景表達(dá)的質(zhì)量需求2021/8/149案例分析車庫門開關(guān)器 (2)n車庫門系統(tǒng)的質(zhì)量屬性場景q對于產(chǎn)品線中的各種產(chǎn)品而言，用于開門和關(guān)門的設(shè)備和控制裝置是不同的q不同的產(chǎn)品中使用的處理器不同q如果車庫門在下降的過程中檢測到一個障礙物，它必須在0.1

5、秒內(nèi)停止q可以在家庭信息系統(tǒng)內(nèi)使用產(chǎn)品相關(guān)的診斷協(xié)議來診斷和管理車庫門開關(guān)器。因改可以直接產(chǎn)生一個反應(yīng)該協(xié)議的構(gòu)架2021/8/1410ADD步驟n1. 選擇要分解的模塊q從整個系統(tǒng)開始q進(jìn)行分解時，要求所有輸入都是可獲得的n限制條件、功能需求、質(zhì)量需求n2. 根據(jù)這些步驟對模塊進(jìn)行求精q從具體的質(zhì)量場景和功能需求集合中選擇構(gòu)架驅(qū)動因素q選擇或創(chuàng)建滿足構(gòu)架驅(qū)動因素的構(gòu)架模式，確定所用戰(zhàn)術(shù)需要的子模塊q實例化模塊并根據(jù)使用案例分配功能，使用多個視圖進(jìn)行表示q定義子模塊的接口q驗證使用案例和質(zhì)量場景并對其進(jìn)行求精，使它們成為子模塊的限制n3. 對需要進(jìn)一步分解的每個模塊重復(fù)上述步驟2021/8/1

6、411選擇要分解的模塊n系統(tǒng)分解的步驟：系統(tǒng)子系統(tǒng)子模塊n示例中，系統(tǒng)指的是車庫門開關(guān)器q在這個級別的一個限制是：開關(guān)器必須能與家庭信息系統(tǒng)進(jìn)行交互2021/8/14122.a 選擇構(gòu)架驅(qū)動因素n進(jìn)行分解時，需要從質(zhì)量屬性場景和功能需求中選擇相應(yīng)的構(gòu)架驅(qū)動因素q構(gòu)架驅(qū)動因素在模塊的高優(yōu)先級需求中q在車庫門系統(tǒng)中，已給出的4個場景就是構(gòu)架驅(qū)動因素，它們給出了以下需求n可修改性n實時性能需求nADD的特點在于，對于模塊的所有需求并非同等對待q通過選擇構(gòu)架驅(qū)動因素，我們將問題簡化為滿足最重要的需求q在滿足最重要的需求的條件下，才滿足不太重要的需求2021/8/1413選擇構(gòu)架模式 (1)n對于每個質(zhì)

7、量屬性的需求，在構(gòu)架設(shè)計中，我們都有相應(yīng)的戰(zhàn)術(shù)來實現(xiàn)它q每個戰(zhàn)術(shù)都有相應(yīng)的成本q每個戰(zhàn)術(shù)都可以實現(xiàn)一個或多個質(zhì)量屬性，但是也可能對一些質(zhì)量屬性產(chǎn)生負(fù)面的影響n通常我們會在構(gòu)架設(shè)計中選擇戰(zhàn)術(shù)的組合來實現(xiàn)多個質(zhì)量屬性的平衡2021/8/1414選擇構(gòu)架模式 (2)n該步驟的目標(biāo)是建立一個由模塊類型組成的總體構(gòu)架模式n該模式通過組合選定的戰(zhàn)術(shù)，滿足構(gòu)架驅(qū)動因素n影響戰(zhàn)術(shù)選擇的兩個因素q驅(qū)動因素本身q實現(xiàn)戰(zhàn)術(shù)的模式對其他質(zhì)量屬性產(chǎn)生的副作用2021/8/1415選擇構(gòu)架模式 (3)-示例n比如：q為了達(dá)成系統(tǒng)的可修改性，一個經(jīng)典的戰(zhàn)術(shù)就是使用“解釋器”模式q但是使用解釋器模式會對性能產(chǎn)生較大的負(fù)面影響

8、q是否使用“解釋器”模式依賴于可修改性與性能的重要性對比n一個可行的決策為：對總體模式的部分使用“解釋器”，其他部分則使用其他戰(zhàn)術(shù)2021/8/1416選擇構(gòu)架模式 (4)n按照案例分析中所提到的兩個關(guān)鍵需求：性能和可修改性，我們可以使用學(xué)過的響應(yīng)戰(zhàn)術(shù)來滿足n可修改性戰(zhàn)術(shù)回顧q局部化變更q防止連鎖反應(yīng)q推遲綁定時間n我們的案例中，可修改性場景主要與系統(tǒng)設(shè)計時出現(xiàn)的變更相關(guān)，因此我們可以使用“局部化變更”戰(zhàn)術(shù)q所采用的具體戰(zhàn)術(shù)為：“語義一致性”和信息隱藏2021/8/1417選擇構(gòu)架模式 (5)n性能戰(zhàn)術(shù)回顧q資源需求n提高計算效率q資源仲裁n優(yōu)化調(diào)度算法q資源管理n無論是引入并發(fā)，還是維持?jǐn)?shù)據(jù)

9、或計算的備份，還是增加可用資源，都無助于提高車庫門的響應(yīng)速度2021/8/1418選擇構(gòu)架模式 (6)n最后選定和應(yīng)用的具體戰(zhàn)術(shù)q語義一致性n將處理用戶接口、通訊和傳感器的部分都放入各自單獨的模塊q信息隱藏n為通訊和傳感器模塊使用“虛擬機”技術(shù)，隱藏內(nèi)部實現(xiàn)q提高計算效率n提高關(guān)鍵部分（瓶頸）的計算效率q精心調(diào)度n對關(guān)鍵性能計算進(jìn)行調(diào)度，確保實時響應(yīng)需求2021/8/1419n應(yīng)用了戰(zhàn)術(shù)后導(dǎo)出的模式q這并非唯一可導(dǎo)出模式q這是一個滿足了需求的模式非關(guān)鍵性非關(guān)鍵性能計算能計算虛擬機虛擬機關(guān)鍵性關(guān)鍵性能計算能計算用戶界面用戶界面保證時限時間保證時限時間的調(diào)度程序的調(diào)度程序選擇構(gòu)架模式 (7)202

10、1/8/1420實例化模塊 (1)n前面的步驟確定了模塊的分解結(jié)構(gòu)，接下來要確定如何實例化這些模塊類型n在ADD方法中，功能的分配標(biāo)準(zhǔn)類似于其他設(shè)計方法q實際的系統(tǒng)中往往有多個模塊，每組功能都會有一個模塊n模塊功能實例化q升/降門（沒有時限，非關(guān)鍵性能計算）q診斷（非關(guān)鍵性能計算）q障礙物檢測（有時限，關(guān)鍵性能計算）q通信、傳感等（有可修改性需求，使用“虛擬機”技術(shù)）2021/8/1421實例化模塊 (2)診斷診斷通訊虛擬機通訊虛擬機障礙物檢測障礙物檢測用戶接口用戶接口保證時限時間保證時限時間的調(diào)度程序的調(diào)度程序升升/降門降門傳感器傳感器/啟發(fā)器啟發(fā)器虛擬機虛擬機2021/8/1422分配功能

11、 (1)n該步驟的目的是驗證現(xiàn)有的分解時限所要求的功能q防止功能的遺漏n應(yīng)用與父模塊相關(guān)的用例可以讓構(gòu)架師更詳細(xì)的了解功能的分布情況q可能導(dǎo)致增加或刪除子模塊q父模塊的每個用例都可用子模塊的一系列責(zé)任來表示2021/8/1423分配功能 (2)n為分解模塊中的子模塊分配責(zé)任還會幫助發(fā)現(xiàn)必要的信息交換q這必須作為生產(chǎn)者/消費者關(guān)系記錄下來q信息交互的細(xì)節(jié)在這一步并不重要n一些交互將引入模塊間交互的特定模式q比如：發(fā)布/訂閱模式q必須記錄這些模式，對于受影響的模塊而言，它們將轉(zhuǎn)化為責(zé)任2021/8/1424用多個視圖表示構(gòu)架 (1)n通常使用三種主要的視圖類型中，每種選擇一個視圖來表示構(gòu)架（如果這些視圖的表示還不足夠怎么辦？）q模塊分解視圖n為責(zé)任提供容器；確定模塊間的主要數(shù)據(jù)流關(guān)系q并發(fā)視圖n確定資源競爭、可能出現(xiàn)的死鎖和數(shù)據(jù)一致性問題n可能會發(fā)現(xiàn)模塊的新責(zé)任q比如對臨界資源的并發(fā)訪問q必須在模塊視圖中對這個新責(zé)任進(jìn)行記錄n可能導(dǎo)致新模塊的產(chǎn)生q比如：一個資源管理器2021/8/1425用多個視圖表示構(gòu)架 (2)q理解車庫門系統(tǒng)中的