軟件質(zhì)量保證和管理

Zhu.Kerry@KerryZhu第一頁，共四十五頁。提高軟件設(shè)計質(zhì)量

第13章回顧13.1需求分析的概念

軟件系統(tǒng)的構(gòu)建層次，軟件需求工程過程13.2需求的獲取與分析13.3需求分析建模

結(jié)構(gòu)化分析建模，面向?qū)ο蟮姆治鼋＃艚萁?3.4系統(tǒng)需求的質(zhì)量保證第二頁，共四十五頁。第14章提高軟件設(shè)計質(zhì)量14.1軟件設(shè)計14.2軟件體系結(jié)構(gòu)14.3軟件設(shè)計模式14.4軟件設(shè)計優(yōu)化

14.5一些典型的系統(tǒng)設(shè)計14.6數(shù)據(jù)庫設(shè)計質(zhì)量第三頁，共四十五頁。課程目標(biāo)了解軟件設(shè)計的目標(biāo)理解軟件體系結(jié)構(gòu)的模型掌握軟件設(shè)計模式理解軟件設(shè)計的優(yōu)化了解一些典型的軟件系統(tǒng)設(shè)計第四頁，共四十五頁。14.1軟件設(shè)計設(shè)計模式使得人們可以更加簡單和方便地去復(fù)用成功的軟件設(shè)計和體系結(jié)構(gòu)，從而能夠幫助設(shè)計者更快更好地完成系統(tǒng)設(shè)計。軟件設(shè)計一般分為：體系結(jié)構(gòu)設(shè)計

高層次設(shè)計，將軟件需求轉(zhuǎn)化為數(shù)據(jù)結(jié)構(gòu)和軟件的系統(tǒng)結(jié)構(gòu)，并定義子系統(tǒng)和它們之間的通信或接口。詳細(xì)設(shè)計

過去習(xí)慣成為總體設(shè)計或概要設(shè)計。通過對結(jié)構(gòu)表示進(jìn)行細(xì)化，得到軟件軟件詳細(xì)的數(shù)據(jù)結(jié)構(gòu)和算法。第五頁，共四十五頁。14.1.1軟件設(shè)計的目標(biāo)

軟件體系結(jié)構(gòu)設(shè)計的基本任務(wù)：設(shè)計軟件系統(tǒng)結(jié)構(gòu)數(shù)據(jù)結(jié)構(gòu)及數(shù)據(jù)庫設(shè)計編寫概要設(shè)計文檔概要設(shè)計文檔評審軟件設(shè)計的目標(biāo)具備特征：

可靠性性能和安全性可擴展性可定制性或可移植性可維護(hù)性和可重用性第六頁，共四十五頁。14.1.2軟件設(shè)計評價標(biāo)準(zhǔn)軟件設(shè)計質(zhì)量的分析與評價包含：質(zhì)量屬性、度量以及質(zhì)量分析與評價技術(shù)。區(qū)分軟件設(shè)計的質(zhì)量屬性：

軟件運行時間評價的質(zhì)量屬性；軟件維護(hù)時間評價的質(zhì)量屬性；與體系結(jié)構(gòu)本質(zhì)質(zhì)量相關(guān)的質(zhì)量屬性；軟件設(shè)計度量方法可以分為：面向功能設(shè)計的度量，面向?qū)ο笤O(shè)計度量。軟件設(shè)計的評價工具和技術(shù)：軟件設(shè)計評審，靜態(tài)分析，模擬與原型。軟件設(shè)計模型：由實體空間，過程空間和形式空間組成。第七頁，共四十五頁。軟件系統(tǒng)設(shè)計模型示意圖

第八頁，共四十五頁。軟件設(shè)計評價實體空間標(biāo)準(zhǔn)以源系統(tǒng)做為標(biāo)準(zhǔn)來度量系統(tǒng)設(shè)計模型，是一個軟件設(shè)計最終應(yīng)該附合的標(biāo)準(zhǔn)。它依賴于我們對于源系統(tǒng)的認(rèn)識程度，同時軟件設(shè)計是思維的產(chǎn)物。

