復(fù)旦MSE復(fù)習(xí)資料-軟件工程部分(SE01 概論)

1、1軟件工程復(fù)旦大學(xué)MSE考前輔導(dǎo)2021年10月 2參考書?軟件工程：實(shí)踐者的研究方法第6版 ?美roger s.pressman(著) ，鄭人杰,馬素霞,白曉穎 等(譯) ，機(jī)械工業(yè)出版社，7111194004 |，2007-01-01軟件工程導(dǎo)論第四版張海潘 編著，清華大學(xué)出版社，2003軟件工程第二版齊治昌 譚慶平 寧洪著，高等教育出版社，2005實(shí)用軟件工程第二版鄭人杰、殷人昆、陶永雷，清華大學(xué)出版社，1997年3 計(jì)算機(jī)軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論4計(jì)算機(jī)軟件 計(jì)算機(jī)軟件指計(jì)算機(jī)系統(tǒng)中的程序及其文檔。 程序是計(jì)算任務(wù)的處理對(duì)象和處理規(guī)那么的描述。任何以計(jì)算機(jī)為處理工具

2、的任務(wù)都是計(jì)算任務(wù)。處理對(duì)象是數(shù)據(jù)如數(shù)據(jù)、文字、圖形、圖象、聲音等，它們只是表示，而無含義或信息數(shù)據(jù)及有關(guān)的含義。處理規(guī)那么一般指處理的動(dòng)作和步驟。程序必須裝入計(jì)算機(jī)內(nèi)才能工作。文檔是為了便于了解程序所需的說明性資料，文檔一般是給人看的，不一定裝入計(jì)算機(jī)。5計(jì)算機(jī)軟件 軟件的特點(diǎn) 軟件的分類6軟件的特點(diǎn)軟件是一種邏輯實(shí)體，而不是具體的物理實(shí)體，其開發(fā)本錢和進(jìn)度難以估計(jì)軟件的開發(fā)過程中沒有明顯的制造過程，一旦軟件開發(fā)成功后，只須復(fù)制即可，但維護(hù)工作量大軟件的運(yùn)行和使用沒有硬件那樣的機(jī)械磨損，老化問題標(biāo)準(zhǔn)定義1 能夠完成預(yù)定功能和性能的可執(zhí)行指令；2 使得程序能夠適當(dāng)?shù)夭僮餍畔⒌臄?shù)據(jù)結(jié)構(gòu)；3 描述

3、程序的操作和使用的文檔。7各位大佬的定義Fritz Bauer曾在NATO會(huì)議上給出軟件工程的定義：軟件工程 是為了經(jīng)濟(jì)地獲得能夠在實(shí)際機(jī)器上高效運(yùn)行的可靠軟件而建立和使用的一系列好的工程化原那么。1983年，IEEEInstitute of Electrical & Electronic Engineers，電氣與電子工程師協(xié)會(huì)給出了一個(gè)更為全面的定義：軟件工程 是研究和應(yīng)用如何以系統(tǒng)化的、標(biāo)準(zhǔn)的、可度量的方法去開發(fā)、運(yùn)行和維護(hù)軟件，即把工程化應(yīng)用到軟件上。8軟件工程的層次化軟件工程是一種層次化的技術(shù)9 軟件工程的層次1 軟件工程必須以有組織的質(zhì)量保證為根底，全面質(zhì)量管理和過程改進(jìn)使得更加成

4、熟的軟件工程方法的不斷出現(xiàn)。2 軟件工程過程是進(jìn)行一系列有組織的活動(dòng)，從而能夠合理地和及時(shí)地開發(fā)出計(jì)算機(jī)軟件。過程定義了技術(shù)方法的采用、工程產(chǎn)品包括模型、文檔、數(shù)據(jù)、報(bào)告、表格等的產(chǎn)生、里程碑的建立、質(zhì)量的保證和變更的管理。3 軟件工程方法為軟件開發(fā)提供如何做的技術(shù)，它涵蓋了工程方案、需求分析、系統(tǒng)設(shè)計(jì)、程序?qū)崿F(xiàn)、測(cè)試與維護(hù)等一系列的任務(wù)。4 軟件工具為過程和方法提供自動(dòng)的或半自動(dòng)的支持。這些軟件工具被集成起來，建立起一個(gè)支持軟件開發(fā)的系統(tǒng)，稱之為計(jì)算機(jī)輔助軟件工程CASE，Computer Aided Software Engineering。CASE集成了軟件、硬件和一個(gè)存放開發(fā)過程信息的

5、軟件工程數(shù)據(jù)庫(kù)，形成了一個(gè)軟件工程環(huán)境。10軟件和硬件的比照與硬件相比，軟件具有以下不同的特點(diǎn)：1 軟件是邏輯的，而不是物理的產(chǎn)品。邏輯往往實(shí)際只存在于人的頭腦當(dāng)中，軟件人員好比“皇帝的新衣故事中的裁縫，軟件的開發(fā)過程極難加以控制。2 軟件是由開發(fā)或工程化而形成的，沒有明顯的制造過程。軟件本錢集中于“開上，意味著軟件工程不能象硬件制造工程那樣來管理。3軟件在運(yùn)行和使用期間，不存在硬件那樣的磨損和老化問題，但它存在退化問題，開發(fā)人員必須維護(hù)軟件。 4 大多數(shù)軟件是自定的，而不是通過已有構(gòu)件組裝而成的。迄今為止，軟件的開發(fā)尚未完全擺脫手工的方式。5 軟件本錢相當(dāng)昂貴。 6 軟件本身是復(fù)雜的。111

