軟件工程(第二版)課件_第1頁
軟件工程(第二版)課件_第2頁
軟件工程(第二版)課件_第3頁
軟件工程(第二版)課件_第4頁
軟件工程(第二版)課件_第5頁
已閱讀5頁,還剩141頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

第1章

軟件工程綜述

本章要點:軟件特點與分類軟件工程及其發(fā)展軟件危機現(xiàn)象與原因工程技術與工程管理主流工程方法學第1章軟件工程綜述

本章要點:11.軟件有什么特點

計算機系統(tǒng)由硬件、軟件兩部分組成。硬件是物理部件,如:處理器、存儲器、主板總線,具有一定的物理形態(tài),能夠獨立存在。軟件則是物理硬件以外的邏輯部件,如:程序、數(shù)據(jù)、文檔,抽象無形,不能獨立存在。

軟件工程需要研究如何更有成效地研發(fā)軟件、維護軟件,要達到這個目標,則必然需要對軟件有很好的認識。1.軟件有什么特點

計算機系統(tǒng)由硬件、軟件兩部分組成22.什么是軟件工程

軟件工程是關于軟件開發(fā)、使用與維護的工程方法學,是一門涉及工程技術、工程管理與工程經(jīng)濟等諸多內(nèi)容的綜合性工程學科。軟件工程建立在與軟件有關的工程概念、原理與方法基礎上,它是對現(xiàn)實軟件問題的工程方法探索,具有鮮明的工程實用性。2.什么是軟件工程

軟件工程是關于軟件開發(fā)、使用與31.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。軟件研發(fā)機構應該有健康的可適應軟件研發(fā)任務的組織機體。項目小組則是最小的因項目任務組建的研發(fā)團隊,要求小而精,成員大多限制在8人以內(nèi)。主要成員有:項目負責人、開發(fā)人員、資料管理員、軟件測試員。項目小組有多種管理機制,如:民主分權制、主程序員負責制、職業(yè)項目經(jīng)理負責制、層級負責制。1.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量43.為什么會發(fā)生軟件危機20世紀60年代中期,軟件開發(fā)者遭遇到了軟件危機。主要危機現(xiàn)象有:軟件開發(fā)成本進度難估算、軟件質(zhì)量沒有保證、軟件不能滿足應用需要、軟件缺乏可維護性。

危機客觀原因:軟件的邏輯隱蔽性、軟件的復雜性、軟件的低產(chǎn)業(yè)發(fā)展水平。

危機主管原因:漠視用戶需求、重結果輕過程、個人英雄理念。3.為什么會發(fā)生軟件危機20世紀60年代中期,軟件開54.軟件工程技術、管理與目標

軟件工程涉及的技術問題有:

軟件過程:實現(xiàn)軟件的步驟與工程框架;

工程方法:實現(xiàn)軟件的技術性要素,如:工程規(guī)范、工程策略、技術手段等。

軟件工具:對工程方法與軟件過程的自動化或半自動化支持。

軟件工程涉及的管理問題有:項目管理、人員管理、過程管理、產(chǎn)品管理。

軟件工程還必須考慮工程目標,以體現(xiàn)其工程價值。一些主要的工程目標是:降低成本、滿足需求、改善性能、提高質(zhì)量、及時交付。4.軟件工程技術、管理與目標軟件工程涉及的技術問題65.主流工程方法學結構化方法學是傳統(tǒng)的主流方法學,以功能為基本元素,包括結構化分析(SA)、結構化設計(SD)與結構化實現(xiàn)(SP),可對整個軟件生命周期提供方法學支持。面向對象方法學則是目前的主流方法學,包括面向對象分析(OOA)、面向對象設計(OOD)與面向對象實現(xiàn)(OOA),可對整個軟件生命周期提供方法學支持。其以實體為基本元素,如:類體、對象,并可使程序系統(tǒng)基于現(xiàn)實實體構建,更加接近現(xiàn)實環(huán)境。5.主流工程方法學結構化方法學是傳統(tǒng)的主流方法學,以功能為76.常用軟件工具

軟件工程的還需要有軟件分析設計工具的支持。一些常用的軟件分析設計工具有:MicrosoftVisio:通用圖形建模工具,可支持結構化分析設計建模。SybasePowerDesigner:專門的數(shù)據(jù)庫建模工具。IBMRationalRose:專門的UML建模工具。6.常用軟件工具軟件工程的還需要有軟件分析設計工具的8第2章

軟件項目管理軟件研發(fā)團隊軟件項目計劃軟件項目成本估算軟件項目風險軟件項目文檔、配置與質(zhì)量管理第2章軟件項目管理軟件研發(fā)團隊91.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。軟件研發(fā)機構應該有健康的可適應軟件研發(fā)任務的組織機體。項目小組則是最小的因項目任務組建的研發(fā)團隊,要求小而精,成員大多限制在8人以內(nèi)。主要成員有:項目負責人、開發(fā)人員、資料管理員、軟件測試員。項目小組有多種管理機制,如:民主分權制、主程序員負責制、職業(yè)項目經(jīng)理負責制、層級負責制。1.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量102.軟件項目計劃為使軟件開發(fā)各項工作有秩序地進行,項目管理者必須事先制定項目開發(fā)計劃。任務分配:進行任務分解,然后合理地、適度地給每個成員分配項目任務。進度安排:對項目任務及其資源按時序進行合理部署。可基于里程碑制定項目進度計劃,一些關鍵性成果,如:需求規(guī)格說明書,可作為項目進度里程碑標志。有許多工具可用來幫助建立項目進度計劃,如:甘特圖、任務網(wǎng)絡圖。項目計劃書則是項目計劃的具體體現(xiàn),可作為軟件開發(fā)的工作指南。2.軟件項目計劃為使軟件開發(fā)各項工作有秩序地進行,項目管理113.軟件項目成本估算軟件項目有來自多方面的成本,如:工資開支、場地費、差旅費、設備費、資料費。但項目最主要成本是人員工資成本。軟件成本估算,主要就是是對人力成本的估算。常用的人力成本成本估算方法有:程序代碼行成本估算、軟件功能點成本估算、軟件過程成本估算。3.軟件項目成本估算軟件項目有來自多方面的成本,如:工資開124.軟件項目風險軟件開發(fā)涉及諸多不確定性,用戶需求的不確定性,技術策略的不確定性,等等。這些不確定因素的存在,使得軟件開發(fā)有了這樣那樣的風險,如:計劃風險、管理風險、需求風險、技術風險、人員風險、產(chǎn)品風險、用戶風險、商業(yè)風險,等等。值得注意的是,風險所影響的是項目的未來結果,我們只能判斷其今后的發(fā)生概率,而并不能夠百分之百地確定其影響。因此,需要對風險實施有效的管理,以降低風險事件的發(fā)生概率。風險管理主要任務有:風險識別:調(diào)查是識別項目風險的有效途徑。可以依據(jù)風險類別進行風險調(diào)查,以對項目風險有較全面的把握。風險評估:風險有多大的發(fā)生概率?風險有多大的影響力?風險防范:可以從風險規(guī)避、風險監(jiān)控與風險應急這三個方面進行風險防范。4.軟件項目風險軟件開發(fā)涉及諸多不確定性,用戶需求的不確定13第3章

