軟件工程東北大學信息科學與工程學院課件

軟件工程CollegeofInformationScience&Engineering,NEU,2007郭軍E-Mail:neu@,boatheader@126.com高巖E-Mail:gaoyan_neu@126.com,gaoyan_neu@163.com1整體概述THEFIRSTPARTOFTHEOVERALLOVERVIEW,PLEASESUMMARIZETHECONTENT第一部分Chapter1軟件工程概述1.1軟件的概念1.2為什么學習軟件工程1.3什么是軟件工程1.4課程結構1.5參考書目1.6教材案例-在線寵物商店31.1軟件的概念(1/2)軟件:新的驅動力Intheearly1980s,afrontpagestoryinBusinessWeekmagazineBanking&FinanceGovernmentInsuranceManufacturingMedia&PublishingRetailTravelUtilities

19501960197019801990200541.1軟件的概念(2/2)定義Program+DataStructure+Documents

──WangJiahua,軟件工程,pp.1軟件的性質復雜性難以描述性不可見性變化性風險性易于副本的大批量生產強合作性51.2為什么學習軟件工程(1/4)軟件危機爆發(fā)時間1967年NATO的研究組首次提出1968年NATO軟件工程會議首次提出軟件工程概念1968-2006,近40年“危機”一詞軟件危機依然存在Crisis！61.2為什么學習軟件工程(2/4)軟件危機面對的問題藝術vs.標準化錯誤的發(fā)現(xiàn)軟件需求獲取軟件支持和維護開發(fā)速度vs.市場需求開發(fā)周期過長、開發(fā)成本過高研發(fā)風險軟件Trouble軟件開發(fā)中的復雜的協(xié)作(人員,問題,過程)不同角色的軟件神話(管理者,用戶,開發(fā)者,大眾)71.2為什么學習軟件工程(3/4)采用什么方法緩解危機硬件?建筑學?拍電影?……軟件工程！81.2為什么學習軟件工程(4/4)挑戰(zhàn)91.3什么是軟件工程(1/4)FritzBauer:“建立和應用完善的工程原理以便經濟地得到在真實機器上可靠和有效運行的軟件重原理、輕技術、無度量IEEE：(1)應用系統(tǒng)的有規(guī)則的定量的方法開發(fā)、使用和維護軟件；即應用工程于軟件。(2)研究(1)中的方法粗糙101.3什么是軟件工程(2/4)Definition軟件工程是以質量為核心，為了經濟地開發(fā)滿足客戶需求的軟件而研究、建立和應用的系統(tǒng)化的、有規(guī)則的、可度量的和可控制的工程原則、方法，涉及到軟件過程、項目管理、開發(fā)方法、軟件復用、軟件度量、開發(fā)工具，甚至企業(yè)文化等各個方面。

──GuoJun111.3什么是軟件工程(3/4)發(fā)展歷程(1)121.3什么是軟件工程(4/4)發(fā)展歷程(2)131.4課程結構(1/2)Chapter1 軟件工程概述Chapter2 過程和活動Chapter3 軟件過程模型Chapter4 問題定義和可行性研究的方法Chapter5 需求分析方法Chapter6 軟件設計方法Chapter7 軟件實施和測試方法Chapter8 項目管理方法141.4課程結構(2/2)實驗教學主要內容需求采集，角色分配，制定計劃(4)系統(tǒng)分析與設計(4)系統(tǒng)分包與集成，配置管理(4)系統(tǒng)測試與交付(4)基于團隊合作的項目模擬開發(fā)(8)151.5參考書目(1/2)教材軟件工程及應用/東北大學出版社2007年5月參考推薦軟件工程/東北大學出版社/

王家華/中面向對象的軟件工程/機械出 版社/TimothyC.Lethbridge/加161.5參考書目(2/2)171.6教材案例-在線寵物商店(1/3)寵物大戰(zhàn)SUNVs.Microsoft主要功能：列舉寵物商品類別和提供搜索功能顯示寵物列表和寵物具體信息提供用戶登錄驗證、注冊新用

戶和維護用戶信息等功能管理購物車實現(xiàn)結帳處理查詢訂貨情況統(tǒng)計銷售記錄181.6教材案例-在線寵物商店(2/3)問題(1/2):從何開始？采用什么技術？需要多少時間？需要多少人？哪些角色？能否并行、協(xié)作地開發(fā)？人力應該如何高效率的投入？開發(fā)計劃？直接編碼？需求？設計方案和模型？人機交互的界面？功能優(yōu)先級？

191.6教材案例-在線寵物商店(3/3)問題(2/2):開發(fā)風險？可擴展性？復用？設計模式？編碼規(guī)范？需求變更？測試？開發(fā)過程？軟件度量？最后期限？20Chapter2過程和活動2.1軟件過程的概念2.2問題定義活動2.3可行性研究活動2.4需求分析活動2.5設計活動2.6實施活動2.7測試活動2.8部署活動212.1軟件過程的概念(1/9)軟件工程是一種層次化的技術

AQualityFocusProcessMethodsCASETools222.1軟件過程的概念(2/9)軟件過程的定義軟件過程由開發(fā)或維護軟件及其相關產品的一系列活動構成，這些活動從不同的方面定義了軟件開發(fā)中的步驟、交付物、涉眾及其職責等流程要素232.1軟件過程的概念(3/9)為什么要引入軟件過程？(1/2)軟件工作的范圍軟件的開發(fā)風險（規(guī)模、周期、復雜度）涉及整個軟件生存周期擴展到少，可預知、可控多，不易預知，不易控制發(fā)展到只考慮

編寫程序242.1軟件過程的概念(4/9)為什么要引入軟件過程？(2/2)軟件開發(fā)的角色軟件標準團隊中更多的角色擴展到軟件產品的標準化軟件開發(fā)過程的標準化擴展到程序員252.1軟件過程的概念(5/9)Buildthe

System控制

預算,計劃表,標準輸入需求

資源

人員,工具輸出代碼,文檔Process控制/約束輸入資源輸出262.1軟件過程的概念(6/9)WhatHowChange272.1軟件過程的概念(7/9)282.1軟件過程的概念(8/9)BasicActivities(基礎活動)問題定義，需求，規(guī)約，設計，實現(xiàn)，

軟件驗證，集成，軟件演進/維護，退役UmbrellaActivities(輔助性活動)軟件項目跟蹤和控制，正式的技術復審，