6、2軟件的特點(diǎn)軟件的開發(fā)和運(yùn)行常受到計(jì)算機(jī)硬件的限制，對(duì)計(jì)算機(jī)硬件有著不同程度的依賴性軟件的開發(fā)至今尚未完全實(shí)現(xiàn)自動(dòng)化軟件本錢相當(dāng)昂貴相當(dāng)多的軟件工作涉及到社會(huì)因素13軟件的分類系統(tǒng)軟件：屬于計(jì)算機(jī)系統(tǒng)中最靠近硬件的一層，其它軟件一般都通過系統(tǒng)軟件發(fā)揮作用，它與具體的應(yīng)用領(lǐng)域無關(guān)。如操作系統(tǒng)、編譯程序等。支持軟件：支持軟件的開發(fā)和維護(hù)的軟件。如數(shù)據(jù)庫(kù)管理系統(tǒng)、網(wǎng)絡(luò)軟件、軟件開發(fā)環(huán)境等。應(yīng)用軟件：特定應(yīng)用領(lǐng)域?qū)Ｓ玫能浖Ｈ鐚?shí)時(shí)軟件、嵌入式軟件、科學(xué)和工程計(jì)算軟件、事務(wù)處理軟件、人工智能軟件等。按軟件功能進(jìn)行劃分：14 按軟件規(guī)模進(jìn)行劃分：類別 參加人員數(shù) 研制期限 源程序行數(shù) 微型 1 14周 0

7、.5k 小型 1 16月 1k2k中型 25 12年 5k50k大型 520 23年 50k100k甚大型 1001000 45年 1M(=1000k)極大型 20005000 510年 1M10M15 按軟件工作方式劃分： 實(shí)時(shí)處理軟件 分時(shí)軟件 交互式軟件 批處理軟件 按軟件效勞對(duì)象的范圍劃分： 工程軟件 產(chǎn)品軟件 軟件的分類軟件的開展16軟件工程的目標(biāo)軟件工程旨在開發(fā)滿足用戶需要、及時(shí)交付、不超過預(yù)算和無故障的軟件，其主要目標(biāo)如下：1 合理預(yù)算開發(fā)本錢，付出較低的開發(fā)費(fèi)用；2 實(shí)現(xiàn)預(yù)期的軟件功能，到達(dá)較好的軟件性能，滿足用戶的需求；3 提高所開發(fā)軟件的可維護(hù)性，降低維護(hù)費(fèi)用；4 提高軟件

8、開發(fā)生產(chǎn)率，及時(shí)交付使用。17軟件危機(jī)軟件危機(jī)爆發(fā)于20世紀(jì)60年代末期，雖然人們一直致力于發(fā)現(xiàn)解決危機(jī)的方法，但是軟件危機(jī)至今依然困繞著我們，并沒有一種靈丹妙藥可以完全治愈這種病痛。18軟件危機(jī)21 軟件開發(fā)的進(jìn)度難以控制，經(jīng)常出現(xiàn)經(jīng)費(fèi)超預(yù)算、完成期限一再拖延的現(xiàn)象。1979年，美國(guó)US Government Accounting Office對(duì)政府工程進(jìn)行了調(diào)查，其中9個(gè)軟件工程的結(jié)果如下：19軟件危機(jī)32 軟件需求在開發(fā)初期不明確，導(dǎo)致矛盾在后期集中暴露，從而對(duì)整個(gè)開發(fā)過程帶來災(zāi)難性的后果。3 由于缺乏完整標(biāo)準(zhǔn)的資料，加之軟件測(cè)試不充分，從而造成軟件質(zhì)量低下，運(yùn)行中出現(xiàn)大量問題。20軟件

9、危機(jī)4由于認(rèn)識(shí)到軟件的設(shè)計(jì)、實(shí)現(xiàn)、維護(hù)和傳統(tǒng)的工程規(guī)那么有相同的根底，于是北大西洋公約組織NATO于1967年首次提出了軟件工程Software Engineering的概念。關(guān)于編制軟件與其他工程任務(wù)類似的提法，得到了1968年在德國(guó)召開的NATO軟件工程會(huì)議的認(rèn)可。委員會(huì)的結(jié)論是，軟件工程應(yīng)使用已有的工程規(guī)那么的理論和模式，來解決所謂的軟件危機(jī)。軟件危機(jī)至今仍然困繞著我們，這說明軟件生產(chǎn)過程在許多方面和傳統(tǒng)的工程相似，但卻具有獨(dú)特的屬性和問題。2122 計(jì)算機(jī)軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論23軟件生存周期 software life cycle軟件有一個(gè)孕育、誕生、成長(zhǎng)、成熟