過程空間標(biāo)準(zhǔn)可以看作實體空間的間接標(biāo)準(zhǔn)，是基于分析模型和設(shè)計模型來定義。形式空間標(biāo)準(zhǔn)以目標(biāo)系統(tǒng)的角度(即軟件產(chǎn)品質(zhì)量屬性)檢驗系統(tǒng)設(shè)計。實體空間標(biāo)準(zhǔn)和過程空間標(biāo)準(zhǔn)，可以保證目標(biāo)系統(tǒng)的功能滿足源系統(tǒng)。第九頁，共四十五頁。軟件設(shè)計質(zhì)量考察指標(biāo)

設(shè)計結(jié)果的穩(wěn)定性設(shè)計的清晰性設(shè)計合理性系統(tǒng)的模塊結(jié)構(gòu)所顯示的寬度、深度等模塊間松耦合而模塊內(nèi)部又保持高度一致性、穩(wěn)定性是高質(zhì)量軟件設(shè)計的關(guān)鍵之一給出的系統(tǒng)設(shè)計是否滿足軟件需求可測試性和可追溯性所要設(shè)計的系統(tǒng)在整個項目軟件中的地位、作用對各種需求項是否都進(jìn)行了相應(yīng)的設(shè)計分析第十頁，共四十五頁。系統(tǒng)的模塊結(jié)構(gòu)復(fù)雜性描述

第十一頁，共四十五頁。14.1.3軟件設(shè)計原則軟件設(shè)計的思想原則用戶需求遠(yuǎn)比技術(shù)重要需求其實很少改變，改變的是對需求的理解接受變化不要低估軟件規(guī)模的需求在軟件設(shè)計中沒有捷徑可以走任何體系結(jié)構(gòu)都有它自身的優(yōu)點和缺點，設(shè)計模式也一樣軟件設(shè)計的技術(shù)原則開－閉原則單一職責(zé)原則李氏代換原則依賴倒轉(zhuǎn)原則接口隔離原則合成/聚合復(fù)用原則迪米特法則第十二頁，共四十五頁。耦合的表現(xiàn)形式

第十三頁，共四十五頁。系統(tǒng)模塊的內(nèi)聚性第十四頁，共四十五頁。14.2軟件體系結(jié)構(gòu)軟件體系結(jié)構(gòu)：