軟件工程過程模式軟件生命周期瀑布模式、原型進化模式增量模式、螺旋模式迭代模式、組件復用模式第3章軟件工程過程模式軟件生命周期141.軟件生命周期軟件生存周期是軟件由提出到開發(fā)到投入應用的全過程,基于開發(fā)者立場一般劃分為三個生命段:定義期、開發(fā)期、運行維護期,每個生命段又包含若干個階段任務。1.軟件生命周期軟件生存周期是軟件由提出到開發(fā)到投入應用的152.瀑布模式瀑布模式是最傳統(tǒng)的過程模式,“瀑布”形象表達了其自頂向下、逐級細化的過程特征。瀑布模式的特點是:(1)線性化過程;(2)里程碑管理;(3)階段評審;(4)文檔驅動。對于需求明確的軟件項目,瀑布模式有較好的適應性。然而,如果需求不明確或需求易變更,則瀑布模式就顯現(xiàn)出了不適應性。2.瀑布模式瀑布模式是最傳統(tǒng)的過程模式,“瀑布”形象表達了163.原型進化模式原型進化模式的開發(fā)流程是:開發(fā)者先建立原型系統(tǒng)供用戶評價或使用,然后根據(jù)用戶的意見反饋,對原型系統(tǒng)不斷修正,由此使它逐步接近并最終達到目標系統(tǒng)的要求。原型進化模式可較好適應用戶的需求變更,但卻因缺乏里程碑管理機制,而不能很好支持大型項目。3.原型進化模式原型進化模式的開發(fā)流程是:開發(fā)者先建立原型174.增量模式增量模式是瀑布模式與原型進化模式優(yōu)點的結合,其將系統(tǒng)分解為多個增量構件,然后以增量構件為原型部件,逐步創(chuàng)建、集成與完善。增量模式在整體上具有瀑布模式的里程碑特點,可適應大型項目。但系統(tǒng)的局部構建上,則體現(xiàn)為基于增量構件的原型進化,可適應用戶的需求變更。4.增量模式增量模式是瀑布模式與原型進化模式優(yōu)點的結合,其185.螺旋模式螺旋模式是一種可較好規(guī)避開發(fā)風險的過程模式。螺旋模式的特點是項目基于任務域螺旋式遞進,每一個任務域都需要進行風險評估,并需要根據(jù)評估結論制定有效的風險規(guī)避措施。5.螺旋模式螺旋模式是一種可較好規(guī)避開發(fā)風險的過程模式。螺196.迭代模式迭代模式是軟件的分析、設計與實現(xiàn)可交替反復進行的過程模式。迭代模式有對面向對象方法更好的過程支持,可使面向對象方法獲得更有成效的工程應用。6.迭代模式迭代模式是軟件的分析、設計與實現(xiàn)可交替反復進行20第4章

軟件分析計算機系統(tǒng)結構軟件系統(tǒng)前期分析項目可行性分析軟件需求分析軟件需求驗證第4章軟件分析計算機系統(tǒng)結構211.計算機體系結構幾種典型的計算機體系結構:

中央主機結構:主機集中了全部智能,并依靠終端接口與外部設備連接??蛻魴C/服務器結構:智能分布于服務器與客戶機,并依靠網(wǎng)絡連接成系統(tǒng)。其中,服務器處于核心位置,提供被動核心服務;客戶機處于邊緣位置,可主動訪問服務器,尋求服務支持。瀏覽器/服務器結構:一種更適合互聯(lián)網(wǎng)遠程交互的基于Web應用的特殊的客戶機/服務器結構。1.計算機體系結構幾種典型的計算機體系結構:222.軟件系統(tǒng)前期分析可從以下方面進行軟件高層分析:軟件系統(tǒng)的業(yè)務領域、業(yè)務邊界與業(yè)務流程。軟件系統(tǒng)對硬件設施、網(wǎng)絡環(huán)境、數(shù)據(jù)環(huán)境的依賴。軟件系統(tǒng)的安全層級、措施與防范機制。軟件系統(tǒng)與其它相關系統(tǒng)之間的協(xié)作關系。軟件系統(tǒng)與用戶組織及其工作任務的協(xié)調(diào)性與適應性。2.軟件系統(tǒng)前期分析可從以下方面進行軟件高層分析:233.項目可行性分析

以少量的時間及人力成本,對項目是否可著手實施作出有依據(jù)的判斷,以避免因項目實施條件不具備而造成的大量的人力、物力與時間的浪費??蓮募夹g、經(jīng)濟、應用等幾個方面進行可行性分析,分析結論則需要撰寫成可行性分析報告,并提交有關部門確認。3.項目可行性分析以少量的時間及人力成本,對項目是245.軟件文檔管理軟件文檔是工程模式軟件開發(fā)的成果體現(xiàn)。然而,軟件文檔要能產(chǎn)生很好的工程效應,則還必須要有管理規(guī)范的支持。開發(fā)時必須建立的技術資料、管理資料為正式文檔,通常需要專門歸檔。而根據(jù)需要隨時創(chuàng)建的并且無須歸檔的模型或工作表格則為非正式文檔。按照文檔使用范圍,則又可分為:技術文檔、管理文檔與用戶文檔。5.軟件文檔管理軟件文檔是工程模式軟件開發(fā)的成果體現(xiàn)。然而256.軟件配置管理所謂軟件配置,也就是基于軟件生產(chǎn)軌跡進行過程控制與產(chǎn)品追蹤。其貫穿于整個軟件生命周期,因此可使軟件開發(fā)中產(chǎn)生的各種成果具有一致性。軟件配置的主要任務有:軟件配置規(guī)劃、軟件變更控制、軟件版本控制。6.軟件配置管理所謂軟件配置,也就是基于軟件生產(chǎn)軌跡進行過267.軟件質(zhì)量管理所謂軟件質(zhì)量,也就是對軟件品質(zhì)的優(yōu)劣評價。軟件開發(fā)者應該開發(fā)出高質(zhì)量的軟件產(chǎn)品,以更好地滿足用戶應用。來自經(jīng)驗的結論是:嚴格有效的軟件質(zhì)量管理,可帶來高質(zhì)量的軟件產(chǎn)品。軟件質(zhì)量管理涉及問題有:質(zhì)量標準、質(zhì)量計劃與質(zhì)量控制。7.軟件質(zhì)量管理所謂軟件質(zhì)量,也就是對軟件品質(zhì)的優(yōu)劣評價。277.組件復用模式組件復用模式是對基于組件的系統(tǒng)集成的過程支持。組件復用可帶來了流水線軟件裝配,系統(tǒng)所需組件大多無須專門開發(fā),而可通過專業(yè)制作機構提供,由此可提高軟件開發(fā)效率,并可提高軟件產(chǎn)品質(zhì)量。7.組件復用模式組件復用模式是對基于組件的系統(tǒng)集成的過程支288.分析任務與過程需求分析是為有效解決用戶需求問題而需要進行的一項工程活動,所需考慮的需求問題有:功能需求、數(shù)據(jù)需求、性能需求、接口需求。開發(fā)者與用戶都將參與需求分析活動。開發(fā)者承擔分析任務,但活動核心則是用戶。需求分析任務需要由熟悉用戶業(yè)務的系統(tǒng)分析師承擔。需求分析步驟是:獲取用戶需求、創(chuàng)建需求模型、確定軟件規(guī)格、進行需求驗證。8.分析任務與過程需求分析是為有效解決用戶需求問題而需要進299.獲取用戶需求用戶泛指一切可從軟件獲得服務的對象??梢允悄硞€人,但也可以是人以外的機構、部門、其他系統(tǒng)或設備??赏ㄟ^調(diào)查而獲取用戶需求。然而,有效的需求收集則依賴于有效的調(diào)查提問,并依賴于合適的調(diào)查方法。一些常用調(diào)查方法是:訪談、座談、問卷、跟班、收集資料。來自用戶的需求將體現(xiàn)為需求規(guī)約,其可表達用戶的軟件價值。9.獲取用戶需求用戶泛指一切可從軟件獲得服務的對象??梢允?010.建立需求模型

需求建模是用戶需求問題圖解,一些常用模型有:業(yè)務樹圖、用例圖、活動圖。其中,業(yè)務樹是結構化需求建模,用例圖是系統(tǒng)業(yè)務舉例,活動圖則反映系統(tǒng)工作流程。10.建立需求模型需求建模是用戶需求問題圖解,一些3111.進行需求驗證需求驗證是指對需求分析成果的檢查與確認。主要的需求驗證內(nèi)容有:有效性驗證、一致性驗證、完整性驗證、現(xiàn)實性驗證、可檢驗性驗證??赏ㄟ^需求原型確認或需求評審,而實現(xiàn)需求驗證。11.進行需求驗證需求驗證是指對需求分析成果的檢查與確認。32第5章