軟件質量保證，軟件配置管理，文檔編制，復用管理，度量，風險管理，…Somethingthatcoversorprotects.保護物覆蓋或保護的事物292.1軟件過程的概念(9/9)公共過程框架CommonProcessFrameworkFrameworkActivitiesTaskSetsTasksMilestones,deliverablesSQApointsUmbrellaActivities302.2問題定義活動(1/3)What問題定義是軟件開發(fā)過程當中的一個定義要解決的問題并確定系統(tǒng)范圍的活動。Why形成一個早期判斷，達成一個最初共識When 項目日程表的最前端占整個軟件開發(fā)時間中的比例很小312.2問題定義活動(2/3)Who系統(tǒng)分析師、出資方領導、出資方技術人員、開發(fā)方領導和項目經理Where客戶現(xiàn)場 322.2問題定義活動(3/3)How332.3可行性研究活動(1/3)What可行性研究是以相對短的時間和相對低的成本來確定給定的問題在其約束條件內是否有解、有幾種解以及哪個是最佳解。Why必須要先確立滿足約束條件的方案是否存在、是否可行、是否最優(yōu)，然后再在最優(yōu)方案的基礎上進行開發(fā)342.3可行性研究活動(2/3)When項目的早期階段占整個軟件開發(fā)時間中的比例較小，但比問題定義活動所消耗的時間長Who系統(tǒng)分析師、出資方領導、出資方技術人員、用戶代表、開發(fā)方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（SQA，SoftwareQualityAssure）人員等Where客戶現(xiàn)場。352.3可行性研究活動(3/3)HowHow(1/2)362.4需求分析活動(1/7)What(1/3)需求：主要是在產品構建之前確定的系統(tǒng)必須符合的條件或具備的功能，它們是關于系統(tǒng)將要完成什么工作的一段描述語句，它們必須經過所有相關人員的認可，其目的是徹底地解決客戶的問題。需求文檔一組需求的集合用戶需求文檔、系統(tǒng)需求文檔和軟件規(guī)約文檔372.4需求分析活動(2/7)What(2/3)382.4需求分析活動(3/7)功能性需求和非功能性需求功能性需求：描述了系統(tǒng)應該做什么，即具備的功能或服務。（輸入、輸出和計算等）非功能性需求：描述了系統(tǒng)必須遵守的約束條件。（響應時間、吞吐量、可靠性、可移植性、可擴展性、易用性、安全性、資源要求、可復用性、技術要求、文化和政策需求、法律需求、道德要求、隱私要求，等等）描述需求的標準是完整的、正確的、必要的、無歧義的、可行的、可驗證的以及被設置了優(yōu)先級別的。What(3/3)392.4需求分析活動(4/7)Why需求不一致、模糊、矛盾需求變更客戶忽略領域常識/知識/術語客戶集中于現(xiàn)有系統(tǒng)的不足之處，而忽略了系統(tǒng)要實現(xiàn)的關鍵功能零碎、無組織、不明確、表達不清不分輕重緩急402.4需求分析活動(5/7)When項目的早期階段？貫穿于整個軟件開發(fā)過程的需求活動412.4需求分析活動(6/7)Who系統(tǒng)分析師、需求闡釋者、客戶代表、用戶代表、開發(fā)方領導、項目經理、架構設計師、領域專家、財務人員、市場人員、軟件質量保證（SQA，SoftwareQualityAssure）人員、程序員、測試人員、部署人員、技術文檔編寫人員、培訓人員等。Where調研時，在客戶現(xiàn)場編纂軟件需求規(guī)約文檔時，可以在開發(fā)單位復審相關的需求文檔時，根據(jù)需要來安排422.4需求分析活動(7/7)How432.5設計活動(1/7)What設計：是在系統(tǒng)的約束條件下（如預算、時間、人力資源、用戶軟、硬件環(huán)境和用戶對系統(tǒng)的操作能力等），為了實現(xiàn)系統(tǒng)的功能性需求和非功能性需求，而找到并描述的一種遵循高質量的通用原則的方法，其交付文檔能夠指導開發(fā)人員實現(xiàn)系統(tǒng)。442.5設計活動(2/7)總體設計任務是根據(jù)軟件需求規(guī)約文檔，確定一個合理的軟件體系結構。這個體系結構包括合理地劃分組成系統(tǒng)的模塊、模塊間的調用關系以及模塊間的接口關系。軟件體系結構還從總體方面決定了系統(tǒng)的可擴充性、可維護性，以及系統(tǒng)的性能等?？傮w設計的設計粒度較大，有時也被稱為概要設計、架構設計。452.5設計活動(3/7)詳細設計詳細設計地任務是在總體設計的基礎上進一步確定如何實現(xiàn)目標系統(tǒng)，包括系統(tǒng)的數(shù)據(jù)對象的設計、人機接口的設計以及模塊邏輯的詳細設計。設計部件的粒度系統(tǒng)、子系統(tǒng)、框架、構件、組件、模塊、類、方法等462.5設計活動(4/7)Why軟件架構是軟件系統(tǒng)的核心應對復雜多變的情況，同時保持完整性應對系統(tǒng)在擴展功能當中出現(xiàn)的問題大規(guī)模復用的有效基礎項目管理的基礎472.5設計活動(5/7)When項目的中、早期階段？工作量早期中期后期項目時間大小貫穿于整個軟件開發(fā)過程的設計活動482.5設計活動(6/7)Who主要包括架構設計師、軟件設計員、復用工程師、設計復審員、項目經理、財務人員、軟件質量保證（SQA，SoftwareQualityAssure）人員和需求變更者等Where建議在軟件企業(yè)內部進行設計492.5設計活動(7/7)How502.6實施活動(1/5)What編碼：是將軟件設計結果轉換成用某種程序設計語言書寫的程序。單元測試：是把一個模塊作為獨立的程序單元進行測試，以保證它能夠正確執(zhí)行規(guī)定的功能。集成：是指將單獨的軟件構件合并成一個整體的軟件系統(tǒng)。集成分為集成子系統(tǒng)和集成系統(tǒng)兩個級別：512.6實施活動(2/5)Why以實施為中心的軟件開發(fā)弱化的需求弱化的設計對實施人員的過度依賴對實施活動的輕視需要的時間進入工作狀態(tài)具有技術含量水平存在差異實施質量不易度量522.6實施活動(3/5)Why將單元測試作為實施的一部分When項目的中、后期階段工作量早期中期后期項目時間大小貫穿于整個軟件開發(fā)過程的實施活動532.6實施活動(4/5)Who包括實施員、代碼復審員、集成員、測試工程師、測試員、項目經理、架構設計師、軟件設計員、復用工程師、SQA人員和財務人員等Where建議在軟件企業(yè)內部進行開發(fā)542.6實施活動(5/5)How552.7測試活動(1/6)What測試：是選擇適當?shù)臏y試用例執(zhí)行被測程序的過程，其目的在于發(fā)現(xiàn)程序錯誤。缺陷：是系統(tǒng)任一方面（包括需求、設計或代碼）的缺點。該缺點會促成或潛在的促成一個或多個失敗發(fā)生。錯誤：是指程序中的缺陷所產生的不正確結果。失?。寒斠粋€程序不能運行或者其表現(xiàn)不可被接受時稱為失敗。失敗是系統(tǒng)執(zhí)行中出現(xiàn)的情況。失敗源于代碼缺陷。單元測試、集成測試、系統(tǒng)測試、α(alpha)、β(Beta)、驗收測試562.7測試活動(2/6)質量維度：描述質量的概念或評測質量的方法的不同視角可靠性維度可靠性維度性能維度測試用例：為特定目標開發(fā)的測試輸入、執(zhí)行條件和預期結果的集合。 572.7測試活動(3/6)Why及時檢查出項目中的缺陷和不足保證所開發(fā)的軟件能夠達到用戶滿意測試是項目管理的重要內容582.7測試活動(4/6)When項目的后期階段？優(yōu)點縮短測試時間易于定位缺陷避免錯上加錯工作量早期中期后期項目時間大小592.7測試活動(5/6)Who主要包括測試工程師、測試員、軟件設計員、實施員、項目經理、部署工程師、部署員、SQA人員和財務人員等Where建議單元測試、集成測試和系統(tǒng)測試在實施員所在的開發(fā)現(xiàn)場及其附近進行β測試和驗收測試則完全在用戶現(xiàn)場測試602.7測試活動(6/6)How612.8部署活動(1/6)What部署：是為確保最終用戶可以正常使用軟件產品而進行的活動。根據(jù)產品類型，可以將部署分為三種模式:自定義安裝模式現(xiàn)場支持模式Internet模式622.8部署活動(2/6)部署單元：由一個工作版本（可執(zhí)行構件集）、文檔（最終用戶支持材料和發(fā)布說明）和安裝工件組成部署計劃：說明如何將產品從開發(fā)商轉移到用戶群兼容、轉換和遷移策略部署時間表部署順序用戶培訓632.8部署活動(3/6)Why用戶的應用環(huán)境和項目團隊的開發(fā)環(huán)境往往不同，需要進行調試、“磨合數(shù)據(jù)或程序遷移培訓服務和使用支持642.8部署活動(4/6)When項目的后期階段？工作量早期中期后期項目時間大小652.8部署活動(5/6)Who主要包括部署工程師、部署員、文檔編寫員、包裝員、實施員、項目經理、SQA人員和財務人員等Where一部分工作可以在開發(fā)現(xiàn)場進行，如制定部署計劃、包裝產品、編寫相關文檔等；另一部分工作必須在用戶現(xiàn)場進行，如β測試、驗收測試和用戶正式使用中的安裝、培訓工作等。662.8部署活動(6/6)How67Chapter3軟件過程模型3.1過程模型概念3.2線形順序模型系列3.3演進模型系列3.4其它模型系列3.5過程模型的選擇683.1過程模型概念(1/5)為什么需要模型?模型幫助我們解釋事物