10、、衰亡的生存過程。這個(gè)過程即為計(jì)算機(jī)軟件的生存周期軟件生存周期大體可分為如下幾個(gè)活動(dòng)：計(jì)算機(jī)系統(tǒng)工程、可行性分析、軟件工程方案、軟件需求分析、軟件設(shè)計(jì)、程序編碼、測(cè)試及運(yùn)行維護(hù)24計(jì)算機(jī)系統(tǒng)工程 計(jì)算機(jī)系統(tǒng)包括計(jì)算機(jī)硬件、軟件和使用計(jì)算機(jī)的人。計(jì)算機(jī)系統(tǒng)工程的任務(wù)是確定待開發(fā)軟件的總體要求和范圍，以及與之有關(guān)的硬件、支持軟件的要求?？尚行苑治?從經(jīng)濟(jì)、技術(shù)、法律等多個(gè)方面分析待開發(fā)的軟件是否有可行的解決方案，并在假設(shè)干個(gè)可行的解決方案中作出選擇。軟件生存周期 software life cycle25軟件工程方案 確定待開發(fā)軟件的目標(biāo)，并對(duì)資源分配、本錢估算、進(jìn)度安排等作出合理的方案。軟件需求

11、分析 確定待開發(fā)軟件的功能、性能、數(shù)據(jù)、界面等要求，即解決待開發(fā)軟件要“做什么的問題。軟件生存周期 software life cycle26軟件設(shè)計(jì) 主要解決待開發(fā)軟件“怎么做的問題。 軟件設(shè)計(jì)通?？煞譃橄到y(tǒng)設(shè)計(jì)也稱概要設(shè)計(jì)或總體設(shè)計(jì)和詳細(xì)設(shè)計(jì)。 系統(tǒng)設(shè)計(jì)的任務(wù)是設(shè)計(jì)軟件系統(tǒng)的結(jié)構(gòu)，包括軟件系統(tǒng)的組成成分、各成分的功能和接口、成分間的連接和通信，同時(shí)設(shè)計(jì)全局?jǐn)?shù)據(jù)結(jié)構(gòu)； 詳細(xì)設(shè)計(jì)的任務(wù)是設(shè)計(jì)各個(gè)組成成分的實(shí)現(xiàn)細(xì)節(jié)，包括局部數(shù)據(jù)結(jié)構(gòu)和算法等。軟件生存周期 software life cycle27編碼 用某種程序語(yǔ)言為軟件編寫程序。測(cè)試 發(fā)現(xiàn)并糾正軟件中的錯(cuò)誤和缺陷。運(yùn)行和維護(hù) 在軟件運(yùn)行期間，

12、當(dāng)發(fā)現(xiàn)了軟件中潛藏的錯(cuò)誤或需要增加新的功能或需將軟件移植到另一運(yùn)行平臺(tái)等情況出現(xiàn)時(shí)對(duì)軟件進(jìn)行修改。軟件生存周期 software life cycle28 計(jì)算機(jī)軟件 軟件生存周期 軟件開發(fā)模型軟件工程概論29軟件開發(fā)模型軟件開發(fā)模型是軟件開發(fā)全部過程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架也稱軟件過程模型或軟件生存周期模型軟件工程的主要環(huán)節(jié)3031軟件開發(fā)模型典型的軟件開發(fā)模型有：瀑布模型waterfall model演化模型evolutionary model增量模型incremental model螺旋模型spiral model噴泉模型water fountain model基于構(gòu)件的開發(fā)模型compo

13、nent-based development modelRUP開發(fā)模型敏捷過程模型最傻瓜的方法邊做邊改型。就是建立一個(gè)版本 用運(yùn)行狀態(tài)的評(píng)估來確定 修改到用戶滿意為止！相當(dāng)?shù)纳倒希?233瀑布模型可行性研究需求分析與規(guī)約設(shè)計(jì)與規(guī)約編碼與單元測(cè)試集成測(cè)試系統(tǒng)測(cè)試運(yùn)行與維護(hù)341970年提出瀑布模型特征接受上一階段的結(jié)果作為本階段的輸入利用這一輸入實(shí)施本階段應(yīng)完成的活動(dòng)對(duì)本階段的工作進(jìn)行評(píng)審將本階段的結(jié)果作為輸出，傳遞給下一階段缺點(diǎn)缺乏靈活性，難以適應(yīng)需求不明確或需求經(jīng)常變化的軟件開發(fā)開發(fā)早期存在的問題往往要到交付使用時(shí)才發(fā)現(xiàn)，維護(hù)代價(jià)大瀑布模型快速原型模型快速原型模型的第一步是建造一個(gè)快速原型，

14、實(shí)現(xiàn)客戶或未來的用戶與系統(tǒng)的交互，用戶或客戶對(duì)原型進(jìn)行評(píng)價(jià)，進(jìn)一步細(xì)化待開發(fā)軟件的需求。通過逐步調(diào)整原型使其滿足客戶的要求，開發(fā)人員可以確定客戶的真正需求是什么；第二步那么在第一步的根底上開發(fā)客戶滿意的軟件產(chǎn)品。顯然，快速原型方法可以克服瀑布模型的缺點(diǎn)，減少由于軟件需求不明確帶來的開發(fā)風(fēng)險(xiǎn)，具有顯著的效果。快速原型的關(guān)鍵在于盡可能快速地建造出軟件原型，一旦確定了客戶的真正需求，所建造的原型將被丟棄。因此，原型系統(tǒng)的內(nèi)部結(jié)構(gòu)并不重要，重要的是必須迅速建立原型，隨之迅速修改原型，以反映客戶的需求。 3536 軟件往往難以一次開發(fā)完成，我們可以在獲取了一組根本的需求后，通過快速分析，構(gòu)造出該軟件的一