軟件設計本章要點:概要設計任務系統(tǒng)構架設計數(shù)據(jù)結構設計程序結構設計軟件算法設計程序編碼第5章軟件設計本章要點:331.設計任務與過程概要設計也叫總體設計,需要確定軟件系統(tǒng)總體構造,涉及系統(tǒng)構架、程序結構、數(shù)據(jù)結構、安全防范、故障處理等諸多方面的設計,以對軟件系統(tǒng)做出總的設計規(guī)劃。概要設計以需求規(guī)格定義為依據(jù),首先要確定的是系統(tǒng)構架,然后以系統(tǒng)構架為基礎,確定系統(tǒng)全局數(shù)據(jù)結構、程序結構,考慮系統(tǒng)安全防范、故障處理措施。1.設計任務與過程概要設計也叫總體設計,需要確定軟件系統(tǒng)總342.系統(tǒng)構架系統(tǒng)構架是軟件系統(tǒng)的基礎框架,需要考慮問題有:系統(tǒng)支持環(huán)境、系統(tǒng)體系結構。系統(tǒng)支持環(huán)境是構建軟件大廈的地基,涉及硬件環(huán)境、軟件環(huán)境、網(wǎng)絡環(huán)境。系統(tǒng)體系結構則為軟件系統(tǒng)總體結構。分層體系是具代表性的軟件體系結構。2.系統(tǒng)構架系統(tǒng)構架是軟件系統(tǒng)的基礎框架,需要考慮問題有:353.數(shù)據(jù)結構數(shù)據(jù)結構是指數(shù)據(jù)元素之間的邏輯關系。程序設計中的數(shù)據(jù)結構,一般是動態(tài)數(shù)據(jù)結構,以服務功能為設計目標。概要設計中,需要考慮的是影響諸多功能、跨越多個模塊的全局性程序數(shù)據(jù)。數(shù)據(jù)庫設計中的數(shù)據(jù)結構則一般是靜態(tài)結構,以建立合理存儲為設計目標,所涉及元素有:數(shù)據(jù)表、數(shù)據(jù)視圖、數(shù)據(jù)索引。3.數(shù)據(jù)結構數(shù)據(jù)結構是指數(shù)據(jù)元素之間的邏輯關系。364.程序結構概要設計需要抽象模塊,并從功能、數(shù)據(jù)、接口等諸多方面定義模塊。結構化程序中的模塊是程序函數(shù)。面向對象程序中的模塊是類體。在基于組件的系統(tǒng)集成中,組件則被看做是模塊。高質(zhì)量程序模塊應該有很好的獨立性,這樣的模塊通常更加安全、穩(wěn)定、可靠,也更加便于維護改造。內(nèi)聚度與耦合度這兩個技術指標可用于判斷模塊是否有較好的獨立性。概要設計還需要確定模塊之間的任務協(xié)作與控制,并設計一個合理的可控制的可擴充的程序結構,以使諸多模塊能夠集成為一個整體。結構化程序的控制是自頂向下的。總控模塊對程序進行頂層整體控制,下級模塊則實現(xiàn)對具體任務的控制與操作。面向對象程序則由類圖、構件圖說明結構。類圖用于描述面向對象程序邏輯結構,構件圖用于描述面向對象程序物理結構。4.程序結構概要設計需要抽象模塊,并從功能、數(shù)據(jù)、接口等諸375.程序結構化流程控制程序結構化流程控制是高清晰度的控制。程序如果能滿足單人口、單出口的要求,則程序是結構化控制。順序、選擇、循環(huán)等控制結構是結構化控制。GOTO語句則是非結構化控制的代表??墒挂粋€程序塊有多個出入口,可降低程序的穩(wěn)定性、可靠性與可維護性。5.程序結構化流程控制程序結構化流程控制是高清晰度的控制。386.程序算法設計工具

程序流程圖、NS圖、PAD圖、PDL語言,是與結構化控制相適應的算法設計工具。6.程序算法設計工具程序流程圖、NS圖、PAD圖、39程序流程圖程序流程圖40NS圖NS圖41PAD圖PAD圖427.算法復雜度評估算法復雜度是對程序算法是否復雜的量化說明。通常,可以從時間和空間兩個方面,對程序算法進行復雜度評價。時間復雜度:由算法執(zhí)行所耗費時間決定。通常,算法中語句的執(zhí)行次數(shù)越多,其花費時間就越多,則時間復雜度就越高??臻g復雜度:由算法所需存儲空間決定。通常,程序中定義的數(shù)據(jù)元素越少,采用的數(shù)據(jù)類型越簡單,則空間復雜度就越低。7.算法復雜度評估算法復雜度是對程序算法是否復雜的量化說明43McCabe方法這是一種基于控制流的廣泛應用的程序算法復雜度評估方法。其定義程序算法復雜度為強連通程序圖中線性無關的有向環(huán)的個數(shù)。計算公式是:V(G)=m–n+1,其中,V是強連通程序圖中的環(huán)數(shù),m是弧數(shù),n是節(jié)點數(shù)。McCabe方法這是一種基于控制流的廣泛應用的程序算法復雜度448.程序編碼編程語言可分為機器語言、匯編語言、傳統(tǒng)高級語言、結構化語言、面向對象語言、第四代程序語言。有必要根據(jù)問題性質(zhì)選擇合適的程序語言,以提高編程質(zhì)量。編程規(guī)范即是為提高程序可讀性、可理解性而需要遵守的約定。一些常用的編碼規(guī)范有:程序注釋、標識符命名、程序編排格式。程序算法設計還必須考慮程序的運行效率,其由程序的算法復雜度、程序中數(shù)據(jù)的類型、程序編譯的優(yōu)化程度等諸多因素決定。8.程序編碼編程語言可分為機器語言、匯編語言、傳統(tǒng)高級語言45第6章

軟件測試本章要點:測試方法與過程測試用例面向對象測試程序調(diào)試測試工具第6章軟件測試本章要點:461.測試目的、計劃與方法軟件測試之根本目的在于發(fā)現(xiàn)軟件錯誤。軟件測試需要事先制定計劃,如:測試時間、測試任務、測試目標、責任人等,即需要通過測試計劃提前確定下來。有黑盒測試與白盒測試兩種基本測試方法。黑盒測試以概要設計中的模塊定義為測試內(nèi)容,主要用于系統(tǒng)確認測試、系統(tǒng)集成測試。白盒測試則以詳細設計中的程序算法說明為測試內(nèi)容,主要用于程序單元測試。1.測試目的、計劃與方法軟件測試之根本目的在于發(fā)現(xiàn)軟件錯誤472.測試任務軟件測試任務有:單元測試、集成測試、確認測試。單元測試是以基本單元模塊為測試對象。一般以白盒測試為主,以黑盒測試為輔。主要測試內(nèi)容有:模塊接口、局部數(shù)據(jù)結構、執(zhí)行路徑、出錯處理、條件邊界等。諸多單元模塊可按照設計好的體系結構進行裝配,在此過程中需要集成測試,以發(fā)現(xiàn)模塊之間是否有連接錯誤。系統(tǒng)有非漸增集成與漸增集成測試兩種集成策略。非漸增集成是一次性把所有模塊組合在一起。漸增集成測試則是每個單元模塊逐個地集成到系統(tǒng)中去。在系統(tǒng)完成集成之后,接著需要進行確認測試,以確認用戶需求是否得以實現(xiàn)。測試內(nèi)容有:軟件有效性驗證、軟件配置復查。測試方法有:Alpha測試、Beta測試。2.測試任務軟件測試任務有:單元測試、集成測試、確認測試。483.測試用例

設計測試用例,就是為測試準備測試數(shù)據(jù)。白盒測試用例為邏輯覆蓋,主要有:語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋和路徑覆蓋等幾種覆蓋形式。黑盒測試用例則有等價類劃分、邊界值分析、錯誤推測等幾種設計方法。3.測試用例設計測試用例,就是為測試準備測試數(shù)據(jù)。494.面向對象程序測試