如何工作模型能夠拓寬我們的視野

(抽象)軟件過程模型一個過程模型是一個過程的抽象表示過程模型幫助我們更好地理解軟件開發(fā)693.1過程模型概念(2/5)703.1過程模型概念(3/5)713.1過程模型概念(4/5)723.1過程模型概念(5/5)經典模型LinearSequentialModelWaterfallModelVModelDepartmentofDefense

ModelRADModelTheCircularModelPrototypingModelBuild-and-FixModel

IncrementalModelSpiralModelConcurrentDevelopmentModelXPModelRUPModelCBDAssemblyModelFormalMethodsModelIDEALModel733.2線形順序模型系列(1/7)線性順序模型analysisdesigncodetestSystem/information

engineering743.2線形順序模型系列(2/7)瀑布模型75763.2線形順序模型系列(4/7)V模型773.2線形順序模型系列(5/7)國防部模型783.2線形順序模型系列(6/7)圓形模型793.2線形順序模型系列(7/7)RAD(RapidApplicationDevelopment)模型60~90days803.3演進模型系列(1/12)原型模型Listento

customerbuild/revise

mock-upcustomertest

-drivesmock-up813.3演進模型系列(2/12)邊建邊改ModelBuildfirst

versionModifyuntil

clientissatisfiedMaintenance

phaseRetirementDevelopmentMaintenance823.3演進模型系列(3/12)邊建邊改Model(續(xù))833.3演進模型系列(4/12)增量模型System/InformationengineeringanalysisdesignCodetestIncrement1Deliveryof1stincrementanalysisdesignCodetestIncrement2Deliveryof2stincrementanalysisdesignCodetestIncrement3Deliveryof3stincrementanalysisdesignCodetestIncrement4Deliveryof4stincrementCalendarTime843.3演進模型系列(5/12)Customer

CommunicationRiskAnalysisEngineeringConstruction&ReleasePlanningCustomer

EvaluationProjectentry

Pointaxis螺旋模型853.3演進模型系列(6/12)并發(fā)模型NoneUnderdevelopmentUnderreviewAwaitingchangesUnderrevisionBaselinedDoneAnalysisactivity863.3演進模型系列(7/12)XP模型873.3演進模型系列(8/12)RUPModel883.3演進模型系列(9/12)RUPModel迭代式生命周期893.3演進模型系列(10/12)RUPModel項目階段和里程碑903.3演進模型系列(11/12)RUPModelRUP各階段工作量和進度分配（中等規(guī)模項目）一個典型的分配方案913.3演進模型系列(12/12)RUPModelRUP開發(fā)周期和演進周期923.4其它模型系列(1/5)構件組裝模型與瀑布模型對比933.4其它模型系列(2/5)構件組裝模型(螺旋版)IdentifycandidatecomponentsLookupcomponentsinlibraryExtractcomponentsifavailableConstructnthiterationofsystemPutnewcomponentsinlibraryBuildComponentsifunavailableCustomer

CommunicationRiskAnalysisEngineeringConstruction&ReleaseCustomer

EvaluationPlanning943.4其它模型系列(3/5)應用構件提取車間構件生產車間標準規(guī)范與質量保證1基礎構件，2功能構件3接口構件，4用戶界面構件應用構件庫構件庫組裝車間領域1領域2應用系統(tǒng)...1234953.4其它模型系列(4/5)形式化方法模型Requirements

definitionFormal

specificationFormal

transformationIntegrationand

systemtesting963.4其它模型系列(5/5)EstablishimprovementinfrastructureLearningEstablishingActingStimulusforchangeSetcontextBuildsponsorshipCharacterizecurrentanddesiredstatesDeveloprecommend-ationsSetprioritiesDevelopapproachPlanactionsCreatesolutionPilot/testsolutionRefinesolutionImplementsolutionAnalyzeandvalidateProposefutureactionsDiagnosingInitiatingIDEALModel973.5過程模型的選擇(1/2)軟件工程過程模型的選擇是基于:項目的應用特點采用的方法和工具需要的控制交付的產品9899Chapter4問題定義和可行性研究的方法4.1可行性研究的內容4.1成本/效益分析4.2相關文檔規(guī)范1004.1可行性研究的內容(1/1)1014.2成本/效益分析(1/6)運營效益≧啟動成本+運營成本啟動成本指為了建立新系統(tǒng)所支付的一次性開支運營成本指為了維持這個系統(tǒng)的運行所發(fā)生的費用運營效益指正式運行系統(tǒng)后能夠產生的收益1024.2成本/效益分析(2/6)投資回收分析法缺點：忽略了資金的時間因素凈資金現(xiàn)值法貨幣的時間價值1034.2成本/效益分析(3/6)凈資金現(xiàn)值法資金現(xiàn)值的使用承認了貨幣的時間價值例：小型機的折舊期限為8年，某公司的計算機系統(tǒng)總投資400萬元，項目計劃用2年時間完成，第1年投資300萬元，第2年投資100萬元。系統(tǒng)投入運行后每年運行費用為20萬元，經和財務人員共同估算每年可得效益376萬元。假定以后每年的費用與效益都相同。假定銀行利率為9%。1044.2成本/效益分析(4/6)例：獲得總經濟效益為1073.5萬元。投資回收期=2+1+92.1/274.9=3.3（年）1054.2成本/效益分析(5/6)成本/效益比較凈資金現(xiàn)值系數(shù)例：假定方案A和方案B都可行。方案A的開發(fā)成本為10000元，在5年期限內每年可得效益4000；方案B開發(fā)成本為100000萬元，在5年期限內每年可得效益30000元。假定最小可接受的折扣率為12％1064.2成本/效益分析(6/6)例：方案A的凈資金現(xiàn)值系數(shù)＝4416/10000=0.44方案B的凈資金現(xiàn)值系數(shù)＝8150/100000＝0.08。1074.3相關文檔規(guī)范(1/3)問題定義報告范圍與目標敘述：XX年XX月XX日

