《52浙江大學(xué)王燦《軟件體系結(jié)構(gòu)》視頻課程PPT7_構(gòu)架設(shè)計案例(1)》由會員分享,可在線閱讀,更多相關(guān)《52浙江大學(xué)王燦《軟件體系結(jié)構(gòu)》視頻課程PPT7_構(gòu)架設(shè)計案例(1)(25頁珍藏版)》請在裝配圖網(wǎng)上搜索。
1、設(shè)計構(gòu)架 (1)簡短回顧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形成團(tuán)隊結(jié)構(gòu)q創(chuàng)建骨架系統(tǒng)軟件生命周期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)險分析所建立的一種軟件開發(fā)模型。n構(gòu)架在軟件生命周期中處于一
2、個什么位置?演化模型生命周期軟件概念初步的需求分析構(gòu)架和系統(tǒng)核心的設(shè)計交付最終版本獲取客戶反饋開發(fā)一個版本匯總客戶反饋交付該版本何時可以開始構(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)的可用性需求決定構(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個使用案例是對一個
3、系統(tǒng)所執(zhí)行的一系列動作的描述,通常功能屬性的需求都可以由用戶案例表達(dá)屬性驅(qū)動的設(shè)計 (ADD)n ADD是一種設(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)行分配,以實例化由該模塊所提供的模塊類型n ADD結(jié)果:得到一種粗粒度的劃分,即模塊分解視圖和其他視圖的最初的幾個層次q系統(tǒng)被描述為功能和功能之間交互的一組容器案例分析車庫門開關(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)
4、車門的升起或下降n ADD的輸入:一組需求q使用用戶案例表達(dá)的功能需求q限制q使用質(zhì)量屬性場景表達(dá)的質(zhì)量需求案例分析車庫門開關(guān)器 (2)n車庫門系統(tǒng)的質(zhì)量屬性場景q對于產(chǎn)品線中的各種產(chǎn)品而言,用于開門和關(guān)門的設(shè)備和控制裝置是不同的q不同的產(chǎn)品中使用的處理器不同q如果車庫門在下降的過程中檢測到一個障礙物,它必須在0.1秒內(nèi)停止q可以在家庭信息系統(tǒng)內(nèi)使用產(chǎn)品相關(guān)的診斷協(xié)議來診斷和管理車庫門開關(guān)器。因改可以直接產(chǎn)生一個反應(yīng)該協(xié)議的構(gòu)架ADD步驟n 1. 選擇要分解的模塊q從整個系統(tǒng)開始q進(jìn)行分解時,要求所有輸入都是可獲得的n限制條件、功能需求、質(zhì)量需求n 2. 根據(jù)這些步驟對模塊進(jìn)行求精q從具體的質(zhì)
5、量場景和功能需求集合中選擇構(gòu)架驅(qū)動因素q選擇或創(chuàng)建滿足構(gòu)架驅(qū)動因素的構(gòu)架模式,確定所用戰(zhàn)術(shù)需要的子模塊q實例化模塊并根據(jù)使用案例分配功能,使用多個視圖進(jìn)行表示q定義子模塊的接口q驗證使用案例和質(zhì)量場景并對其進(jìn)行求精,使它們成為子模塊的限制n 3. 對需要進(jìn)一步分解的每個模塊重復(fù)上述步驟選擇要分解的模塊n系統(tǒng)分解的步驟:系統(tǒng)子系統(tǒng)子模塊n示例中,系統(tǒng)指的是車庫門開關(guān)器q在這個級別的一個限制是:開關(guān)器必須能與家庭信息系統(tǒng)進(jìn)行交互2.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ū)動
6、因素,它們給出了以下需求n可修改性n實時性能需求n ADD的特點在于,對于模塊的所有需求并非同等對待q通過選擇構(gòu)架驅(qū)動因素,我們將問題簡化為滿足最重要的需求q在滿足最重要的需求的條件下,才滿足不太重要的需求選擇構(gòu)架模式 (1)n對于每個質(zhì)量屬性的需求,在構(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ì)量屬性的平衡選擇構(gòu)架模式 (2)n該步驟的目標(biāo)是建立一個由模塊類型組成的總體構(gòu)架模式n該模式通過組合選定的戰(zhàn)術(shù),滿足構(gòu)架驅(qū)動因素n影響戰(zhàn)術(shù)選擇的兩個因素q驅(qū)
7、動因素本身q實現(xiàn)戰(zhàn)術(shù)的模式對其他質(zhì)量屬性產(chǎn)生的副作用選擇構(gòu)架模式 (3)-示例n比如:q為了達(dá)成系統(tǒng)的可修改性,一個經(jīng)典的戰(zhàn)術(shù)就是使用“解釋器”模式q但是使用解釋器模式會對性能產(chǎn)生較大的負(fù)面影響q是否使用“解釋器”模式依賴于可修改性與性能的重要性對比n一個可行的決策為:對總體模式的部分使用“解釋器”,其他部分則使用其他戰(zhàn)術(shù)選擇構(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ù)
8、為:“語義一致性”和信息隱藏選擇構(gòu)架模式 (5)n性能戰(zhàn)術(shù)回顧q資源需求n提高計算效率q資源仲裁n優(yōu)化調(diào)度算法q資源管理n無論是引入并發(fā),還是維持?jǐn)?shù)據(jù)或計算的備份,還是增加可用資源,都無助于提高車庫門的響應(yīng)速度選擇構(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)需求n應(yīng)用了戰(zhàn)術(shù)后導(dǎo)出的模式q這并非唯一可導(dǎo)出模式q這是一個滿足了需求的模式非關(guān)鍵性能計算虛擬機關(guān)鍵性能計算用戶界面保證
9、時限時間的調(diào)度程序選擇構(gòu)架模式 (7)實例化模塊 (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ù))實例化模塊 (2)診斷通訊虛擬機障礙物檢測用戶接口保證時限時間的調(diào)度程序升/降門傳感器/啟發(fā)器虛擬機分配功能 (1)n該步驟的目的是驗證現(xiàn)有的分解時限所要求的功能q防止功能的遺漏n應(yīng)用與父模塊相關(guān)的用例可以讓
10、構(gòu)架師更詳細(xì)的了解功能的分布情況q可能導(dǎo)致增加或刪除子模塊q父模塊的每個用例都可用子模塊的一系列責(zé)任來表示分配功能 (2)n為分解模塊中的子模塊分配責(zé)任還會幫助發(fā)現(xiàn)必要的信息交換q這必須作為生產(chǎn)者/消費者關(guān)系記錄下來q信息交互的細(xì)節(jié)在這一步并不重要n一些交互將引入模塊間交互的特定模式q比如:發(fā)布/訂閱模式q必須記錄這些模式,對于受影響的模塊而言,它們將轉(zhuǎn)化為責(zé)任用多個視圖表示構(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比如:一個資源管理器用多個視圖表示構(gòu)架 (2)q理解車庫門系統(tǒng)中的并發(fā),要考慮以下用例n兩個用戶同時做類似的事情(用HIS關(guān)門,用開關(guān)關(guān)門)q識別資源競爭或數(shù)據(jù)完整性問題n一個用戶同時執(zhí)行多個活動q揭示數(shù)據(jù)交換和活動控制問題n啟動系統(tǒng)q提供系統(tǒng)初始化的策略和概述n關(guān)閉系統(tǒng)q揭示系統(tǒng)清除(關(guān)機)問題q部署視圖n確定部署到特定硬件上出現(xiàn)的特殊責(zé)任n確定是否需要某些模塊的多個實例