面向對象程序涉及單元測試、集成測試、確認測試,但測試內(nèi)容不同。在進行面向對象程序單元測試時,已經(jīng)不能孤立地測試單個操作,而應該把操作作為類的一部分來測試。集成測試則反映為基于線程的測試或基于使用的測試。確認測試則體現(xiàn)為用例驅動。4.面向對象程序測試面向對象程序涉及單元測試、集成505.程序調(diào)試診斷發(fā)現(xiàn)錯誤并修正排除錯誤,這即是程序調(diào)試。其中,診斷是關鍵。如果錯誤的性質(zhì)與位置被診斷出來,則改錯只是一件相對簡單的工作。主要診斷方法有:①在程序中插入輸出語句;②使用自動調(diào)式工具。程序調(diào)試策略有:試探法、回溯法、對分查找法、歸納法、演繹法。5.程序調(diào)試診斷發(fā)現(xiàn)錯誤并修正排除錯誤,這即是程序調(diào)試。其516.測試工具測試數(shù)據(jù)生成程序:用于自動生成測試用例。動態(tài)分析程序:用于分析被測程序中某語句的動態(tài)執(zhí)行情況,如:執(zhí)行次數(shù)、執(zhí)行頻率。靜態(tài)分析程序:用于掃描被測試程序正文,并從中發(fā)現(xiàn)程序錯誤。6.測試工具測試數(shù)據(jù)生成程序:用于自動生成測試用例。52第7章

軟件維護與再工程軟件維護分類軟件可維護性軟件維護實施軟件再工程第7章軟件維護與再工程軟件維護分類531.軟件維護分類改正性維護完善性維護適應性維護預防性維護1.軟件維護分類改正性維護542.軟件可維護性軟件可維護性是指維護人員對軟件系統(tǒng)進行修正、改進的難易。影響軟件可維護性的因素有:系統(tǒng)大小、系統(tǒng)文檔、系統(tǒng)年齡??赏ㄟ^軟件的易理解性、可靠性、易修改性、易移植性的評價,而對軟件系統(tǒng)進行可維護性綜合評估。2.軟件可維護性軟件可維護性是指維護人員對軟件系統(tǒng)進行修正553.軟件維護實施開發(fā)組可承擔軟件初期維護,但當軟件轉入正常使用以后,其維護工作則一般由專門的維護機構承擔。軟件維護機構人員組成有:維護負責人、系統(tǒng)監(jiān)督員、配置管理員、維護工程師。其中,維護負責人全權負責維護任務,包括技術與管理兩個方面的工作。維護將由申請報告啟動,其一般由軟件用戶提出。維護機構則對維護申請進行評審。維護活動需要記錄存檔,需要進行評價。3.軟件維護實施開發(fā)組可承擔軟件初期維護,但當軟件轉入正常564.軟件再工程軟件再工程是指對已存在軟件系統(tǒng)的重構與擴充。再工程主要用于一些老系統(tǒng)改造,所涉及活動有:逆向工程、重構工程、正向工程。4.軟件再工程軟件再工程是指對已存在軟件系統(tǒng)的重構與擴充。57第8章

結構化工程方法分析建模特點數(shù)據(jù)、功能與行為建模數(shù)據(jù)、功能與行為定義結構化設計建?;跀?shù)據(jù)流的結構映射程序結構優(yōu)化第8章結構化工程方法分析建模特點581.功能建模功能建模是對系統(tǒng)數(shù)據(jù)加工的圖解。數(shù)據(jù)流圖是最常用的結構化功能建模工具,涉及數(shù)據(jù)接口、數(shù)據(jù)處理、數(shù)據(jù)流、數(shù)據(jù)存儲等圖形元素,用于描述系統(tǒng)數(shù)據(jù)加工細節(jié)。數(shù)據(jù)流可以逐層細化,由此可逐步深入地解剖數(shù)據(jù)處理過程。數(shù)據(jù)流細化一般自頂層業(yè)務環(huán)境開始,然后到1層、2層,由此而逐步深入到系統(tǒng)內(nèi)部獲取功能細節(jié)。前期分析中的業(yè)務樹可用于支持數(shù)據(jù)流功能細化,以方便對功能的逐層解剖。1.功能建模功能建模是對系統(tǒng)數(shù)據(jù)加工的圖解。數(shù)據(jù)流圖是最常592.行為建模行為模型用于說明軟件系統(tǒng)與環(huán)境的交互。狀態(tài)轉換圖是最常用的軟件行為建模工具,涉及狀態(tài)、事件等圖形元素。2.行為建模行為模型用于說明軟件系統(tǒng)與環(huán)境的交互。603.數(shù)據(jù)字典數(shù)據(jù)字典用于定義軟件元素,以使軟件元素獲得嚴密的、詳細的、精確的規(guī)格說明。早期軟件開發(fā)中,數(shù)據(jù)字典需要使用手工方式創(chuàng)建與維護。目前軟件開發(fā)中,數(shù)據(jù)字典可依靠CASE工具自動生成與維護。需求分析模型中的數(shù)據(jù)、功能、行為等諸多方面的元素,都有必要通過數(shù)據(jù)字典給予細節(jié)說明,以達到對系統(tǒng)較完整全面的規(guī)格定義。3.數(shù)據(jù)字典數(shù)據(jù)字典用于定義軟件元素,以使軟件元素獲得嚴密614.設計建模常用的結構化圖形建模語言是:程序結構圖、H-IPO圖。程序結構圖比較適合設計者構思程序結構,但模塊功能特征較難由模型體現(xiàn),因此在模型之外還需要有對模塊的詳細說明。H-IPO圖則可帶來較高的建模清晰度,其由“H圖”與“IPO圖”組合。H圖表示程序結構,IPO圖則定義模塊,描述模塊:輸入、處理、輸出。程序結構還可表示為框架偽碼,以方便由結構設計到算法設計的過渡。4.設計建模常用的結構化圖形建模語言是:程序結構圖、H-I625.結構化程序結構映射基于數(shù)據(jù)流的結構映射,是以功能為目標的結構化建模方法的延伸,可達到由功能分析到功能設計的有效轉換。數(shù)據(jù)流可分為變換流與事務流,并可根據(jù)其特征,分別按不同方法進行結構映射。5.結構化程序結構映射基于數(shù)據(jù)流的結構映射,是以功能為目標637.程序結構優(yōu)化通過數(shù)據(jù)流映射只能獲取程序的基本框架,一般還需要對程序結構進行結構優(yōu)化??蓮哪K獨立性、模塊接口復雜度、程序過程流暢性、程序構造簡潔性等諸多方面,對程序結構進行優(yōu)化。一些源于經(jīng)驗的啟發(fā)性原則,可為程序結構優(yōu)化提供指導性參考。7.程序結構優(yōu)化通過數(shù)據(jù)流映射只能獲取程序的基本框架,一般64第9章