軟件體系結(jié)構(gòu)為軟件系統(tǒng)提供了一個結(jié)構(gòu)、行為和屬性的高級抽象，由構(gòu)成系統(tǒng)的元素的描述、這些元素的相互作用、指導(dǎo)元素集成的模式以及這這些模式的約束組成。體系結(jié)構(gòu)的模型和視圖體系結(jié)構(gòu)的分類體系結(jié)構(gòu)的設(shè)計異步體系結(jié)構(gòu)的選擇第十五頁，共四十五頁。14.2.1體系結(jié)構(gòu)的模型和視圖體系結(jié)構(gòu)的模型結(jié)構(gòu)模型：以體系結(jié)構(gòu)的構(gòu)件、連接件和其他概念來刻畫結(jié)構(gòu)，并力圖通過結(jié)構(gòu)來反映系統(tǒng)的重要語義內(nèi)容。框架模型：框架模型主要以一些特殊的問題為目標(biāo)建立只針對和適應(yīng)該問題的結(jié)構(gòu)。動態(tài)模型：動態(tài)模型是對結(jié)構(gòu)或框架模型的補充，研究系統(tǒng)的“大顆粒”的行為性質(zhì)。過程模型：研究構(gòu)造系統(tǒng)的步驟和過程。功能模型：由一組功能構(gòu)件按層次組成，下層向上層提供服務(wù)。體系結(jié)構(gòu)的試圖概念試圖邏輯試圖物理試圖第十六頁，共四十五頁。14.2.2體系結(jié)構(gòu)的分類C/S軟件體系結(jié)構(gòu)傳統(tǒng)的二層C/S結(jié)構(gòu)存在局限性。三層C/S結(jié)構(gòu)將應(yīng)用功能分為表示層、功能層和數(shù)據(jù)層。B/S軟件體系結(jié)構(gòu)B/S結(jié)構(gòu)是對C/S結(jié)構(gòu)的一種改進(jìn)。B/S結(jié)構(gòu)和C/S結(jié)構(gòu)比較接近，但也具有自己的特點。中間件的多層分布式的體系結(jié)構(gòu)具有客戶端的表示層、中間的業(yè)務(wù)邏輯層和數(shù)據(jù)庫服務(wù)器的三層或多層體系結(jié)構(gòu)。多層體系結(jié)構(gòu)將客戶和資源分開，降低了服務(wù)器的負(fù)載。多層分布式系統(tǒng)中，不同的組件可以用不同的語言來實現(xiàn)。第十七頁，共四十五頁。14.2.3體系結(jié)構(gòu)的設(shè)計多層分布式體系主要層次在多層體系設(shè)計中，各層次按照一定方式進(jìn)行劃分，實現(xiàn)明確分工。客戶、業(yè)務(wù)服務(wù)、數(shù)據(jù)服務(wù)。多層分布式體系設(shè)計要點安全性、穩(wěn)定性易維護(hù)快速響應(yīng)系統(tǒng)擴展靈活多層分布式體系結(jié)構(gòu)的應(yīng)用開發(fā)要考慮3方面的技術(shù)：開發(fā)環(huán)境、應(yīng)用程序的集成、應(yīng)用程序的配置。系統(tǒng)平臺軟件和終端軟件的體系結(jié)構(gòu)的劃分是以高性能、高可靠性、高安全性、高擴展性和可管理為原則。第十八頁，共四十五頁。14.2.4異步體系結(jié)構(gòu)的選擇異步體系結(jié)構(gòu)優(yōu)點：更快的響應(yīng)時間負(fù)載平衡具有更好的容錯能力支持?jǐn)嗬m(xù)連接的系統(tǒng)異步體系結(jié)構(gòu)缺點：利用通知或輪詢進(jìn)行狀態(tài)跟蹤處理超時創(chuàng)建和執(zhí)行補償邏輯第十九頁，共四十五頁。14.3軟件設(shè)計模式《設(shè)計模式》：設(shè)計模式使得人們可以更加簡單和方便地去復(fù)用成功的軟件設(shè)計和體系結(jié)構(gòu)，從而能夠幫助設(shè)計者更快更好地完成系統(tǒng)設(shè)計?！督ㄖ挠篮惴椒ā罚耗Ｊ绞且粭l由三部分組成的規(guī)則，它表示了一個特定環(huán)境、一個問題和一個解決方案之間的關(guān)系。每一個模式描述了一個在我們周圍不斷重復(fù)發(fā)生的問題，以及該問題的解決方案的核心。這樣，你就能一次又一次地使用該方案而不必做重復(fù)勞動。第二十頁，共四十五頁。14.3.1設(shè)計模式的分類創(chuàng)建型模式創(chuàng)建型模式抽象了實例化過程。它們幫助一個系統(tǒng)獨立于如何創(chuàng)建、組合和表示它的那些對象。結(jié)構(gòu)型模式結(jié)構(gòu)型類模式采用繼承機制來組合接口或?qū)崿F(xiàn)，描述了如何對一些對象進(jìn)行組合，從而實現(xiàn)新功能的一些方法。行為模式行為模式涉及到算法和對象間職責(zé)的分配。行為模式不僅描述對象或類的模式，還描述它們之間的通信模式。行為模式使用繼承機制在類間分派行為。第二十一頁，共四十五頁。設(shè)計模式分類分類具體種類描述創(chuàng)建型模式抽象工廠提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，而無需指定它們具體的類。

生成器將一個復(fù)雜對象的構(gòu)建與它的表示分離，使得同樣的構(gòu)建過程可以創(chuàng)建不同的表示。工廠方法定義一個用于創(chuàng)建對象的接口，讓子類決定實例化哪一個類。FactoryMethod使一個類的實例化延遲到其子類。原型用原型實例指定創(chuàng)建對象的種類，并且通過拷貝這些原型創(chuàng)建新的對象。