項目：儲蓄系統(tǒng)問題：手工處理，顧客等待時間長，經常失去客戶項目目標：加快處理速度，減少客戶等待時間，吸引更多客戶項目范圍：……(敘述新系統(tǒng)的功能、行為及有關約束條件）初步設想：建立一個計算機系統(tǒng)可行性研究：……（指出可行性研究所需時間與費用）1084.3相關文檔規(guī)范(2/3)詞匯表不必說明眾所周知的術語完整的詞匯表“版本號”和“修訂歷史紀錄”“目錄”系統(tǒng)分析師負責詞匯表的完整性1094.3相關文檔規(guī)范(3/3)可行性研究報告大綱1)軟件工程實踐者的研究方法2)RUP：前景3)國家標準：可行性研究報告的編寫內容4)企業(yè)標準110Chapter5需求分析方法5.1需求分析的原則5.2需求收集方法5.3傳統(tǒng)需求分析建模方法5.4面向對象的需求分析建模方法5.5相關文檔規(guī)范1115.1需求分析的原則(1/12)1)循序漸進理由系統(tǒng)的規(guī)模越大且復雜->難以一下子理解完整急于求成->“邊建邊改”or錯誤or功能不完善步驟采集原始需求整理需求建立需求分析模型編寫需求規(guī)約文檔復審1125.1需求分析的原則(2/12)1)循序漸進1135.1需求分析的原則(3/12)2)自頂向下，逐層分解理由龐大的、復雜的系統(tǒng)很難一下子被完全理解小鳥視角分解分解還是分割？怎樣分解？分解多少/多深為宜？1145.1需求分析的原則(4/12)2)自頂向下，逐層分解1155.1需求分析的原則(5/12)3)與實現(xiàn)分離理由避免記錄一些因為當前的技術才存在的需求，或者使用一些可能不適合新產品的技術避免對實現(xiàn)的方式做出束縛。除非已經嚴格的做出要求，否則一般不應使用屬于實現(xiàn)的描述各盡其責解決辦法職業(yè)化、專業(yè)化的需求分析人員復審1165.1需求分析的原則(6/12)4)定義需求屬性理由每個需求僅僅是幾行描述語句嗎？評估測試故障對需求的影響評估用戶對系統(tǒng)的滿意程度估算開發(fā)成本管理項目的規(guī)模分配開發(fā)資源安排調度計劃管理需求變更管理項目風險1175.1需求分析的原則(7/12)4)定義需求屬性屬性包括每個需求并不僅僅是一行描述語句。每個需求都有類型、原因、開發(fā)優(yōu)先級、風險、客戶滿意度、客戶不滿意度、依賴關系、沖突關系，以及來源等屬性隨著開發(fā)的深入，還可以繼續(xù)豐富需求的屬性，如開發(fā)難度、開發(fā)工作量等1185.1需求分析的原則(8/12)5)可驗證性理由證明所開發(fā)的系統(tǒng)符客戶和用戶的要求的依據(jù)不可驗證的需求，僅僅是對需求的一種主觀愿望，對于設計和測試等活動而言都是缺乏意義的度量出系統(tǒng)實現(xiàn)的質量1195.1需求分析的原則(9/12)5)可驗證性非功能性需求的可驗證性易用性性能可靠性安全性1205.1需求分析的原則(10/12)6)可追蹤性需求的追蹤路徑1215.1需求分析的原則(11/12)6)可追蹤性理由跟蹤問題：在工件的轉換過程中，可能會出現(xiàn)很多問題，而問題存在傳遞性開發(fā)成員誤解需求錯誤地使用需求變更需求…分析潛在變更的影響核實通過實施系統(tǒng)所有的需求都已經被實現(xiàn)1225.1需求分析的原則(12/12)7)其它原則使用術語尊重客戶的意見重視復用需求對變更進行管理要求“確認需求”1235.2需求收集方法與用戶交流的方式用戶訪談做學徒討論會頭腦風暴…交流手段使用思維圖，使用魚骨圖，使用需求卡片1245.3傳統(tǒng)需求分析建模方法功能建模數(shù)據(jù)流程圖(DataFlowDiagram,DFD)行為建模狀態(tài)變遷圖(State-TransitionDiagram,STD)Petri網(wǎng)數(shù)據(jù)字典判定表和判定樹1255.3傳統(tǒng)——數(shù)據(jù)流程圖(1/16)什么是數(shù)據(jù)流程圖是一個分層的概念模型，分為三個層次：總體圖、零級圖、細節(jié)圖，分別描述系統(tǒng)的不同特征。4種符號：方，圓，開口矩（平行線），箭頭3個層次：總體圖，零級圖，細節(jié)圖優(yōu)點容易理解，容易在開發(fā)方和用戶方之間進行交流，以及在開發(fā)組織內部交流1265.3傳統(tǒng)——數(shù)據(jù)流程圖(2/16)表示符號外部實體數(shù)據(jù)處理數(shù)據(jù)存儲數(shù)據(jù)流1275.3傳統(tǒng)——數(shù)據(jù)流程圖(3/16)數(shù)據(jù)變換1285.3傳統(tǒng)——數(shù)據(jù)流程圖(4/16)分層表示的數(shù)據(jù)處理1295.3傳統(tǒng)——數(shù)據(jù)流程圖(5/16)分層表示的數(shù)據(jù)處理總體圖：描述了系統(tǒng)和周圍環(huán)境的關系零級圖：表示一個系統(tǒng)的主要功能或者是一個大型系統(tǒng)的主要組成子系統(tǒng)細節(jié)圖：表示一個復雜的處理