面向對象工程方法UML特點用例建?;顒咏嶓w類分析建模系統(tǒng)邏輯結構建模程序對象交互建模系統(tǒng)物理裝配與部署第9章面向對象工程方法UML特點651.UML特點UML是統(tǒng)一建模語言,有統(tǒng)一的語法規(guī)則、語義規(guī)則與語用規(guī)則,并可從多個不同視角建立軟件模型。UML的建模的過程特點是:用例驅動、以構架為中心、增量迭代。UML通過包實現(xiàn)了對模型的有效的一體化的管理。1.UML特點UML是統(tǒng)一建模語言,有統(tǒng)一的語法規(guī)則、語義662.用例建模用例建模是面向用戶需求的,能夠反映系統(tǒng)的用戶價值。用例圖中的基本元素有:用例:用戶業(yè)務級程序實例,使用橢圓圖標表示。參與者:可與系統(tǒng)進行主動交流的外部環(huán)境元素,使用人形圖標表示。交流:系統(tǒng)與用戶之間的交互或通信,使用連線表示。參與者之間可建立泛化關系。用例之間有泛化、延伸、包含關系。2.用例建模用例建模是面向用戶需求的,能夠反映系統(tǒng)的用戶價673.活動建?;顒訄D用于描述系統(tǒng)動態(tài)過程,主要圖形元素有:活動、轉換、起點、終點、判斷、并發(fā)、同步、泳道等??墒褂没顒訄D說明高層業(yè)務級活動,這通常涉及整個業(yè)務流程。也可針對每個用例進行活動建模,以反映用例內(nèi)部活動細節(jié)。3.活動建模活動圖用于描述系統(tǒng)動態(tài)過程,主要圖形元素有:活684.類分析建模面向對象程序涉及控制類、邊界類、實體類,分析中主要考慮的是實體類。類分析建模首要工作是發(fā)現(xiàn)實體類??墒褂妹~搜索法發(fā)現(xiàn)候選類,然后再從候選類中篩選出實體類。實體類所代表的數(shù)據(jù)相互之間通常有一定的關系。依靠這種關系可形成有組織的程序數(shù)據(jù)結構。實體類之間的主要數(shù)據(jù)關系有:關聯(lián)、聚集、泛化。4.類分析建模面向對象程序涉及控制類、邊界類、實體類,分析695.面向對象設計方法結構化程序設計以功能為依據(jù),并以實現(xiàn)功能為目標。面向對象程序則有與結構化程序不同的內(nèi)部構造與運行機制,因此需要有不同于結構化程序的專門的設計方法的支持。面向對象程序是以實體為依據(jù),并基于實體及其控制確定程序結構,并還需要考察對象行為,說明對象動態(tài)行為過程。UML可提供面向對象設計建模。所涉及模型有:設計類圖、狀態(tài)圖、協(xié)作圖、時序圖、構件圖、部署圖。設計建模應是合乎邏輯的推論,并需要從邏輯結構、動態(tài)過程與物理結構這三個方面的建模。5.面向對象設計方法結構化程序設計以功能為依據(jù),并以實現(xiàn)功706.邏輯結構設計系統(tǒng)構架是構造程序系統(tǒng)的基本框架,需要優(yōu)先考慮。分層構架則是一種常用的構架模式,其特點是程序系統(tǒng)按功能支持分層構建,如:應用層、中間件層、系統(tǒng)層等。應用程序框架則涉及程序構造。一個復雜的程序系統(tǒng),可被劃分為諸多相對簡單的任務子系統(tǒng)。這樣的任務子系統(tǒng),大多有一定的獨立性,并是搭建程序框架的基本元素。6.邏輯結構設計系統(tǒng)構架是構造程序系統(tǒng)的基本框架,需要優(yōu)先717.動態(tài)過程設計動態(tài)過程模型有:協(xié)作圖、時序圖、狀態(tài)圖。協(xié)作圖可說明對象之間的動態(tài)交互。協(xié)作圖建模也將依靠用例驅動。已經(jīng)獲得的基于用例的類關系模型,可作為協(xié)作建模的結構背景,由此可獲取到有關對象的協(xié)作框架。時序圖也是針對對象的動態(tài)行為建模,但基于對象生命線說明對象交互,因此有比協(xié)作圖更加直觀清晰的時序說明。狀態(tài)圖可描述對象狀態(tài)及其遷移。通常,狀態(tài)圖中的對象是一個取自系統(tǒng)的個體元素。因此,在對某個對象進行狀態(tài)考察時,并無須過多考慮它與其他對象的交互。7.動態(tài)過程設計動態(tài)過程模型有:協(xié)作圖、時序圖、狀態(tài)圖。728.物理裝配與部署構件圖是軟件系統(tǒng)物理建模,用于反映軟件系統(tǒng)基于構件的物理集成與裝配。部署圖可說明程序系統(tǒng)的安裝部署,可反映程序系統(tǒng)運行時,各種將駐留或執(zhí)行程序的計算機設備之間的物理關聯(lián)。8.物理裝配與部署構件圖是軟件系統(tǒng)物理建模,用于反映軟件系73

第1章

軟件工程綜述

本章要點:軟件特點與分類軟件工程及其發(fā)展軟件危機現(xiàn)象與原因工程技術與工程管理主流工程方法學第1章軟件工程綜述

本章要點:741.軟件有什么特點

計算機系統(tǒng)由硬件、軟件兩部分組成。硬件是物理部件,如:處理器、存儲器、主板總線,具有一定的物理形態(tài),能夠獨立存在。軟件則是物理硬件以外的邏輯部件,如:程序、數(shù)據(jù)、文檔,抽象無形,不能獨立存在。

軟件工程需要研究如何更有成效地研發(fā)軟件、維護軟件,要達到這個目標,則必然需要對軟件有很好的認識。1.軟件有什么特點

計算機系統(tǒng)由硬件、軟件兩部分組成752.什么是軟件工程

軟件工程是關于軟件開發(fā)、使用與維護的工程方法學,是一門涉及工程技術、工程管理與工程經(jīng)濟等諸多內(nèi)容的綜合性工程學科。軟件工程建立在與軟件有關的工程概念、原理與方法基礎上,它是對現(xiàn)實軟件問題的工程方法探索,具有鮮明的工程實用性。2.什么是軟件工程

軟件工程是關于軟件開發(fā)、使用與761.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。軟件研發(fā)機構應該有健康的可適應軟件研發(fā)任務的組織機體。項目小組則是最小的因項目任務組建的研發(fā)團隊,要求小而精,成員大多限制在8人以內(nèi)。主要成員有:項目負責人、開發(fā)人員、資料管理員、軟件測試員。項目小組有多種管理機制,如:民主分權制、主程序員負責制、職業(yè)項目經(jīng)理負責制、層級負責制。1.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量773.為什么會發(fā)生軟件危機20世紀60年代中期,軟件開發(fā)者遭遇到了軟件危機。主要危機現(xiàn)象有:軟件開發(fā)成本進度難估算、軟件質(zhì)量沒有保證、軟件不能滿足應用需要、軟件缺乏可維護性。

危機客觀原因:軟件的邏輯隱蔽性、軟件的復雜性、軟件的低產(chǎn)業(yè)發(fā)展水平。

危機主管原因:漠視用戶需求、重結果輕過程、個人英雄理念。3.為什么會發(fā)生軟件危機20世紀60年代中期,軟件開784.軟件工程技術、管理與目標

軟件工程涉及的技術問題有:

軟件過程:實現(xiàn)軟件的步驟與工程框架;

工程方法:實現(xiàn)軟件的技術性要素,如:工程規(guī)范、工程策略、技術手段等。

軟件工具:對工程方法與軟件過程的自動化或半自動化支持。

軟件工程涉及的管理問題有:項目管理、人員管理、過程管理、產(chǎn)品管理。

軟件工程還必須考慮工程目標,以體現(xiàn)其工程價值。一些主要的工程目標是:降低成本、滿足需求、改善性能、提高質(zhì)量、及時交付。4.軟件工程技術、管理與目標軟件工程涉及的技術問題795.主流工程方法學結構化方法學是傳統(tǒng)的主流方法學,以功能為基本元素,包括結構化分析(SA)、結構化設計(SD)與結構化實現(xiàn)(SP),可對整個軟件生命周期提供方法學支持。面向對象方法學則是目前的主流方法學,包括面向對象分析(OOA)、面向對象設計(OOD)與面向對象實現(xiàn)(OOA),可對整個軟件生命周期提供方法學支持。其以實體為基本元素,如:類體、對象,并可使程序系統(tǒng)基于現(xiàn)實實體構建,更加接近現(xiàn)實環(huán)境。5.主流工程方法學結構化方法學是傳統(tǒng)的主流方法學,以功能為806.常用軟件工具

軟件工程的還需要有軟件分析設計工具的支持。一些常用的軟件分析設計工具有:MicrosoftVisio:通用圖形建模工具,可支持結構化分析設計建模。SybasePowerDesigner:專門的數(shù)據(jù)庫建模工具。IBMRationalRose:專門的UML建模工具。6.常用軟件工具軟件工程的還需要有軟件分析設計工具的81第2章