單件保證一個類僅有一個實例，并提供一個訪問它的全句訪問點。結(jié)構(gòu)型模式適配器將一個類的接口轉(zhuǎn)換成客戶希望的另外一個接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些類可以一起工作橋接將抽象部分與它的實現(xiàn)部分分離，使它們都可以獨立的變化組合將對象組合成樹形結(jié)構(gòu)以表示“部分－整體”的層次結(jié)構(gòu)。Composite使得用戶單個對象和組合對象的使用具有一致性裝飾動態(tài)的給一個對象添加一些額外的職責(zé)。就增加功能來說，Decorator模式相比生成子類更為靈活外觀為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)a?ade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用享元運用共享技術(shù)有效的支持大量細(xì)粒度的對象代理為其他對象提供一種代理以控制對這個對象的訪問第二十二頁，共四十五頁。設(shè)計模式分類分類具體種類描述行為型模式職責(zé)鏈?zhǔn)苟鄠€對象都有機會處理請求，從而避免請求的發(fā)送者和接收者之間的耦合關(guān)系。將這些對象連成一條鏈，并沿著這條鏈傳遞該請求，直到有一個對象處理它為止。命令將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進(jìn)行參數(shù)化；對請求排對或記錄請求日志，以及支持可撤銷的操作。解釋器給定一個語言，定義它的文法的一種表示，并定義一個解釋器，這個解釋器使用該表示來解釋語言中的句子。迭代器提供一種方法順序訪問一個聚合對象中各個元素，而又不需要暴露該對象的內(nèi)部表示。中介者用一個中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式的相互引用，從而使其耦合松散，而且可以獨立的改變它們之間的交互。備忘錄在不破壞封裝性的前提下，捕獲一個對象的內(nèi)部狀態(tài)，并在該對象之外保存這個狀態(tài)。這樣以后就可將該對象恢復(fù)到原先保存的狀態(tài)。觀察者定義對象間的一種一對多的依賴關(guān)系，當(dāng)一個對象的狀態(tài)發(fā)生改變時，所有依賴于它的對象都得到通知并被自動更新。狀態(tài)允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。對象看起來似乎修改了它的類。策略允許一個對象在其內(nèi)部狀態(tài)改變時改變它的行為。模板方法定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。訪問者表示一個作用于某對象結(jié)構(gòu)中的各元素的操作。第二十三頁，共四十五頁。14.3.2MVC模型模型：是封裝數(shù)據(jù)和所有基于對這些數(shù)據(jù)的操作。視圖：是封裝對數(shù)據(jù)的顯示、即用戶界面?？刂破鳎菏欠庋b外界作用于模型的操作和對數(shù)據(jù)流向的控制。MVC設(shè)計模式將模型、視圖與控制器分隔開來。MVC設(shè)計模式實現(xiàn)過程：控制器創(chuàng)建模型；控制器創(chuàng)建一個或多個視圖，并將它們與模型相關(guān)聯(lián)；控制器負(fù)責(zé)改變模型的狀態(tài)；當(dāng)模型的狀態(tài)發(fā)生改變時，模型會通知與之相關(guān)的視圖進(jìn)行更新。第二十四頁，共四十五頁。UML表示MVC設(shè)計模式第二十五頁，共四十五頁。14.3.3設(shè)計模式的作用設(shè)計模式有4個基本要素：

模式名稱：描述模式的問題、解決方案和效果；

問題：描述了應(yīng)該在何時使用模式；

解決方案：描述了設(shè)計的組成部分之間的相互關(guān)系、職責(zé)和協(xié)作方式。