15、個(gè)初始版本，稱為原型prototype，然后根據(jù)用戶在試用原型的過程中提出的反響意見和建議對(duì)原型進(jìn)行改進(jìn)，獲得原型的新版本，重復(fù)這一過程，最終可得到令用戶滿意的軟件產(chǎn)品。 演化模型采用迭代的思想，漸進(jìn)地開發(fā)，逐步完成軟件版本。 增量模型、螺旋模型都屬于演化模型演化模型37增量模型38增量模型將軟件的開發(fā)過程分成假設(shè)干個(gè)日程時(shí)間交錯(cuò)的線性序列，每個(gè)線性序列產(chǎn)生軟件的一個(gè)可發(fā)布的“增量版本，后一版本是對(duì)前一版本的修改和補(bǔ)充，重復(fù)增量發(fā)布的過程，直至產(chǎn)生最終的完善產(chǎn)品增量模型融合了瀑布模型的根本成分重復(fù)地應(yīng)用和演化模型的迭代特征增量模型強(qiáng)調(diào)每一個(gè)增量都發(fā)布一個(gè)可運(yùn)行的產(chǎn)品增量模型39增量模型特別適用

16、于：需求經(jīng)常變化的軟件開發(fā)市場(chǎng)急需，而開發(fā)人員和資金不能在設(shè)定的市場(chǎng)期限之前實(shí)現(xiàn)一個(gè)完善的產(chǎn)品的軟件開發(fā)增量模型能有方案地管理技術(shù)風(fēng)險(xiǎn)，如早期增量版本中防止采用尚未成熟的技術(shù)增量模型40于1988年提出是瀑布模型和演化模型的結(jié)合，并增加了風(fēng)險(xiǎn)分析螺旋模型沿著螺線旋轉(zhuǎn)，在四個(gè)象限上分別表達(dá)四個(gè)方面的活動(dòng)，即： 制定方案：確定軟件目標(biāo)，選定實(shí)施方案，弄清工程開發(fā)的限制條件 風(fēng)險(xiǎn)分析：分析所選方案，考慮如何識(shí)別和消除風(fēng)險(xiǎn) 工程實(shí)施：實(shí)施軟件開發(fā) 客戶評(píng)估：評(píng)價(jià)開發(fā)工作，提出修正建議螺旋模型41 42優(yōu)點(diǎn)：設(shè)計(jì)上的靈活性,可以在工程的各個(gè)階段進(jìn)行變更。 以小的分段來構(gòu)建大型系統(tǒng),使本錢計(jì)算變得簡(jiǎn)單容易

17、?？蛻羰冀K參與每個(gè)階段的開發(fā),保證了工程不偏離正確方向以及工程的可控性。隨著工程推進(jìn),客戶始終掌握工程的最新信息 , 從而他或她能夠和管理層有效地交互。缺點(diǎn)：采用螺旋模型需要具有相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí)，在風(fēng)險(xiǎn)較大的工程開發(fā)中，如果未能夠及時(shí)標(biāo)識(shí)風(fēng)險(xiǎn)，勢(shì)必造成重大損失。 過多的迭代次數(shù)會(huì)增加開發(fā)本錢，延遲提交時(shí)間。 螺旋模型43噴泉模型44噴泉模型是一種支持面向?qū)ο箝_發(fā)的模型，是一種以用戶需求為動(dòng)力，以對(duì)象為驅(qū)動(dòng)的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。該模型認(rèn)為軟件開發(fā)過程自下而上周期的各階段是相互重疊和屢次反復(fù)的，就像水噴上去又可以落下來，類似一個(gè)噴泉。各個(gè)開發(fā)階段沒有特定的次序

18、要求，并且可以交互進(jìn)行，可以在某個(gè)開發(fā)階段中隨時(shí)補(bǔ)充其他任何開發(fā)階段中的遺漏。 表達(dá)迭代和無間隙特征 迭代：各開發(fā)活動(dòng)常常重復(fù)工作屢次，相關(guān)的功能在每次迭代中隨之參加演進(jìn)的系統(tǒng) 無間隙：開發(fā)活動(dòng)之間不存在明顯的邊界噴泉模型45優(yōu)點(diǎn)：開發(fā)人員可以同步進(jìn)行開發(fā)，可以提高軟件工程開發(fā)效率，節(jié)省開發(fā)時(shí)間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。缺點(diǎn)：由于噴泉模型在各個(gè)開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于工程的管理。此外這種模型要求嚴(yán)格管理文檔，使得審核的難度加大，尤其是面對(duì)可能隨時(shí)參加各種信息、需求與資料的情況。 46支持軟件復(fù)用reuse利用預(yù)先包裝好的軟件構(gòu)件來構(gòu)造應(yīng)用系統(tǒng)基于構(gòu)