軟件項目管理軟件研發(fā)團隊軟件項目計劃軟件項目成本估算軟件項目風險軟件項目文檔、配置與質(zhì)量管理第2章軟件項目管理軟件研發(fā)團隊821.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量的軟件產(chǎn)品。軟件研發(fā)機構應該有健康的可適應軟件研發(fā)任務的組織機體。項目小組則是最小的因項目任務組建的研發(fā)團隊,要求小而精,成員大多限制在8人以內(nèi)。主要成員有:項目負責人、開發(fā)人員、資料管理員、軟件測試員。項目小組有多種管理機制,如:民主分權制、主程序員負責制、職業(yè)項目經(jīng)理負責制、層級負責制。1.軟件研發(fā)團隊需要組建優(yōu)秀的軟件研發(fā)團隊,以生產(chǎn)出高質(zhì)量832.軟件項目計劃為使軟件開發(fā)各項工作有秩序地進行,項目管理者必須事先制定項目開發(fā)計劃。任務分配:進行任務分解,然后合理地、適度地給每個成員分配項目任務。進度安排:對項目任務及其資源按時序進行合理部署??苫诶锍瘫贫椖窟M度計劃,一些關鍵性成果,如:需求規(guī)格說明書,可作為項目進度里程碑標志。有許多工具可用來幫助建立項目進度計劃,如:甘特圖、任務網(wǎng)絡圖。項目計劃書則是項目計劃的具體體現(xiàn),可作為軟件開發(fā)的工作指南。2.軟件項目計劃為使軟件開發(fā)各項工作有秩序地進行,項目管理843.軟件項目成本估算軟件項目有來自多方面的成本,如:工資開支、場地費、差旅費、設備費、資料費。但項目最主要成本是人員工資成本。軟件成本估算,主要就是是對人力成本的估算。常用的人力成本成本估算方法有:程序代碼行成本估算、軟件功能點成本估算、軟件過程成本估算。3.軟件項目成本估算軟件項目有來自多方面的成本,如:工資開854.軟件項目風險軟件開發(fā)涉及諸多不確定性,用戶需求的不確定性,技術策略的不確定性,等等。這些不確定因素的存在,使得軟件開發(fā)有了這樣那樣的風險,如:計劃風險、管理風險、需求風險、技術風險、人員風險、產(chǎn)品風險、用戶風險、商業(yè)風險,等等。值得注意的是,風險所影響的是項目的未來結果,我們只能判斷其今后的發(fā)生概率,而并不能夠百分之百地確定其影響。因此,需要對風險實施有效的管理,以降低風險事件的發(fā)生概率。風險管理主要任務有:風險識別:調(diào)查是識別項目風險的有效途徑??梢砸罁?jù)風險類別進行風險調(diào)查,以對項目風險有較全面的把握。風險評估:風險有多大的發(fā)生概率?風險有多大的影響力?風險防范:可以從風險規(guī)避、風險監(jiān)控與風險應急這三個方面進行風險防范。4.軟件項目風險軟件開發(fā)涉及諸多不確定性,用戶需求的不確定86第3章

軟件工程過程模式軟件生命周期瀑布模式、原型進化模式增量模式、螺旋模式迭代模式、組件復用模式第3章軟件工程過程模式軟件生命周期871.軟件生命周期軟件生存周期是軟件由提出到開發(fā)到投入應用的全過程,基于開發(fā)者立場一般劃分為三個生命段:定義期、開發(fā)期、運行維護期,每個生命段又包含若干個階段任務。1.軟件生命周期軟件生存周期是軟件由提出到開發(fā)到投入應用的882.瀑布模式瀑布模式是最傳統(tǒng)的過程模式,“瀑布”形象表達了其自頂向下、逐級細化的過程特征。瀑布模式的特點是:(1)線性化過程;(2)里程碑管理;(3)階段評審;(4)文檔驅動。對于需求明確的軟件項目,瀑布模式有較好的適應性。然而,如果需求不明確或需求易變更,則瀑布模式就顯現(xiàn)出了不適應性。2.瀑布模式瀑布模式是最傳統(tǒng)的過程模式,“瀑布”形象表達了893.原型進化模式原型進化模式的開發(fā)流程是:開發(fā)者先建立原型系統(tǒng)供用戶評價或使用,然后根據(jù)用戶的意見反饋,對原型系統(tǒng)不斷修正,由此使它逐步接近并最終達到目標系統(tǒng)的要求。原型進化模式可較好適應用戶的需求變更,但卻因缺乏里程碑管理機制,而不能很好支持大型項目。3.原型進化模式原型進化模式的開發(fā)流程是:開發(fā)者先建立原型904.增量模式增量模式是瀑布模式與原型進化模式優(yōu)點的結合,其將系統(tǒng)分解為多個增量構件,然后以增量構件為原型部件,逐步創(chuàng)建、集成與完善。增量模式在整體上具有瀑布模式的里程碑特點,可適應大型項目。但系統(tǒng)的局部構建上,則體現(xiàn)為基于增量構件的原型進化,可適應用戶的需求變更。4.增量模式增量模式是瀑布模式與原型進化模式優(yōu)點的結合,其915.螺旋模式螺旋模式是一種可較好規(guī)避開發(fā)風險的過程模式。螺旋模式的特點是項目基于任務域螺旋式遞進,每一個任務域都需要進行風險評估,并需要根據(jù)評估結論制定有效的風險規(guī)避措施。5.螺旋模式螺旋模式是一種可較好規(guī)避開發(fā)風險的過程模式。螺926.迭代模式迭代模式是軟件的分析、設計與實現(xiàn)可交替反復進行的過程模式。迭代模式有對面向對象方法更好的過程支持,可使面向對象方法獲得更有成效的工程應用。6.迭代模式迭代模式是軟件的分析、設計與實現(xiàn)可交替反復進行93第4章

軟件分析計算機系統(tǒng)結構軟件系統(tǒng)前期分析項目可行性分析軟件需求分析軟件需求驗證第4章軟件分析計算機系統(tǒng)結構941.計算機體系結構幾種典型的計算機體系結構:

中央主機結構:主機集中了全部智能,并依靠終端接口與外部設備連接??蛻魴C/服務器結構:智能分布于服務器與客戶機,并依靠網(wǎng)絡連接成系統(tǒng)。其中,服務器處于核心位置,提供被動核心服務;客戶機處于邊緣位置,可主動訪問服務器,尋求服務支持。瀏覽器/服務器結構:一種更適合互聯(lián)網(wǎng)遠程交互的基于Web應用的特殊的客戶機/服務器結構。1.計算機體系結構幾種典型的計算機體系結構:952.軟件系統(tǒng)前期分析可從以下方面進行軟件高層分析:軟件系統(tǒng)的業(yè)務領域、業(yè)務邊界與業(yè)務流程。軟件系統(tǒng)對硬件設施、網(wǎng)絡環(huán)境、數(shù)據(jù)環(huán)境的依賴。軟件系統(tǒng)的安全層級、措施與防范機制。軟件系統(tǒng)與其它相關系統(tǒng)之間的協(xié)作關系。軟件系統(tǒng)與用戶組織及其工作任務的協(xié)調(diào)性與適應性。2.軟件系統(tǒng)前期分析可從以下方面進行軟件高層分析:963.項目可行性分析