效果：描述了模式應(yīng)用的效果及使用模式應(yīng)權(quán)衡的問題。設(shè)計模式在工程小組成員之間提供了通用的語義。設(shè)計模式可以更加簡單方便的復(fù)用成功的設(shè)計和體系結(jié)構(gòu)。設(shè)計模式有助于作出有利于系統(tǒng)復(fù)用的選擇，避免設(shè)計損害系統(tǒng)復(fù)用性。設(shè)計模式可以幫助設(shè)計者更快更好的完成系統(tǒng)設(shè)計第二十六頁，共四十五頁。14.3.4通過UML改善功能設(shè)計UML是一種直觀化、明確化、構(gòu)建和文檔化軟件系統(tǒng)產(chǎn)物的通用可視化建模語言。設(shè)計階段分為結(jié)構(gòu)設(shè)計和詳細(xì)設(shè)計。結(jié)構(gòu)設(shè)計是定義包，包括包間的依賴性和主要通信機制。詳細(xì)設(shè)計是通過創(chuàng)建新的類圖、狀態(tài)圖和動態(tài)圖，描述新的技術(shù)類、并擴展和細(xì)化分析階段。UML設(shè)計可以規(guī)格說明更直觀、更清晰。系統(tǒng)設(shè)計分為硬件設(shè)計及軟件設(shè)計。使用UML的Collaboration圖和Component圖分別對系統(tǒng)的硬、軟件進(jìn)行系統(tǒng)分析。除了使用UML框圖外，還需要使用StateChart、Sequence框圖描述具體的系統(tǒng)流程細(xì)節(jié)。第二十七頁，共四十五頁。14.4軟件設(shè)計優(yōu)化14.4.1模塊設(shè)計和接口設(shè)計的要求14.4.2詳細(xì)設(shè)計的要求14.4.3界面設(shè)計的要求第二十八頁，共四十五頁。14.4.1模塊設(shè)計和接口設(shè)計的要求模塊設(shè)計準(zhǔn)則：模塊的劃分是合適、模塊與模塊之間是否具有一定的獨立性每個模塊的功能和接口定義是否正確數(shù)據(jù)結(jié)構(gòu)的定義是否正確

模塊內(nèi)的數(shù)據(jù)流和控制流的定義是否正確接口設(shè)計準(zhǔn)則：用戶接口設(shè)計是否正確全面，是否有單獨的用戶界面設(shè)計文檔

是否包含有硬件接口設(shè)計，硬件接口設(shè)計是否正確且全面概要設(shè)計規(guī)格說明是否包含有軟件接口設(shè)計，軟件接口設(shè)計是否正確且全面是否包含有通信接口設(shè)計，通信接口設(shè)計是否正確且全面

是否描述了各類接口的功能、各接口與其他接口或模塊之間的關(guān)系已經(jīng)接口的設(shè)計是否具有可測試性

第二十九頁，共四十五頁。14.4.2詳細(xì)設(shè)計的要求詳細(xì)設(shè)計的目標(biāo)任務(wù)：為每個模塊確定采用的算法確定每一模塊使用的數(shù)據(jù)結(jié)構(gòu)確定模塊接口的細(xì)節(jié)為每一個模塊設(shè)計出一組測試用例詳細(xì)設(shè)計的原則：模塊的邏輯描述要清晰易讀、準(zhǔn)確可靠采用結(jié)構(gòu)化設(shè)計方法，改善控制結(jié)構(gòu)詳細(xì)設(shè)計的表示方法：流程圖偽碼IPO圖PAD判定表（樹）第三十頁，共四十五頁。5種軟件詳細(xì)設(shè)計表示方法比較第三十一頁，共四十五頁。14.4.3界面設(shè)計的要求用戶界面設(shè)計原則：用戶界面必須保持一致性用戶界面應(yīng)有自助功能用戶界面易懂性Windows界面設(shè)計規(guī)則：易用性規(guī)范性幫助設(shè)施美觀與協(xié)調(diào)性獨特性快捷方式的組合錯誤保護(hù)第三十二頁，共四十五頁。14.5一些典型的系統(tǒng)設(shè)計14.5.1J2EE系統(tǒng)的設(shè)計14.5.2.Net系統(tǒng)的設(shè)計第三十三頁，共四十五頁。14.5.1J2EE系統(tǒng)的設(shè)計J2EE系統(tǒng)的結(jié)構(gòu)：運行在客戶端機器上的客戶層組件運行在J2EE服務(wù)器上的Web層組件運行在J2EE服務(wù)器上的業(yè)務(wù)邏輯層組件運行在EIS服務(wù)器上的企業(yè)信息系統(tǒng)層軟件J2EE的模型－視圖－控制體系結(jié)構(gòu)J2EE設(shè)計模式：前端控制器數(shù)據(jù)訪問對象模式值對象模式截取過濾器會話面模式視圖幫助器第三十四頁，共四十五頁。J2EE系統(tǒng)結(jié)構(gòu)