19、件的開發(fā)模型融合了螺旋模型的許多特征印度做的很好基于構(gòu)件的開發(fā)模型47軟件構(gòu)件是一個(gè)獨(dú)立發(fā)布的功能局部，可以通過其接口訪問它的效勞。它可以是被封裝的對(duì)象類、一些功能模塊、軟件框架framework、設(shè)計(jì)模式Pattern等。 基于構(gòu)件的開發(fā):開發(fā)者在設(shè)計(jì)和詳細(xì)描述階段，使用內(nèi)部開發(fā)的構(gòu)件和公開市場(chǎng)的構(gòu)件來為他們的應(yīng)用軟件提供盡可能多的功能。然后，開發(fā)者編寫其它的構(gòu)件來粘聯(lián)代碼，把構(gòu)件一一連接。他們可以把新寫的構(gòu)件放進(jìn)公司的知識(shí)庫(kù)，以至于其它人就可以使用這些構(gòu)件的功能。這種做法有效提高了軟件重用的效率并降低了開發(fā)本錢。基于構(gòu)件的開發(fā)模型優(yōu)點(diǎn)和缺點(diǎn)48模型優(yōu)點(diǎn)缺點(diǎn)瀑布模型文檔驅(qū)動(dòng)系統(tǒng)可能不滿足客戶

20、的需求快速原型模型關(guān)注滿足客戶需求可能導(dǎo)致系統(tǒng)設(shè)計(jì)差、效率低，難于維護(hù)增量模型開發(fā)早期反饋及時(shí)，易于維護(hù)需要開放式體系結(jié)構(gòu)，可能會(huì)設(shè)計(jì)差、效率低螺旋模型風(fēng)險(xiǎn)驅(qū)動(dòng)風(fēng)險(xiǎn)分析人員需要有經(jīng)驗(yàn)且經(jīng)過充分訓(xùn)練49 RUP模型50RUP模型 UML過程的根本特征是：用例驅(qū)動(dòng)，以架構(gòu)為核心，迭代并且增量用例驅(qū)動(dòng)： 用例獲取系統(tǒng)的功能需求，它們“驅(qū)動(dòng)需求分析之后的所有階段的開發(fā)。在分析階段，它們被用于獲取所需的功能并經(jīng)客戶確實(shí)認(rèn)。在設(shè)計(jì)和實(shí)現(xiàn)階段，用例必須被實(shí)現(xiàn)，在測(cè)試階段，用例用于驗(yàn)證系統(tǒng)。RUP模型RUPRational Unified Process，統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程)是一個(gè)面向?qū)ο笄一诰W(wǎng)

21、絡(luò)的程序開發(fā)方法論。根據(jù)Rational(Rational Rose和統(tǒng)一建模語(yǔ)言的開發(fā)者)的說法，好似一個(gè)在線的指導(dǎo)者，它可以為所有方面和層次的程序開發(fā)提供指導(dǎo)方針，模版以及事例支持。 RUP和類似的產(chǎn)品-例如面向?qū)ο蟮能浖^程OOSP，以及OPEN Process都是理解性的軟件工程工具-把開發(fā)中面向過程的方面例如定義的階段，技術(shù)和實(shí)踐和其他開發(fā)的組件例如文檔，模型，手冊(cè)以及代碼等 等整合在一個(gè)統(tǒng)一的框架內(nèi)。51AOPAOP，aspect objected programming,較好的說法是面向切面編程，按我的理解是，它能減少和系統(tǒng)的其他局部的耦合，是系統(tǒng)能更好的維護(hù)和重構(gòu)，叫他切面，就

22、是說他可以在需要 它的時(shí)候?qū)⑵鋮⒓拥较到y(tǒng)中，且能很好的和原系統(tǒng)配合，當(dāng)不需要的時(shí)候就可以去除，也不會(huì)重新修改代碼。在Spring開源框架中最重要的就是依賴注入和AOP了，利用它，可以讓程序員能更好的管理事務(wù)和業(yè)務(wù)bean,DAO bean,用它來做系統(tǒng)運(yùn)行日志，就是個(gè)例子。52形式化方法模型用于開發(fā)計(jì)算機(jī)系統(tǒng)的形式化方法是描述系統(tǒng)性質(zhì)的基于數(shù)學(xué)的技術(shù)，這樣的形式化方法提供了一個(gè)框架，可以在框架中以系統(tǒng)的而不是特別的方式刻劃、開發(fā)和驗(yàn) 證系統(tǒng)。 如果一個(gè)方法有良好的數(shù)學(xué)根底，那么它就是形式化的，典型地以形式化規(guī)約語(yǔ)言給出。這個(gè)根底提供一系列精確定義的概念，如：一致性和完整性，以及定義標(biāo)準(zhǔn) 的實(shí)現(xiàn)

23、和正確性。 形式化方法的本質(zhì)是基于數(shù)學(xué)的方法來描述目標(biāo)軟件系統(tǒng)屬性的一種技術(shù)。不同的形式化方法的數(shù)學(xué)根底是不同的，有的以集合論和一階謂詞演算為根底如Z和 VDM，有的那么以時(shí)態(tài)邏輯為根底。形式化方法需要形式化規(guī)約說明語(yǔ)言的支持53形式化方法的分類根據(jù)說明目標(biāo)軟件系統(tǒng)的方式，形式化方法可以分為兩類1面向模型的形式化方法。面向模型的方法通過構(gòu)造一個(gè)數(shù)學(xué)模型來說明系統(tǒng)的行為。 2面向?qū)傩缘男问交椒āＣ嫦驅(qū)傩缘姆椒ㄍㄟ^描述目標(biāo)軟件系統(tǒng)的各種屬性來間接定義系統(tǒng)行為。 54根據(jù)表達(dá)能力，形式化方法可以分為五類：1基于模型的方法：通過明確定義狀態(tài)和操作來建立一個(gè)系統(tǒng)模型使系統(tǒng)從一個(gè)狀態(tài)轉(zhuǎn)換到另一個(gè)狀態(tài)。用