以少量的時間及人力成本,對項目是否可著手實施作出有依據(jù)的判斷,以避免因項目實施條件不具備而造成的大量的人力、物力與時間的浪費。可從技術、經(jīng)濟、應用等幾個方面進行可行性分析,分析結論則需要撰寫成可行性分析報告,并提交有關部門確認。3.項目可行性分析以少量的時間及人力成本,對項目是975.軟件文檔管理軟件文檔是工程模式軟件開發(fā)的成果體現(xiàn)。然而,軟件文檔要能產(chǎn)生很好的工程效應,則還必須要有管理規(guī)范的支持。開發(fā)時必須建立的技術資料、管理資料為正式文檔,通常需要專門歸檔。而根據(jù)需要隨時創(chuàng)建的并且無須歸檔的模型或工作表格則為非正式文檔。按照文檔使用范圍,則又可分為:技術文檔、管理文檔與用戶文檔。5.軟件文檔管理軟件文檔是工程模式軟件開發(fā)的成果體現(xiàn)。然而986.軟件配置管理所謂軟件配置,也就是基于軟件生產(chǎn)軌跡進行過程控制與產(chǎn)品追蹤。其貫穿于整個軟件生命周期,因此可使軟件開發(fā)中產(chǎn)生的各種成果具有一致性。軟件配置的主要任務有:軟件配置規(guī)劃、軟件變更控制、軟件版本控制。6.軟件配置管理所謂軟件配置,也就是基于軟件生產(chǎn)軌跡進行過997.軟件質(zhì)量管理所謂軟件質(zhì)量,也就是對軟件品質(zhì)的優(yōu)劣評價。軟件開發(fā)者應該開發(fā)出高質(zhì)量的軟件產(chǎn)品,以更好地滿足用戶應用。來自經(jīng)驗的結論是:嚴格有效的軟件質(zhì)量管理,可帶來高質(zhì)量的軟件產(chǎn)品。軟件質(zhì)量管理涉及問題有:質(zhì)量標準、質(zhì)量計劃與質(zhì)量控制。7.軟件質(zhì)量管理所謂軟件質(zhì)量,也就是對軟件品質(zhì)的優(yōu)劣評價。1007.組件復用模式組件復用模式是對基于組件的系統(tǒng)集成的過程支持。組件復用可帶來了流水線軟件裝配,系統(tǒng)所需組件大多無須專門開發(fā),而可通過專業(yè)制作機構提供,由此可提高軟件開發(fā)效率,并可提高軟件產(chǎn)品質(zhì)量。7.組件復用模式組件復用模式是對基于組件的系統(tǒng)集成的過程支1018.分析任務與過程需求分析是為有效解決用戶需求問題而需要進行的一項工程活動,所需考慮的需求問題有:功能需求、數(shù)據(jù)需求、性能需求、接口需求。開發(fā)者與用戶都將參與需求分析活動。開發(fā)者承擔分析任務,但活動核心則是用戶。需求分析任務需要由熟悉用戶業(yè)務的系統(tǒng)分析師承擔。需求分析步驟是:獲取用戶需求、創(chuàng)建需求模型、確定軟件規(guī)格、進行需求驗證。8.分析任務與過程需求分析是為有效解決用戶需求問題而需要進1029.獲取用戶需求用戶泛指一切可從軟件獲得服務的對象??梢允悄硞€人,但也可以是人以外的機構、部門、其他系統(tǒng)或設備??赏ㄟ^調(diào)查而獲取用戶需求。然而,有效的需求收集則依賴于有效的調(diào)查提問,并依賴于合適的調(diào)查方法。一些常用調(diào)查方法是:訪談、座談、問卷、跟班、收集資料。來自用戶的需求將體現(xiàn)為需求規(guī)約,其可表達用戶的軟件價值。9.獲取用戶需求用戶泛指一切可從軟件獲得服務的對象??梢允?0310.建立需求模型

需求建模是用戶需求問題圖解,一些常用模型有:業(yè)務樹圖、用例圖、活動圖。其中,業(yè)務樹是結構化需求建模,用例圖是系統(tǒng)業(yè)務舉例,活動圖則反映系統(tǒng)工作流程。10.建立需求模型需求建模是用戶需求問題圖解,一些10411.進行需求驗證需求驗證是指對需求分析成果的檢查與確認。主要的需求驗證內(nèi)容有:有效性驗證、一致性驗證、完整性驗證、現(xiàn)實性驗證、可檢驗性驗證??赏ㄟ^需求原型確認或需求評審,而實現(xiàn)需求驗證。11.進行需求驗證需求驗證是指對需求分析成果的檢查與確認。105第5章

軟件設計本章要點:概要設計任務系統(tǒng)構架設計數(shù)據(jù)結構設計程序結構設計軟件算法設計程序編碼第5章軟件設計本章要點:1061.設計任務與過程概要設計也叫總體設計,需要確定軟件系統(tǒng)總體構造,涉及系統(tǒng)構架、程序結構、數(shù)據(jù)結構、安全防范、故障處理等諸多方面的設計,以對軟件系統(tǒng)做出總的設計規(guī)劃。概要設計以需求規(guī)格定義為依據(jù),首先要確定的是系統(tǒng)構架,然后以系統(tǒng)構架為基礎,確定系統(tǒng)全局數(shù)據(jù)結構、程序結構,考慮系統(tǒng)安全防范、故障處理措施。1.設計任務與過程概要設計也叫總體設計,需要確定軟件系統(tǒng)總1072.系統(tǒng)構架系統(tǒng)構架是軟件系統(tǒng)的基礎框架,需要考慮問題有:系統(tǒng)支持環(huán)境、系統(tǒng)體系結構。系統(tǒng)支持環(huán)境是構建軟件大廈的地基,涉及硬件環(huán)境、軟件環(huán)境、網(wǎng)絡環(huán)境。系統(tǒng)體系結構則為軟件系統(tǒng)總體結構。分層體系是具代表性的軟件體系結構。2.系統(tǒng)構架系統(tǒng)構架是軟件系統(tǒng)的基礎框架,需要考慮問題有:1083.數(shù)據(jù)結構數(shù)據(jù)結構是指數(shù)據(jù)元素之間的邏輯關系。程序設計中的數(shù)據(jù)結構,一般是動態(tài)數(shù)據(jù)結構,以服務功能為設計目標。概要設計中,需要考慮的是影響諸多功能、跨越多個模塊的全局性程序數(shù)據(jù)。數(shù)據(jù)庫設計中的數(shù)據(jù)結構則一般是靜態(tài)結構,以建立合理存儲為設計目標,所涉及元素有:數(shù)據(jù)表、數(shù)據(jù)視圖、數(shù)據(jù)索引。3.數(shù)據(jù)結構數(shù)據(jù)結構是指數(shù)據(jù)元素之間的邏輯關系。1094.程序結構概要設計需要抽象模塊,并從功能、數(shù)據(jù)、接口等諸多方面定義模塊。結構化程序中的模塊是程序函數(shù)。面向對象程序中的模塊是類體。在基于組件的系統(tǒng)集成中,組件則被看做是模塊。高質(zhì)量程序模塊應該有很好的獨立性,這樣的模塊通常更加安全、穩(wěn)定、可靠,也更加便于維護改造。內(nèi)聚度與耦合度這兩個技術指標可用于判斷模塊是否有較好的獨立性。概要設計還需要確定模塊之間的任務協(xié)作與控制,并設計一個合理的可控制的可擴充的程序結構,以使諸多模塊能夠集成為一個整體。結構化程序的控制是自頂向下的??偪啬K對程序進行頂層整體控制,下級模塊則實現(xiàn)對具體任務的控制與操作。面向對象程序則由類圖、構件圖說明結構。類圖用于描述面向對象程序邏輯結構,構件圖用于描述面向對象程序物理結構。4.程序結構概要設計需要抽象模塊,并從功能、數(shù)據(jù)、接口等諸1105.程序結構化流程控制程序結構化流程控制是高清晰度的控制。程序如果能滿足單人口、單出口的要求,則程序是結構化控制。順序、選擇、循環(huán)等控制結構是結構化控制。GOTO語句則是非結構化控制的代表。可使一個程序塊有多個出入口,可降低程序的穩(wěn)定性、可靠性與可維護性。5.程序結構化流程控制程序結構化流程控制是高清晰度的控制。1116.程序算法設計工具