客戶層瀏覽器PureHtmlJavaAppletApplicationClientApplicationClientContainerWeb層Web服務(wù)器JSPJSPServletJ2EEPlatform商業(yè)邏輯層EJB容器EJBEJBJ2EEPlatform企業(yè)信息系統(tǒng)層數(shù)據(jù)庫數(shù)據(jù)庫EIS服務(wù)器J2EE服務(wù)器客戶機第三十五頁，共四十五頁。14.5.2.Net系統(tǒng)的設(shè)計邏輯層邏輯應(yīng)用程序體系結(jié)構(gòu)將任何系統(tǒng)都視為一組相互協(xié)作的服務(wù)，這些服務(wù)分為用戶服務(wù)、業(yè)務(wù)服務(wù)和數(shù)據(jù)服務(wù)。物理部署模型Web服務(wù)器用作應(yīng)用程序服務(wù)器遠(yuǎn)程應(yīng)用程序?qū)覣SP.Net結(jié)構(gòu)是一個3層系統(tǒng)：UI層、業(yè)務(wù)邏輯層、數(shù)據(jù)層第三十六頁，共四十五頁。ASP.Net的系統(tǒng)結(jié)構(gòu)模型

第三十七頁，共四十五頁。J2EE與.Net的比較第三十八頁，共四十五頁。14.6數(shù)據(jù)庫設(shè)計質(zhì)量數(shù)據(jù)庫設(shè)計步驟：需求分析概念設(shè)計邏輯設(shè)計物理設(shè)計對數(shù)據(jù)庫進(jìn)行質(zhì)量控制方面劃分為：數(shù)據(jù)層的需求和構(gòu)建數(shù)據(jù)字典設(shè)計數(shù)據(jù)庫數(shù)據(jù)流設(shè)計第三十九頁，共四十五頁。14.6.1數(shù)據(jù)層的需求和構(gòu)建創(chuàng)建軟件系統(tǒng)結(jié)構(gòu)分為：

數(shù)據(jù)層：代表物理數(shù)據(jù)庫。實現(xiàn)數(shù)據(jù)網(wǎng)絡(luò)交互共享的基礎(chǔ)。

業(yè)務(wù)層：負(fù)責(zé)數(shù)據(jù)層與表示層之間的數(shù)據(jù)傳輸。

表示層：應(yīng)用程序的客戶端，通過業(yè)務(wù)層來訪問數(shù)據(jù)庫。數(shù)據(jù)是軟件系統(tǒng)的核心，數(shù)據(jù)層是系統(tǒng)與數(shù)據(jù)庫打交道的唯一一個地方數(shù)據(jù)層被分為：

數(shù)據(jù)訪問元數(shù)據(jù)：描述數(shù)據(jù)的存取方法的數(shù)據(jù)，為系統(tǒng)的每一個存取數(shù)據(jù)邏輯提供描述。

數(shù)據(jù)訪問層：是一個組件，管理數(shù)據(jù)庫驅(qū)動，為上層提供簡單一致的接口執(zhí)行調(diào)用。

數(shù)據(jù)提供層：使用數(shù)據(jù)訪問層執(zhí)行數(shù)據(jù)的CRUD操作，使用數(shù)據(jù)訪問元數(shù)據(jù)控制數(shù)據(jù)調(diào)用指令第四十頁，共四十五頁。14.6.2數(shù)據(jù)字典數(shù)據(jù)字典存儲了各種模式和相應(yīng)的映象。對數(shù)