的詳細內部表示1305.3傳統(tǒng)——數(shù)據(jù)流程圖(6/16)分層表示的數(shù)據(jù)處理總體圖1315.3傳統(tǒng)——數(shù)據(jù)流程圖(7/16)分層表示的數(shù)據(jù)處理零級圖1325.3傳統(tǒng)——數(shù)據(jù)流程圖(8/16)分層表示的數(shù)據(jù)處理細節(jié)圖1335.3傳統(tǒng)——數(shù)據(jù)流程圖(9/16)數(shù)據(jù)流程圖繪制的有關規(guī)定(1/2)外部實體只能出現(xiàn)在總體圖和零級圖中數(shù)據(jù)存儲只能出現(xiàn)在零級圖和細節(jié)圖中數(shù)據(jù)存儲在分層的DFD圖中只能出現(xiàn)一次數(shù)據(jù)存儲必須既有讀操作，也有寫操作數(shù)據(jù)流要有名字數(shù)據(jù)流必須開始或結束在處理圓圈上數(shù)據(jù)流不表示有關的控制邏輯1345.3傳統(tǒng)——數(shù)據(jù)流程圖(10/16)數(shù)據(jù)流程圖繪制的有關規(guī)定(2/2)每個處理要有編號，但不表示先后順序每個圖中處理的數(shù)不應超過9個每個處理應該既有輸入的數(shù)據(jù)流，也有輸出的數(shù)據(jù)流子圖與父圖中對應的處理必須執(zhí)行相同的功能，并且子圖與對應的處理流入和流出的數(shù)據(jù)流相同輸入/輸出命令不能作為DFD圖中的處理1355.3傳統(tǒng)——數(shù)據(jù)流程圖(11/16)規(guī)定舉例11365.3傳統(tǒng)——數(shù)據(jù)流程圖(12/16)規(guī)定舉例2137數(shù)據(jù)流程圖(DFD)規(guī)定舉例3規(guī)定舉例31385.3傳統(tǒng)——數(shù)據(jù)流程圖(12/16)規(guī)定舉例4①E1->DS1數(shù)據(jù)流未與處理相連②DS1->DS2數(shù)據(jù)流無處理③處理P1無輸出數(shù)據(jù)流④處理P2無輸入數(shù)據(jù)流⑤數(shù)據(jù)存儲DS2無讀操作⑥所有數(shù)據(jù)流沒有名字21395.3傳統(tǒng)——數(shù)據(jù)流程圖(12/16)規(guī)定舉例5DS1無寫操作140阿DS2無寫操作DS2讀操作的數(shù)據(jù)流無名稱相對于零級圖中的過程P1，少數(shù)據(jù)流A4DS1與零級圖中的數(shù)據(jù)存儲重復141AB2應指向一個處理，而不應直接指向數(shù)據(jù)存儲，我們規(guī)定數(shù)據(jù)流至少有一端必須和處理相聯(lián)。相對于其父圖中過程P1.2,此處多了數(shù)據(jù)流A4過程P1.2.3無輸入1425.3傳統(tǒng)——數(shù)據(jù)流程圖(14/16)例子143DataFlowDiagramsExample1445.3傳統(tǒng)——數(shù)據(jù)流程圖(16/16)例子1455.3傳統(tǒng)——狀態(tài)變遷圖(1/3)表示符號狀態(tài)：是可以被觀察到的系統(tǒng)的行為模式圓圈或矩形表示，并在圓圈或矩形中標明狀態(tài)的名字變遷表示一種狀態(tài)向另一種狀態(tài)的遷移帶箭頭的線來表示，在線上要標注出事件的名稱，需要時也可以和把DFD圖中相關的處理標注進來1465.3傳統(tǒng)——狀態(tài)變遷圖(2/3)例子1：進程1475.3傳統(tǒng)——狀態(tài)變遷圖(3/3)例子2：復印機1485.3傳統(tǒng)——Petri網(wǎng)(1/2)表示符號位置（Place）節(jié)點表示系統(tǒng)的狀態(tài)用圓形符號表示躍遷（Transition）節(jié)點表示系統(tǒng)中的事件用短粗線或矩形表示1495.3傳統(tǒng)——Petri網(wǎng)(2/2)例子1505.3傳統(tǒng)——數(shù)據(jù)字典(1/6)數(shù)據(jù)流程圖的問題數(shù)據(jù)流程圖描述了一個系統(tǒng)的主要處理邏輯，所存取的數(shù)據(jù)文件或數(shù)據(jù)庫及其輸入和輸出的關系。但不能反映系統(tǒng)的具體細節(jié)。什么是數(shù)據(jù)字典配合數(shù)據(jù)流程圖，反映具體細節(jié)。二者結合，精確描述。作用：統(tǒng)一定義，便于通訊，便于共享1515.3傳統(tǒng)——數(shù)據(jù)字典(2/6)元素數(shù)據(jù)元素最小數(shù)據(jù)單元數(shù)據(jù)流基本數(shù)據(jù)單元，有關的數(shù)據(jù)元素所組成的動態(tài)的數(shù)據(jù)結構數(shù)據(jù)存儲數(shù)據(jù)結構的載體，靜態(tài)的數(shù)據(jù)結構處理具體處理邏輯1525.3傳統(tǒng)——數(shù)據(jù)字典(3/6)數(shù)據(jù)元素1535.3傳統(tǒng)——數(shù)據(jù)字典(4/6)數(shù)據(jù)流1545.3傳統(tǒng)——數(shù)據(jù)字典(5/6)數(shù)據(jù)存儲155處理1565.3傳統(tǒng)——判定表和判定樹(1/8)判定表左上部：條件或數(shù)據(jù)元素名稱右上部：所有條件組合左下部：處理活動名稱右下部：注明條件組合和相應活動對應關系1575.3傳統(tǒng)——判定表和判定樹(2/8)例子1585.3傳統(tǒng)——判定表和判定樹(3/8)例子1595.3傳統(tǒng)——判定表和判定樹(4/8)例子1605.3傳統(tǒng)——判定表和判定樹(5/8)判定表優(yōu)點表達邏輯清楚，比自然語言容易理解問題中的條件或數(shù)據(jù)元素在表中只出現(xiàn)一次判定表缺點用戶難以理解隨著問題中的條件增多，判定表會變的相當復雜，有時侯一個有經驗的分析員也難以畫出某些判定表1615.3傳統(tǒng)——判定表和判定樹(6/8)判定樹是一個樹狀圖根節(jié)點表示問題的名字內部節(jié)點表示條件，葉子節(jié)點表示活動。1625.3傳統(tǒng)——判定表和判定樹(7/8)例子1635.3傳統(tǒng)——判定表和判定樹(8/8)判定樹優(yōu)點：理解容易，不需要用戶培訓繪制方法直觀判定樹缺點：繁瑣，同一條件要書寫多次（如前面股票傭金政策用判定樹表示，則會非常復雜）1645.4面向對象的需求分析建模方法用例建模CRC建模對象-關系模型對象-行為模型1655.4OOA方法——用例建模(1/14)定義：用例是系統(tǒng)、子系統(tǒng)或類和外部的參與者（Actor）交互的動作序列的說明，包括可選的動作序列和會出現(xiàn)異常的動作序列表示方法一個橢圓用例名稱用與例1665.4OOA方法——用例建模(3/14)例子1675.4OOA方法——用例建模(4/14)識別ActorActor在系統(tǒng)邊界外部Actor直接與系統(tǒng)交互Actor與系統(tǒng)的交互應該是有意義的Actor可能是任何事物一個人可以擔任多個參與者1685.4OOA方法——用例建模(5/14)例子1695.4OOA方法——用例建模(6/14)識別UseCase用例止于系統(tǒng)邊界用例是一個交互的抽象從Actor的角度去描述用例粒度適度1705.4OOA方法——用例建模(7/14)例子1：粒度過細，陷入功能分解1715.4OOA方法——用例建模(8/14)例子2：CRUD1725.4OOA方法——用例建模(9/14)識別UseCase之間的關系泛化（Generalization）包含（Include）擴展（Extend）1735.4OOA方法——用例建模(10/14)例子1例子21745.4OOA方法——用例建模(11/14)例子31755.4OOA方法——用例建模(12/14)用例文檔用例編號用例名用例描述參與者前置條件后置條件前置條件后置條件1765.4OOA方法——用例建模(13/14)基本路徑/主事件流1…..××××2……××××3…..××××擴展點/異常事件流/可選事件流或異常/替換事件流2a.××××2a1….×××××補充說明1775.4OOA方法——用例建模(14/14)討論：登錄用例1.系統(tǒng)顯示輸入用戶名和密碼的界面2.會員輸入用戶名和密碼，點擊“確定”3.如果用戶名和密碼正確，系統(tǒng)根據(jù)用戶名從數(shù)據(jù)庫“會員”表中查詢該會員信息，系統(tǒng)顯示會員定制界面4.如果用戶名不存在以上用例文字有什么問題？1785.4OOA方法——CRC建模(1/3)含義Class-Responsibility-Collaborator,類-責任-協(xié)作者識別候選類并指明它們的責任和協(xié)作實際上是一組表示類的標準的索引卡片集合卡片的頂部：類的名字、類型和特征卡片的左邊：列出類的責任，卡片的右邊：列出協(xié)作者1795.4OOA方法——CRC建模(2/3)卡片圖例1805.4OOA方法——CRC建模(3/3)候選類的類型外部實體、事務、發(fā)生的事情或事件、角色、位置邊界類、實體類、控制類1815.4OOA方法——對象-關系建模(1/9)關系類型泛化（Generalization）關系由一個超類和幾個直接子類構成的兩層結構關聯(lián)（Association）關系是模型元素間的一種語義聯(lián)系聚集（Aggregation）和合成（Composition）關系是一種特殊的關聯(lián)，表示類與類之間整體與部分的關系是一種強聚集，組合關系中的類具有相同的生存期依賴（Dependency）關系是類與類之間較弱的關系1825.4OOA方法——對象-關系建模(2/9)例子11835.4OOA方法——對象-關系建模(3/9)例子21845.4OOA方法——對象-關系建模(4/9)例子31855.4OOA方法——對象-關系建模(5/9)例子41865.4OOA方法——對象-關系建模(6/9)例子5例子61871885.4OOA方法——對象-關系建模(8/9)例子7例子81895.4OOA方法——對象-關系建模(9/9)例子9例子10例子111905.4OOA方法——對象-行為建模(1/2)交互圖（InteractionDiagram）是顯示對象之間交互的圖，這些對象是按照時間順序排序的1915.5相關文檔規(guī)范(1/4)相關需求文檔需求卡片RUP前景文檔需求規(guī)約文檔術語表界面原型補充需求（可用性、可靠性、性能…）1925.5相關文檔規(guī)范(2/4)1935.5相關文檔規(guī)范(3/4)需求規(guī)范內容[P66]背景名稱、單位、參考文獻產品概述目的、主要指標、主要特征、軟硬件環(huán)境、費用承擔方外部接口哪些系統(tǒng)、接口方式、數(shù)據(jù)結構和格式功能要求邊界、接口、格式、特殊要求1945.5相關文檔規(guī)范(4/4)需求規(guī)范內容[P66](續(xù))性能要求吞吐量、響應時間、可靠性、安全性等系統(tǒng)邏輯模型數(shù)據(jù)流程圖、數(shù)據(jù)字典、有限狀態(tài)機、Petri網(wǎng)等。驗收準則采用什么實驗、采用什么測試數(shù)據(jù)和測試環(huán)境附錄補充材料，如重要表格、關鍵算法。195Chapter6軟件設計方法6.1設計的概念6.2分治6.3抽象6.4內聚和耦合6.5復用6.6設計描述方法6.7人-機界面的設計6.8相關文檔規(guī)范1966.1設計的概念(1/7)設計的總體原則不應陷入片面性追蹤分析模型選擇合適的技術適度分解可集成提高抽象層次可復用可維護和可擴展的有韌性一致性交互界面應該友好設計評審1976.1設計的概念(2/7)軟件構架UML：指系統(tǒng)的組織結構，它可以遞歸解構為通過接口交互的部件、連接部件的關系以及組裝部件的一些限制條件，通過接口交互的部件有類、構件和子系統(tǒng)。IEEE：系統(tǒng)在其環(huán)境中的最高層概念1986.1設計的概念(3/7)軟件構架MaryShaw和DavidGarlan關于構成系統(tǒng)的元素、這些元素之間的交互、元素和元素之間的組成模式以及作用在這些組成模式上的約束等方面的描述RationalUnifiedProcess指通過接口交互的重要構件的組織或結構，這些構件又由一些更小的構件和接口組成。1996.1設計的概念(4/7)軟件構架反映系統(tǒng)整體的組織結構和基本特征軟件的層次結構模塊相互作用的方式全局的、重要的數(shù)據(jù)變量和數(shù)據(jù)結構數(shù)據(jù)庫的邏輯結構接口2006.1設計的概念(5/7)軟件構架對復雜的系統(tǒng)進行抽象，為系統(tǒng)設計規(guī)劃藍圖，是關于系統(tǒng)構造及系統(tǒng)各構件工作機制的相對精簡、卻能清晰反映核心問題的模型，體現(xiàn)了項目早期的設計決策，可以作為相關涉眾對系統(tǒng)理解和交流以及進行項目管理的基礎，能夠幫助開發(fā)人員進一步細化和實施系統(tǒng)一個好的軟件構架已經成為完成高質量軟件的重要保證，它在軟件開發(fā)中起到核心作用2016.1設計的概念(6/7)軟件體系結構和其它開發(fā)任務的關系2026.1設計的概念(7/7)詳細設計在軟件構架的基礎上進一步確定如何實現(xiàn)目標系統(tǒng)，具體包括系統(tǒng)的模塊（如類及其方法）邏輯的詳細設計、系統(tǒng)數(shù)據(jù)結構的設計、系統(tǒng)數(shù)據(jù)庫結構的設計、系統(tǒng)人-機接口的設計等2036.2分治(1/6)分治思想架構設計->將系統(tǒng)分解為一組子系統(tǒng)或模塊，以及子系統(tǒng)或模塊之間的接口。詳細設計->子系統(tǒng)或模塊被再次細分為子模塊傳統(tǒng)軟件工程中的過程、函數(shù)面向對象軟件工程中的包、類、接口和方法等2046.2分治(2/6)分治的優(yōu)點1)縮小問題空間，減少問題復雜度和工作量C(p1)>C(p2)E(p1)>E(p2)C(p1+p2)>C(p1)+C(p2)E(p1+p2)>E(p1;p2)E(p1;p2)=E(p1)+E(p2)E(p1+p2)>E(p1)+E(p2)