24、這種方法雖可以表示非功能性需求諸如時(shí)間需求，但不能很好地表示并發(fā)性。如：Z語(yǔ)言，VDM，B方法等。 2基于邏輯的方法：用邏輯描述系統(tǒng)預(yù)期的性能，包括底層規(guī)約、時(shí)序和可能性行為。采用與所選邏輯相關(guān)的公理系統(tǒng)證明系統(tǒng)具有預(yù)期的性能。用具體的編程構(gòu) 造擴(kuò)充邏輯從而得到一種廣譜形式化方法，通過保持正確性的細(xì)化步驟集來開發(fā)系統(tǒng)。如：ITL區(qū)間時(shí)序邏輯，區(qū)段演算DC，hoare 邏輯，WP演算，模態(tài)邏輯，時(shí)序邏輯，TAM時(shí)序代理模型，RTTL實(shí)時(shí)時(shí)序邏輯等。 3代數(shù)方法：通過將未定義狀態(tài)下不同的操作行為相聯(lián)系，給出操作的顯式定義。與基于模型的方法相同的是，沒有給出并發(fā)的顯式表示。如：OBJ， Larch族

25、代數(shù)規(guī)約語(yǔ)言等； 4過程代數(shù)方法：通過限制所有容許的可觀察的過程間通信來表示系統(tǒng)行為。此類方法允許并發(fā)過程的顯式表示。如：通信順序過程CSP，通信系統(tǒng)演算 CCS，通信過程代數(shù)ACP，時(shí)序排序規(guī)約語(yǔ)言LOTOS，計(jì)時(shí)CSP(TCSP，通信系統(tǒng)計(jì)時(shí)可能性演算TPCCS等。 5基于網(wǎng)絡(luò)的方法：由于圖形化表示法易于理解，而且非專業(yè)人員能夠使用，因此是一種通用的系統(tǒng)確定表示法。該方法采用具有形式語(yǔ)義的圖形語(yǔ)言，為系統(tǒng)開發(fā)和再工程帶來特殊的好處。如 Petri圖，計(jì)時(shí)Petri圖，狀態(tài)圖等。達(dá)能力，形式化方法可以分為五類5556以體系結(jié)構(gòu)為中心： 首先定義一個(gè)根底的體系結(jié)構(gòu)，然后將它原型化并加以評(píng)估，最

26、后進(jìn)行精化。體系結(jié)構(gòu)給出系統(tǒng)的映象，它定義系統(tǒng)的不同局部、它們的關(guān)系和交互，它們的通信機(jī)制以及關(guān)于如何增加或修改體系結(jié)構(gòu)中的成分的全部規(guī)那么。體系結(jié)構(gòu)涉及到功能性和非功能性兩個(gè)方面，要定義一個(gè)易修改、易理解和允許復(fù)用的系統(tǒng)。57迭代： 用UML建模最好經(jīng)過假設(shè)干次較小的迭代，不要試圖一次就定義模型或圖的所有細(xì)節(jié)，開發(fā)是逐步進(jìn)行的，每次迭代增加一些新的信息和細(xì)節(jié)。每次迭代都要對(duì)前次的結(jié)果評(píng)價(jià)，并用于下一次迭代的輸入。迭代的過程提供連續(xù)的反響，這些反響不僅改善了最終的產(chǎn)品，而且改善了過程本身。 在決定每一次迭代應(yīng)做什么時(shí)，要考慮這次迭代對(duì)系統(tǒng)的最大影響或最高風(fēng)險(xiǎn)。考慮最大影響的迭代意味著使系統(tǒng)能盡

27、早提交給用戶，考慮最高風(fēng)險(xiǎn)的迭代意味著盡早處理工程中的難點(diǎn)，以降低工程的風(fēng)險(xiǎn)。 58增量 ：增量開發(fā)是在屢次迭代的過程中每次增加一些功能或用例的開發(fā)，每次迭代都包含分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試等階段，通過假設(shè)干次增量開發(fā)完成整個(gè)系統(tǒng)的開發(fā)，這樣的開發(fā)過程分解了開發(fā)的風(fēng)險(xiǎn)，不至于把風(fēng)險(xiǎn)留到開發(fā)的后期。每次迭代集中在幾個(gè)功能或用例的開發(fā)上，如發(fā)現(xiàn)問題，其錯(cuò)誤往往比較小，相應(yīng)的風(fēng)險(xiǎn)也小，修改也相對(duì)容易。 59敏捷聯(lián)盟：敏捷軟件開發(fā)宣言2001個(gè)體和交互勝過過程和工具；可工作軟件勝過寬泛的文檔；客戶合作勝過合同談判；響應(yīng)變化勝過遵循方案。敏捷建模60我們的最高目標(biāo)是，通過盡早和持續(xù)地交付有價(jià)值的軟件來滿足客

28、戶。 歡送對(duì)需求提出變更即使是在工程開發(fā)后期。要善于利用需求變更，幫助客戶獲得競(jìng)爭(zhēng)優(yōu)勢(shì)。 要不斷交付可用的軟件，周期從幾周到幾個(gè)月不等，且越短越好。 工程過程中，業(yè)務(wù)人員與開發(fā)人員必須在一起工作。 要善于鼓勵(lì)工程人員，給他們以所需要的環(huán)境和支持，并相信他們能夠完成任務(wù)。 無論是團(tuán)隊(duì)內(nèi)還是團(tuán)隊(duì)間，最有效的溝通方法是面對(duì)面的交談。 敏捷宣言背后的12條原那么61可用的軟件是衡量進(jìn)度的主要指標(biāo)。 敏捷過程提倡可持續(xù)的開發(fā)。工程方、開發(fā)人員和用戶應(yīng)該能夠保持恒久穩(wěn)定的進(jìn)展速度。 對(duì)技術(shù)的精益求精以及對(duì)設(shè)計(jì)的不斷完善將提升敏捷性。 要做到簡(jiǎn)潔，即盡最大可能減少不必要的工作。這是一門藝術(shù)。 最正確的架構(gòu)、

29、需求和設(shè)計(jì)出自于自組織的團(tuán)隊(duì)。 團(tuán)隊(duì)要定期反省如何能夠做到更有效，并相應(yīng)地調(diào)整團(tuán)隊(duì)的行為。 敏捷宣言背后的12條原那么62極限編程Extreme Programming，XP( P57圖4-1，生命周期：籌劃、設(shè)計(jì)、編碼、測(cè)試。XP原那么：現(xiàn)場(chǎng)客戶、簡(jiǎn)單設(shè)計(jì)、測(cè)試驅(qū)動(dòng)、結(jié)對(duì)編程、代碼全體擁有、持續(xù)集成、小型發(fā)布自適應(yīng)軟件開發(fā)Adaptive Software Development,ASD)(P61,圖4-2，生命周期：思考、協(xié)作、學(xué)習(xí)動(dòng)態(tài)系統(tǒng)開發(fā)方法Dynamic SystemDevelopment Method，DSDM敏捷過程模型63動(dòng)態(tài)系統(tǒng)開發(fā)方法Dynamic SystemDevel

30、opment Method，DSDM：使用迭代軟件過程，每一個(gè)迭代都遵循80%原那么如果交付整個(gè)系統(tǒng)需用100%時(shí)間，那么80%的應(yīng)用系統(tǒng)可以用20%的時(shí)間交付。DSDM生命周期的敏捷過程模型：可行性研究業(yè)務(wù)研究功能模型迭代設(shè)計(jì)和構(gòu)建迭代實(shí)現(xiàn)敏捷過程模型64Scrum敏捷過程模型P63圖4-3原那么(和敏捷宣言一致：組織小型團(tuán)隊(duì)以到達(dá)：溝通最大化，負(fù)擔(dān)最小化，非語(yǔ)言描述、非形式化知識(shí)。過程對(duì)技術(shù)和業(yè)務(wù)變化必須具有適應(yīng)性，以“保證制造具有最好可能的產(chǎn)品。過程生產(chǎn)頻繁發(fā)布“可檢查、可調(diào)整、可測(cè)試、可文檔化、可構(gòu)建的軟件增量。開發(fā)工作和開發(fā)人員劃分為“清晰的、低耦合的局部或包。堅(jiān)持在產(chǎn)品構(gòu)建過程中進(jìn)

31、行測(cè)試和文檔化。Scrum過程提供“在任何需要的情況下都能完成產(chǎn)品的能力。敏捷過程模型65特征驅(qū)動(dòng)開發(fā)Feature Drive Developmeng,FDDP65圖4-4特征-是可以在2周或者更短時(shí)間實(shí)現(xiàn)的具有客戶價(jià)值的功能。FDD更加強(qiáng)調(diào)工程管理原那么和技術(shù)。在特征設(shè)計(jì)和構(gòu)建階段定義6個(gè)里程碑：設(shè)計(jì)走查，設(shè)計(jì)，設(shè)計(jì)檢查，編碼，代碼檢查，促進(jìn)構(gòu)建敏捷過程模型軟件神話什么都是浮云不要用機(jī)械工程的概念來套用6667觀點(diǎn)之一我們擁有一套講述如何開發(fā)軟件的書籍，書中充滿了標(biāo)準(zhǔn)與示例，可以幫助我們解決軟件開發(fā)中遇到的任何問題。 客觀事實(shí)好的參考書無疑能指導(dǎo)我們的工作，充分利用書籍中的方法、技術(shù)和技巧

32、，可以有效地解決軟件開發(fā)中大量常見的問題。但實(shí)踐者并不能依賴于書籍，因?yàn)樵诂F(xiàn)實(shí)工作中，由于條件千差萬別，即使是相當(dāng)成熟的軟件工程規(guī)范，常常也無法套用。另外，軟件技術(shù)日新月異，沒有哪一種軟件標(biāo)準(zhǔn)能長(zhǎng)盛不衰。觀點(diǎn)之二如果我們已經(jīng)落后于計(jì)劃，可以增加更多的程序員來趕上進(jìn)度?？陀^事實(shí)軟件開發(fā)不同于傳統(tǒng)的機(jī)械制造，人多不見得力量大。如果給落后于計(jì)劃的項(xiàng)目增添新人，可能會(huì)更加延誤項(xiàng)目。因?yàn)樾氯藭?huì)產(chǎn)生很多新的錯(cuò)誤，使項(xiàng)目混亂，并且原有的開發(fā)人員向新人解釋工作和交流思想都要花費(fèi)時(shí)間，使實(shí)際的開發(fā)時(shí)間更少，所以制定恰如其分的項(xiàng)目計(jì)劃是很重要的。【講解】假設(shè)一個(gè)項(xiàng)目估計(jì)需要12人月工作量，指定由3個(gè)人在4個(gè)月內(nèi)完