程序流程圖、NS圖、PAD圖、PDL語言,是與結構化控制相適應的算法設計工具。6.程序算法設計工具程序流程圖、NS圖、PAD圖、112程序流程圖程序流程圖113NS圖NS圖114PAD圖PAD圖1157.算法復雜度評估算法復雜度是對程序算法是否復雜的量化說明。通常,可以從時間和空間兩個方面,對程序算法進行復雜度評價。時間復雜度:由算法執(zhí)行所耗費時間決定。通常,算法中語句的執(zhí)行次數(shù)越多,其花費時間就越多,則時間復雜度就越高??臻g復雜度:由算法所需存儲空間決定。通常,程序中定義的數(shù)據(jù)元素越少,采用的數(shù)據(jù)類型越簡單,則空間復雜度就越低。7.算法復雜度評估算法復雜度是對程序算法是否復雜的量化說明116McCabe方法這是一種基于控制流的廣泛應用的程序算法復雜度評估方法。其定義程序算法復雜度為強連通程序圖中線性無關的有向環(huán)的個數(shù)。計算公式是:V(G)=m–n+1,其中,V是強連通程序圖中的環(huán)數(shù),m是弧數(shù),n是節(jié)點數(shù)。McCabe方法這是一種基于控制流的廣泛應用的程序算法復雜度1178.程序編碼編程語言可分為機器語言、匯編語言、傳統(tǒng)高級語言、結構化語言、面向對象語言、第四代程序語言。有必要根據(jù)問題性質(zhì)選擇合適的程序語言,以提高編程質(zhì)量。編程規(guī)范即是為提高程序可讀性、可理解性而需要遵守的約定。一些常用的編碼規(guī)范有:程序注釋、標識符命名、程序編排格式。程序算法設計還必須考慮程序的運行效率,其由程序的算法復雜度、程序中數(shù)據(jù)的類型、程序編譯的優(yōu)化程度等諸多因素決定。8.程序編碼編程語言可分為機器語言、匯編語言、傳統(tǒng)高級語言118第6章

軟件測試本章要點:測試方法與過程測試用例面向對象測試程序調(diào)試測試工具第6章軟件測試本章要點:1191.測試目的、計劃與方法軟件測試之根本目的在于發(fā)現(xiàn)軟件錯誤。軟件測試需要事先制定計劃,如:測試時間、測試任務、測試目標、責任人等,即需要通過測試計劃提前確定下來。有黑盒測試與白盒測試兩種基本測試方法。黑盒測試以概要設計中的模塊定義為測試內(nèi)容,主要用于系統(tǒng)確認測試、系統(tǒng)集成測試。白盒測試則以詳細設計中的程序算法說明為測試內(nèi)容,主要用于程序單元測試。1.測試目的、計劃與方法軟件測試之根本目的在于發(fā)現(xiàn)軟件錯誤1202.測試任務軟件測試任務有:單元測試、集成測試、確認測試。單元測試是以基本單元模塊為測試對象。一般以白盒測試為主,以黑盒測試為輔。主要測試內(nèi)容有:模塊接口、局部數(shù)據(jù)結構、執(zhí)行路徑、出錯處理、條件邊界等。諸多單元模塊可按照設計好的體系結構進行裝配,在此過程中需要集成測試,以發(fā)現(xiàn)模塊之間是否有連接錯誤。系統(tǒng)有非漸增集成與漸增集成測試兩種集成策略。非漸增集成是一次性把所有模塊組合在一起。漸增集成測試則是每個單元模塊逐個地集成到系統(tǒng)中去。在系統(tǒng)完成集成之后,接著需要進行確認測試,以確認用戶需求是否得以實現(xiàn)。測試內(nèi)容有:軟件有效性驗證、軟件配置復查。測試方法有:Alpha測試、Beta測試。2.測試任務軟件測試任務有:單元測試、集成測試、確認測試。1213.測試用例

設計測試用例,就是為測試準備測試數(shù)據(jù)。白盒測試用例為邏輯覆蓋,主要有:語句覆蓋、判定覆蓋、條件覆蓋、判定條件覆蓋、條件組合覆蓋和路徑覆蓋等幾種覆蓋形式。黑盒測試用例則有等價類劃分、邊界值分析、錯誤推測等幾種設計方法。3.測試用例設計測試用例,就是為測試準備測試數(shù)據(jù)。1224.面向對象程序測試

面向對象程序涉及單元測試、集成測試、確認測試,但測試內(nèi)容不同。在進行面向對象程序單元測試時,已經(jīng)不能孤立地測試單個操作,而應該把操作作為類的一部分來測試。集成測試則反映為基于線程的測試或基于使用的測試。確認測試則體現(xiàn)為用例驅動。4.面向對象程序測試面向對象程序涉及單元測試、集成1235.程序調(diào)試診斷發(fā)現(xiàn)錯誤并修正排除錯誤,這即是程序調(diào)試。其中,診斷是關鍵。如果錯誤的性質(zhì)與位置被診斷出來,則改錯只是一件相對簡單的工作。主要診斷方法有:①在程序中插入輸出語句;②使用自動調(diào)式工具。程序調(diào)試策略有:試探法、回溯法、對分查找法、歸納法、演繹法。5.程序調(diào)試診斷發(fā)現(xiàn)錯誤并修正排除錯誤,這即是程序調(diào)試。其1246.測試工具測試數(shù)據(jù)生成程序:用于自動生成測試用例。動態(tài)分析程序:用于分析被測程序中某語句的動態(tài)執(zhí)行情況,如:執(zhí)行次數(shù)、執(zhí)行頻率。靜態(tài)分析程序:用于掃描被測試程序正文,并從中發(fā)現(xiàn)程序錯誤。6.測試工具測試數(shù)據(jù)生成程序:用于自動生成測試用例。125第7章

軟件維護與再工程軟件維護分類軟件可維護性軟件維護實施軟件再工程第7章軟件維護與再工程軟件維護分類1261.軟件維護分類改正性維護完善性維護適應性維護預防性維護1.軟件維護分類改正性維護1272.軟件可維護性軟件可維護性是指維護人員對軟件系統(tǒng)進行修正、改進的難易。影響軟件可維護性的因素有:系統(tǒng)大小、系統(tǒng)文檔、系統(tǒng)年齡??赏ㄟ^軟件的易理解性、可靠性、易修改性、易移植性的評價,而對軟件系統(tǒng)進行可維護性綜合評估。2.軟件可維護性軟件可維護性是指維護人員對軟件系統(tǒng)進行修正1283.軟件維護實施開發(fā)組可承擔軟件初期維護,但當軟件轉入正常使用以后,其維護工作則一般由專門的維護機構承擔。軟件維護機構人員組成有:維護負責人、系統(tǒng)監(jiān)督員、配置管理員、維護工程師。其中,維護負責人全權負責維護任務,包括技術與管理兩個方面的工作。維護將由申請報告啟動,其一般由軟件用戶提出。維護機構則對維護申請進行評審。維護活動需要記錄存檔,需要進行評價。3.軟件維護實施開發(fā)組可承擔軟件初期維護,但當軟件轉入正常1294.軟件再工程軟件再工程是指對已存在軟件系統(tǒng)的重構與擴充。再工程主要用于一些老系統(tǒng)改造,所涉及活動有:逆向工程、重構工程、正向工程。4.軟件再工程軟件再工程是指對已存在軟件系統(tǒng)的重構與擴充。130第8章

結構化工程方法分析建模特點數(shù)據(jù)、功能與行為建模數(shù)據(jù)、功能與行為定義結構化設計建?;跀?shù)據(jù)流的結構映射程序結構優(yōu)化第8章結構化工程方法分析建模特點1311.功能建模功能建模是對系統(tǒng)數(shù)據(jù)加工的圖解。數(shù)據(jù)流圖是最常用的結構化功能建模工具,涉及數(shù)據(jù)接口、數(shù)據(jù)處理、數(shù)據(jù)流、數(shù)據(jù)存儲等圖形元素,用于描述系統(tǒng)數(shù)據(jù)加工細節(jié)。數(shù)據(jù)流可以逐層細化,由此可逐步深入地解剖數(shù)據(jù)處理過程。數(shù)據(jù)流細化一般自頂層業(yè)務環(huán)境開始,然后到1層、2層,由此而逐步深入到系統(tǒng)內(nèi)部獲取功能細節(jié)。前期分析中的業(yè)務樹可用于支持數(shù)據(jù)流功能細化,以方便對功能的逐層解剖。1.功能建模功能建模是對系統(tǒng)數(shù)據(jù)加工的圖解。數(shù)據(jù)流圖是最常1322.行為建模行為模型用于說明軟件系統(tǒng)與環(huán)境的交互。狀態(tài)轉換圖是最常用的軟件行為建模工具,涉及狀態(tài)、

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論