2056.2分治(3/6)分治的優(yōu)點2)便于并發(fā)執(zhí)行，縮短開發(fā)周期3)適合團隊協(xié)作，降低了實施難度4)預防了開發(fā)中的多米諾骨牌效應5)容易產生可復用部件2066.2分治(4/6)分治要考慮的問題1)分治是否可以無限分解，是否越細越好2076.2分治(5/6)分治要考慮的問題2)從技術的角度講，如何分治？程序設計方法部件重用可理解性獨立性有界性2086.2分治(6/6)分治要考慮的問題3)如何將任務分解到不同的時間域上？需求的優(yōu)先級基礎部件項目風險任務執(zhí)行的難易程度2096.3抽象(1/7)抽象思想為了降低復雜度，應該隱藏細節(jié)或推遲考慮細節(jié)抽象的優(yōu)點有利于認識事物的普遍特征和基本原理幫助設計人員制定出模塊的“框架”有利于軟件的復用提高系統(tǒng)的的可擴展性 2106.3抽象(2/7)基于抽象的設計原則1)里氏替換原則(LiskovPrinciple)子類可以替換父類，可以出現(xiàn)在父類能出現(xiàn)的任何地方如果對于每一個類型為T1的對象o1，都有類型為T2的對象o2，使得以T1定義的所有程序P在所有的對象o1都替換成o2時，程序P的行為沒有變化，那么類型T2是類型T1的子類型。