33、成，如果第一個(gè)月的任務(wù)花了兩個(gè)月才完成，那么增加人力的結(jié)果如何？假設(shè)增加2個(gè)人參加項(xiàng)目，不論新增加的人適應(yīng)能力有多強(qiáng)，總需要有人去幫助了解熟悉情況，如果這些工作占用了一個(gè)月的時(shí)間，這樣又有3個(gè)人月工作量在新計(jì)劃之外。由于人員增加，工作任務(wù)需要重新劃分，到第3個(gè)月結(jié)束時(shí)雖然有5個(gè)人在工作，實(shí)際上余留下7個(gè)人的工作量。觀點(diǎn)之三項(xiàng)目需求總是在不斷變化，但這些變化能夠很容易地滿足，因?yàn)檐浖庆`活的。客觀事實(shí)軟件需求確實(shí)是經(jīng)常變化的，但這些變化產(chǎn)生的影響會(huì)隨著其引入時(shí)間的不同而不同。對(duì)需求把握得越準(zhǔn)確，軟件的修修補(bǔ)補(bǔ)就越少。有些需求在一開始時(shí)很難確定，在開發(fā)過程中要不斷地加以改正。軟件修改越早代價(jià)越少，

34、修改越晚代價(jià)越大，就跟治病一樣道理。 觀點(diǎn)之四有了對(duì)目標(biāo)的一般描述就足以開始寫程序了，我們以后可以再補(bǔ)充細(xì)節(jié)?？陀^事實(shí)不完善的系統(tǒng)定義是軟件項(xiàng)目失敗的主要原因。關(guān)于待開發(fā)軟件的應(yīng)用領(lǐng)域、功能、性能、接口、設(shè)計(jì)約束和標(biāo)準(zhǔn)等需要詳細(xì)的描述，而這些只有通過用戶和開發(fā)人員之間的通信交流才能確定。越早開始寫程序，就要花越長(zhǎng)時(shí)間才能完成它。觀點(diǎn)之五一旦我們寫出了程序并使其正常運(yùn)行，我們的工作就結(jié)束了。人們有時(shí)認(rèn)為，只有差的軟件產(chǎn)品才需要維護(hù)?？陀^事實(shí)從如圖1.12所示的統(tǒng)計(jì)數(shù)據(jù)來看，軟件投入的50%70%是花費(fèi)在交付給用戶之后。品質(zhì)差的產(chǎn)品被丟棄，只有好的產(chǎn)品才需要維護(hù)和改進(jìn)。觀點(diǎn)之六一個(gè)成功的項(xiàng)目唯一應(yīng)

35、該提交的就是運(yùn)行程序?？陀^事實(shí)軟件包括程序、數(shù)據(jù)和文檔，其中文檔是成功開發(fā)的基礎(chǔ)，為軟件維護(hù)提供了指導(dǎo)。 幫助回憶觀點(diǎn)一：開放軟件源代碼就一定好。 觀點(diǎn)二：軟件質(zhì)量問題可通過軟件測(cè)試得到徹底解決。68觀點(diǎn)一一般人都認(rèn)為開放源代碼對(duì)一個(gè)軟件系統(tǒng)的完善有很好的促進(jìn)作用，因?yàn)檫@樣可以集合很多人的智慧，但這種觀點(diǎn)并不完全正確。大家贊同開放源碼，其實(shí)很大程度上是因?yàn)橄扔辛薒inux成功的例子，而Linux的出現(xiàn)和成功是有它一定的背景的，很大程度上是因?yàn)椴恢С衷创a開放的代表-微軟的緣故。開放源代碼對(duì)促進(jìn)全球軟件和信息技術(shù)行業(yè)的快速開展是很有益處的，但是關(guān)于源代碼的GPL授權(quán)方式目前還看不到它對(duì)軟件企業(yè)開展的好處。一味強(qiáng)調(diào)過度開放源代碼，在現(xiàn)在盜版泛濫的時(shí)代，擁有源代碼的公司如何得到回報(bào)，沒有回報(bào)就沒有進(jìn)一步研發(fā)資金，軟件的開展從何而來。 69觀點(diǎn)二為了克服軟件危機(jī)和提高軟件質(zhì)量，人們進(jìn)行了大量的研究和實(shí)踐。最初的重點(diǎn)是著眼于技術(shù)革新，從各種軟件工具如編輯、編譯、調(diào)試工具等等研制開始，開展成為對(duì)開發(fā)各階段進(jìn)行全面支持的計(jì)算機(jī)輔助軟件工程CASE環(huán)境。同時(shí)，注重軟件開發(fā)模型研究，也就是如何劃分軟件開