2116.3抽象(3/7)基于抽象的設計原則2)開閉原則(Open-ClosedPrinciple)即一個軟件實體應當對擴展開放，對修改關閉2126.3抽象(4/7)基于抽象的設計原則3)依賴倒轉原則(DependenceInversionPriciple)要依賴于抽象，不要依賴于具體類2136.3抽象(5/7)傳統(tǒng)軟件工程中的抽象信息隱蔽指一個模塊內的數(shù)據(jù)和模塊的實現(xiàn)細節(jié)對于該模塊的客戶即調用者模塊有不可見的性質數(shù)據(jù)局部化缺點僅對模塊細節(jié)的封裝，沒有繼承的概念，雖然可以“到處復用”，卻也需要“到處修改”2146.3抽象(6/7)面向對象軟件工程中的抽象繼承傳統(tǒng)，發(fā)展深化抽象類2156.3抽象(7/7)面向對象軟件工程中的抽象接口2166.4內聚和耦合(1/18)內聚是一個模塊內部各部件之間聯(lián)系緊密程度的度量強調分解時將相關的內容放到一起一個模塊內的各個部件聯(lián)系越緊越好耦合是模塊間相互聯(lián)系強弱的度量耦合的強弱取決于模塊間傳遞數(shù)據(jù)的方式、接口復雜情況以及傳遞數(shù)據(jù)的類型各模塊之間的耦合越松散越好2176.4.1內聚(1/10)內聚的分類1)功能內聚（FunctionalCohesion）所有部件處理同一組數(shù)據(jù)，共同完成單一的功能易于理解、易于診斷、易于維護、易于替換、易于復用2186.4.1內聚(2/10)內聚的分類2)順序內聚（SequentialCohesion）各部件之間既有數(shù)據(jù)聯(lián)系又有控制聯(lián)系較為理想2196.4.1內聚(3/10)內聚的分類3)通信內聚（CommunicationalCohesion）所有的部件都訪問同一組數(shù)據(jù)，各部件之間只有數(shù)據(jù)關系，沒有控制關系較為理想2206.4.1內聚(4/10)內聚的分類4)過程內聚（ProceduralCohesion）各部件之間只有控制聯(lián)系，而沒有數(shù)據(jù)聯(lián)系較弱的內聚2216.4.1內聚(5/10)內聚的分類5)時間內聚（TemporalCohesion）所有部件之間既無數(shù)據(jù)聯(lián)系，也無控制聯(lián)系，但是部件之間具有時間關系，即把在執(zhí)行過程中同一階段內完成執(zhí)行任務的部件放到一起，而排除其它部件內聚更弱2226.4.1內聚(6/10)內聚的分類6)實用程序內聚（UtilityCohesion）部件常常是一些相關的、可重用的實用程序內聚很弱2236.4.1內聚(7/10)內聚的分類7)偶然內聚（CoincidentalCohesion）模塊內部的各部件之間沒有任何關系最不好的一種內聚類型2246.4.1內聚(8/10)內聚的分類8)層內聚（LayerCohesion）將相關服務的功能放到一起，成為一層，而將其它內容排出在外替換低層時可以用等價層（實現(xiàn)原層所有的API）而不必修改高層，替換高層模塊對低層模塊沒有影響（低層服務不訪問高層服務）層內聚被廣泛地應用在軟件的分層架構上2256.4.1內聚(9/10)內聚的分類8)層內聚2266.4.1內聚(10/10)相互嵌套的內聚模塊2276.4.2耦合(1/6)解耦的原因牽一發(fā)而動全身很難快速地理解緊耦合的模塊獨立性較差2286.4.2耦合(2/6)耦合的分類1)內容耦合（Contentcoupling）一個模塊直接進入另一個模塊中存取其數(shù)據(jù)或使用其服務最不好的一種耦合2296.4.2耦合(3/6)耦合的分類2)公共耦合（Commoncoupling）兩個模塊間通過一個公共環(huán)境進行數(shù)據(jù)交換較差的耦合，應該避免使用2306.4.2耦合(4/6)耦合的分類3)外部耦合（Externalcoupling）模塊對外部系統(tǒng)（如軟件操作系統(tǒng)、數(shù)據(jù)庫、硬件設備，以及可復用的組件庫等）有依賴關系有時無法避免，應該盡量減少4)控制耦合（Controlcoupling）兩個模塊之間通過接口的參數(shù)表交換開關數(shù)據(jù)，旨在控制另一個模塊的執(zhí)行邏輯較差2316.4.2耦合(5/6)耦合的分類5)印記耦合（Stampcoupling）Pressman：指兩個模塊之間通過參數(shù)交換方式產生耦合，并且交換的是數(shù)據(jù)結構而不是數(shù)據(jù)元素TimothyC.Lethbridge：當應用程序的類被聲明為方法參數(shù)類型時，就會產生印記耦合允許使用2326.4.2耦合(6/6)耦合的分類6)數(shù)據(jù)耦合（Datacoupling）兩個模塊之間通過接口的參數(shù)表交換信息數(shù)據(jù)，并且這些信息數(shù)據(jù)的類型是基本數(shù)據(jù)類型需要傳遞的參數(shù)較少時，數(shù)據(jù)耦合較好需要傳遞的參數(shù)較多時，印記耦合要更好2336.4內聚和耦合(18/18)內聚譜系和耦合譜系234復用的概念復用技術6.5復用(1/20)提高軟件生產率的辦法改進過程改善需求分析方法改進設計方法改進工具……然而……復用——最有效率的方法之一案例2356.5.1復用的概念(1/4)復用的定義Biggerstaff和Ritcher:在新的開發(fā)項目中使用以前已獲得的概念和對象

Tracz:特別為復用目的而設計的軟件的過程

Freeman:是一種通過使用以前開發(fā)工作的某些東西來生產（或幫助生產）一個系統(tǒng)的過程，其關鍵問題是復用什么、什么是導致成功復用的過程2366.5.1復用的概念(2/4)一個典型的復用分層體系2376.5.1復用的概念(3/4)涉及的內容復用的管理問題軟件組織資產復用過程領域工程技術(可復用構件)復用經濟學……2386.5.1復用的概念(4/4)復用的分類根據(jù)對可復用信息進行復用的方式黑盒復用和白盒復用按照復用的規(guī)模小規(guī)模復用與大規(guī)模復用按照復用方法組合式復用和生成式復用按照軟件復用所應用的領域范圍橫向復用和縱向復用按復用的構件的物理形式子程序、類、組件、Web服務組件等2396.5.2復用技術(1/6)代碼復制(共享公共函數(shù)和子例程)代碼公開(版權)復雜改動，

而不是繼承(版本)…….2406.5.2復用技術(2/6)面向對象的復用源碼復用依賴語言粒度較小脆弱的基類不可獨立部署第三方市場不夠繁榮2416.5.2復用技術(3/6)基于組件的復用(概念)組件概念：組件(Component)是指有定義完備接口的、明確規(guī)定了上下文依賴關系的合成單元，它可以被第三方用不同語言開發(fā)，并且能夠被獨立的部署，它具有自包含的屬性，其內部構造和特征不可見EJB、COM、.NET和CORBA等

是主要的組件模型基于接口的程序設計2426.5.2復用技術(4/6)基于組件的復用(不足)Internet(協(xié)議、防火墻)跨平臺組件環(huán)境部署和升級遠程服務需要實例化2436.5.2復用技術(5/6)基于Web服務的功能復用Web服務概念基于開放的標準，通過Web接口在網(wǎng)絡上提供的某個功能的組件術語：HTTP，SOAP，WSDL，UDDI，XML……開發(fā)商：應用程序越來越變得松散耦合被分解為多個組件被分布在多個計算機上Web服務提供商：服務變得更專業(yè)2446.5.2復用技術(6/6)基于Web服務的功能復用優(yōu)點避免了組件的不足(前頁)更簡單使用者，而非所有者充分利用第三方的技能和經驗版權和版本不足速度2456.5.3案例(1/9)寵物商店系統(tǒng)各種角色（如顧客、管理員、商店經理等）要登錄到系統(tǒng)中，需要填寫用戶名、口令為了防止非法入侵，還要填寫驗證碼。驗證碼的相關代碼相對復雜，涉及到驗證碼圖片的生成和驗證碼的校驗。很多網(wǎng)站都有類似的功能。2466.5.3案例(1/8)寵物商店系統(tǒng)的登錄2476.5.3案例(3/9)驗證碼控件2486.5.3案例(4/9)驗證碼控件2496.5.3案例(5/9)驗證碼控件2506.5.3案例(6/9)判斷驗證代碼是否正確if(!ValidateCodeImage1.Validate(textValidateCode.Text)){lblErr.Text="驗證碼錯誤，請重新填寫";……}2516.5.3案例(7/9)Gif2008FatRabbit……2526.5.3案例(8/9)調用publicvoidRefresh(){ //產生一個驗證碼字符串ValidateCode …. //調用Web服務，生成圖片MemoryStreamstrmBuffer=new

MemoryStream(PicService.CreateSpecialPic(ValidateCode));Bitmapobj=newBitmap(strmBuffer);obj.Save(FileName,ImageFormat.Jpeg);…}2536.5.3案例(9/9)擴展思維站在服務提供商的角度考慮圖像Web服務站在服務使用者的角度考慮面向服務的架構(SOA)站在復用工程師的角度考慮可復用構件的管理……2546.6設計描述方法(1/15)設計模型原因：完全使用文字描述的方法來表達軟件復雜的設計結果，往往會造成語義模糊、過于冗長、不夠抽象等問題模型更易于被快速的編檔、理解和執(zhí)行學術界和企業(yè)界傳統(tǒng)：層次圖、結構圖、HIPO(HierachicalInputProcessOutput)圖、ER圖、程序流程圖、盒式圖、PAD(ProblemAnalysisDiagram)圖、PDLOO：包圖、類圖、構件圖、部署圖2556.6.1傳統(tǒng)的設計描述方法(1/9)1)層次圖用于描述程序的組成，即組成系統(tǒng)的程序模塊及其調用關系能夠清楚地表明系統(tǒng)的結構，并可用來粗略地估計系統(tǒng)的尺寸廣泛地應用2566.6.1傳統(tǒng)的設計描述方法(2/9)2576.6.1傳統(tǒng)的設計描述方法(3/9)2)結構圖表明模塊之間的相互作用關系2586.6.1傳統(tǒng)的設計描述方法(4/9)2)結構圖簡單的工資計算程序的結構圖2596.6.1傳統(tǒng)的設計描述方法(5/9)3)程序流程圖又稱程序框圖，是詳細設計中廣泛使用的工具之一2606.6.1傳統(tǒng)的設計描述方法(6/9)4)盒式圖Nassi和Shneiderman提出2616.6.1傳統(tǒng)的設計描述方法(7/9)5)PDL(ProcedureDescriptionLanguage)又稱偽碼，用英文if…then-else…endif和while…do…enddo等表示控制結構的保留字及用設計者本土語言所構成的算法的描述連接數(shù)據(jù)庫；打開數(shù)據(jù)庫的員工表;執(zhí)行SQL語句：Select*from員工表whileUserName=@username,Password=@password；if(員工表存在相關記錄)then 轉移到主頁面；else 轉移到報錯頁面，通知用戶用戶名或秘密錯；……2626.6.1傳統(tǒng)的設計描述方法(8/9)6)E-R圖實體聯(lián)系圖，用以表示應用領域中的實體及其相互關系通過E-R圖可以很快轉成關系數(shù)據(jù)庫概念實體：一切事物，如操作員、顧客、寵物等聯(lián)系：事物間關系屬性：客觀實體和聯(lián)系實體所擁有的性質263學號姓名性別課號課名學時學生注冊注冊日期班級班號專業(yè)人數(shù)學習課程學期成績教授教師開課日期結束日期教師號姓名職稱mnn1m1n6.6.1傳統(tǒng)的設計描述方法(9/9)2646.6.2OO的設計描述方法(1/7)1)包把元素組織成組

的通用機制例子2656.6.2OO的設計描述方法(2/7)2)類圖類加上它們之間的關系就構成了類圖設計原則設計模式2662)類圖例子2676.6.2OO的設計描述方法(4/7)3)構件圖構件是系統(tǒng)中遵從一組接口且提供其實現(xiàn)的物理的、可替換的部分輸出接口(exportinterface)和引入接口(importinterface)2686.6.2OO的設計描述方法(5/7)3)構件圖例子2696.6.2OO的設計描述方法(6/7)4)部署圖用來表示系統(tǒng)中的計算節(jié)點的拓撲結構和通信路徑與節(jié)點上運行的軟構件等節(jié)點是存在于運行時的代表計算資源的物理元素，一般擁有處理能力和內存，如處理器或設備2706.6.2OO的設計描述方法(7/7)4)部署圖例子2716.7人機交互界面設計(1/7)大量的項目因為沒有讓用戶充分參與界面的設計而失敗市場部門的問題開發(fā)人員的問題用戶的問題設計模型的問題2726.7人機交互界面設計(2/7)一些典型的不良界面對用戶的主觀臆測不友好晦澀難懂行為不當界面復雜2736.7人機交互界面設計(3/7)以用戶為中心的設計(User-CenteredDesign,UCD)

理解用戶的特征理解用戶的任務確保用戶參與遵循良好的界面設計原則2746.7人機交互界面設計(4/7)界面設計指導原則全部界面格式和風格應保持一致適當組織菜單層次和菜單項為不同的用戶或功能提供不同的界面服務力求用戶需要的輸入量最少破壞性命令或功能選項應確認提供有效的系統(tǒng)保障能力布局合理簡單易懂，整潔有序，條理清晰幫助功能一定的智能2756.7人機交互界面設計(5/7)界面設計基礎字符型界面和圖形界面2766.7人機交互界面設計(6/7)界面設計基礎界面控件菜單、命令控件、靜態(tài)文本控件、文本控件、數(shù)據(jù)窗口控件、下拉列表框控件、單選按鈕控件、復選框控件、樹形結構控件、圖形控件、微調框控件、滑動條控件……自定義的控件2776.7人機交互界面設計(7/7)多通道人機交互強調計算機輸入信息的自然性和多樣性語音交互虛擬現(xiàn)實高級交互2786.10相關文檔規(guī)范相關設計文檔1)軟件工程實踐者的研究方法2)RUP：軟件架構文檔3)國家標準：軟件設計書的編寫內容概要設計說明書（GB8567－88）詳細設計說明書（GB8567－88）數(shù)據(jù)庫設計說明書（GB8567－88）4)企業(yè)標準279Chapter7軟件實施與測試方法7.1程序設計語言7.2編碼風格7.3軟件測試原則7.4白盒測試7.5黑盒測試7.6單元測試7.7集成測試7.8相關文檔規(guī)范2807.1程序設計語言(1/2)廣泛應用的程序設計語言匯編語言BASIC語言Fortran語言COBOL語言C語言Ada語言Java語言.NET系列語言2817.1程序設計語言(2/2)程序設計語言的選擇生產率因素軟件應用領域程序員的知識/用戶的要求CASE工具支持2827.2編碼風格(1/4)程序的內部文檔程序塊頭部注解程序內部注解 程序的標識符程序文件數(shù)據(jù)文件變量和常數(shù)2837.2編碼風格(2/4)程序清單的安排同一層次的語句序列寫在相同的列上，全部語句的第一個字母要對齊循環(huán)語句的語句體部分要適當?shù)目s進條件選擇語句中的then部分和else部分，應該寫在不同的行上，并且相應部分的語句序列應有適當?shù)目s進。2847.2編碼風格(3/4)程序中的語句由表達式構成的語句適當使用括號分解成更小的表達式IF語句盡量避免否定的布爾條件盡量避免if…thenif形式避免elsereturn的形式2857.2編碼風格(4/4)程序中的語句輸入語句有明確的提示如有必要，進一步確認合法性檢查輸出語句加說明信息2867.3軟件測試原則(1/1)遵循的原則所有測試的標準都是建立在用戶需求之上所有的需求都是可驗證的測試活動可提前展開增量測試窮舉所有的測試是不現(xiàn)實的不要忽略非正常的輸入數(shù)據(jù)不能忽略回歸測試對問題較多的代碼單元，需要進行更細致的測試專業(yè)人員測試或委托第三方測試2877.4白盒測試-7.4.1概念(1/4)概念導出測試用例是依據(jù)模塊的編碼，即模塊的內部邏輯對測試者是可見的只要測試了程序的所有路徑，程序就應該是100%正確的？是否能窮盡所有路徑？即使窮盡了路徑，是否能保證測試的結果可靠？2887.4.1白盒測試的概念(2/4)41+42+…+420≈1.466×10122897.4.1白盒測試的概念(3/4)if(x+y+z)/3==xthen output(“x，y，z的值相等”)else output(“x，y，z的值不相等”)endif測試1：x=1，y=2，z=3測試2：x=2，y=2，z=2測試3：x=2，y=1，z=32907.4.1白盒測試的概念(4/4)白盒測試能保證模塊中所有獨立途徑至少測試一次測試所以邏輯決策真和假兩個方面在所有循環(huán)的邊界內部和邊界上執(zhí)行循環(huán)體檢查內部數(shù)據(jù)結構以保證其有效性2917.4.2基本途徑測試(1/4)概念指覆蓋基本途徑集合的試驗用例將使程序中的每個語句至少執(zhí)行一次基本途徑的集合是由一組獨立途徑組成的獨立途徑是指程序中至少引入一個新（執(zhí)行）語句的路徑2927.4.2基本途徑測試(2/4)途徑1-2-101-2-3-4-6-8-9-2-101-2-3-4-7-8-9-2-101-2-3-5-9