軟件工程課件：第01章 軟件工程概述

1、第1章軟件工程概述1內(nèi)容1.0 軟件概念1.1 軟件危機(jī)1.2 軟件工程1.3 軟件生命周期1.4 軟件過(guò)程1.0 軟件概念軟件軟件的特點(diǎn)軟件發(fā)展歷程軟件概念-軟件 軟件（ Software）是計(jì)算機(jī)系統(tǒng)中與硬件相互依存的另一部分，它是包括程序（Program） ，數(shù)據(jù)（Data）及其相關(guān)文檔（ Document）的完整集合。 Software = Program + Data + Document程序是按事先設(shè)計(jì)的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程序能正常操縱信息的數(shù)據(jù)結(jié)構(gòu)文檔是與程序開(kāi)發(fā)，維護(hù)和使用有關(guān)的圖文材料軟件概念-軟件的特點(diǎn)抽象性軟件是邏輯實(shí)體，沒(méi)有明顯的制造過(guò)程，運(yùn)行和使用沒(méi)

2、有磨損與老化問(wèn)題。依存性軟件開(kāi)發(fā)和運(yùn)行依賴于計(jì)算機(jī)系統(tǒng)。工藝性軟件開(kāi)發(fā)至今尚未完全擺脫手工工藝的開(kāi)發(fā)方式。復(fù)雜性軟件邏輯結(jié)構(gòu)、開(kāi)發(fā)技術(shù)、項(xiàng)目管理復(fù)雜。成本高開(kāi)發(fā)成本、維護(hù)成本高。風(fēng)險(xiǎn)大軟件項(xiàng)目的成功率低。維護(hù)難維護(hù)不能依靠原開(kāi)發(fā)者，理解軟件代碼難，維護(hù)也是開(kāi)發(fā)，維護(hù)成本高軟件工作涉及各種社會(huì)因素政策規(guī)章、管理思想、文化背景、信息素養(yǎng)、技術(shù)水平、系統(tǒng)接口等。軟件的復(fù)雜性邏輯復(fù)雜軟件的邏輯結(jié)構(gòu)非常復(fù)雜開(kāi)發(fā)復(fù)雜成本難以估算、進(jìn)度難以控制、人員素質(zhì)要求、質(zhì)量得不到保證成本高例：軟件成本風(fēng)險(xiǎn)大1995年美國(guó)Standish咨詢集團(tuán)的統(tǒng)計(jì)分析(至90年代初的軟件項(xiàng)目執(zhí)行情況)成功：16.2%失?。?1受到

3、挑戰(zhàn)：53.8%近幾年來(lái)的統(tǒng)計(jì)數(shù)據(jù)成功：26失?。?8受到挑戰(zhàn)：46%維護(hù)難維護(hù)形式多樣化改正性：修改故障完善性：增加功能適應(yīng)性：移植維護(hù)成本越來(lái)越高55%到70維護(hù)帶來(lái)的問(wèn)題可能引發(fā)新的錯(cuò)誤，經(jīng)維護(hù)后邏輯結(jié)構(gòu)更復(fù)雜1.1 軟件危機(jī)軟件危機(jī)軟件發(fā)展歷程，軟件危機(jī)，軟件危機(jī)的表現(xiàn)。產(chǎn)生軟件危機(jī)的原因軟件特點(diǎn)有關(guān)，開(kāi)發(fā)中的問(wèn)題，維護(hù)中的問(wèn)題。消除軟件危機(jī)的途徑正確認(rèn)識(shí)“軟件”，重視軟件過(guò)程，采用有效的軟件開(kāi)發(fā)技術(shù)和方法，引進(jìn)工程管理方法。軟件發(fā)展歷程早期面向批處理有限的分布自定義軟件第二階段多用戶實(shí)時(shí)數(shù)據(jù)庫(kù)軟件產(chǎn)品第三階段分布式系統(tǒng)嵌入“智能”低成本硬件消費(fèi)者的影響第四階段強(qiáng)大的桌面系統(tǒng)面向?qū)ο蠹?/p>

4、術(shù)專家系統(tǒng)人工神經(jīng)網(wǎng)絡(luò)并行計(jì)算網(wǎng)路計(jì)算機(jī)195019601970198019902000 1968年10月，北大西洋公約組織（NATO）的科學(xué)家在德國(guó)召開(kāi)的學(xué)術(shù)會(huì)議上正式提出了軟件危機(jī)問(wèn)題。軟件危機(jī)軟件危機(jī)是計(jì)算機(jī)軟件開(kāi)發(fā)和維護(hù)過(guò)程中所遇到的一系列嚴(yán)重問(wèn)題。主要包括下列兩個(gè)方面的問(wèn)題：如何開(kāi)發(fā)軟件，以滿足對(duì)軟件的日益增長(zhǎng)的需求；如何維護(hù)不斷增多的已有軟件。軟件危機(jī)的典型表現(xiàn)對(duì)軟件開(kāi)發(fā)成本和進(jìn)度的估計(jì)常常很不準(zhǔn)確；用戶對(duì)交付的軟件經(jīng)常不滿意；軟件產(chǎn)品的質(zhì)量往往達(dá)不到要求；開(kāi)發(fā)出來(lái)的軟件通常難以維護(hù)；軟件產(chǎn)品文檔資料不適用和不完善；軟件成本在整個(gè)系統(tǒng)總成本中所占比例逐年上升；軟件開(kāi)發(fā)生產(chǎn)率的提高不

5、能滿足對(duì)軟件需求的增長(zhǎng)；成本問(wèn)題計(jì)算機(jī)軟件和硬件費(fèi)用比越來(lái)越大IBM 360 OS, 5000多人年，耗時(shí)4年(19631966)，花費(fèi)2億多美元美國(guó)空軍：1955年軟件占總費(fèi)用(計(jì)算機(jī)系統(tǒng))的18%，70年60%，85年達(dá)到85美國(guó)全球軍事指揮控制系統(tǒng)，硬件1億美元，軟件高達(dá)7.2億美元軟件質(zhì)量問(wèn)題軟件應(yīng)用面的擴(kuò)大：科學(xué)計(jì)算、軍事、航空航天、工業(yè)控制、企業(yè)管理、辦公、家庭軟件越來(lái)越多的應(yīng)用于安全攸關(guān)的系統(tǒng)，對(duì)軟件質(zhì)量提出更高的要求80年代歐洲亞麗安娜火箭的發(fā)射失敗，原因是軟件錯(cuò)誤美國(guó)阿托拉斯火箭的發(fā)射失敗，原因是軟件故障軟件的復(fù)雜性越來(lái)越高英國(guó)1986年開(kāi)發(fā)的辦公室信息系統(tǒng)Folios經(jīng)4年

6、，因性能達(dá)不到要求，1989年取消日本第5代機(jī)因?yàn)檐浖?wèn)題在投入50億美元后于1993年下馬由于軟件質(zhì)量問(wèn)題導(dǎo)致失敗的軟件項(xiàng)目非常多項(xiàng)目進(jìn)度問(wèn)題項(xiàng)目進(jìn)度難以控制項(xiàng)目延期比比皆是由于進(jìn)度問(wèn)題而取消的軟件項(xiàng)目較常見(jiàn)只有一小部分的項(xiàng)目能夠按期完成軟件維護(hù)問(wèn)題軟件維護(hù)非常困難軟件維護(hù)的多樣性軟件維護(hù)的復(fù)雜性軟件維護(hù)的副作用產(chǎn)生軟件危機(jī)的原因與軟件本身的特點(diǎn)有關(guān)成本高、風(fēng)險(xiǎn)大、難于維護(hù)、邏輯復(fù)雜。軟件是計(jì)算機(jī)系統(tǒng)中的邏輯實(shí)體而不是物理實(shí)體，軟件生產(chǎn)與硬件不同，在它的開(kāi)發(fā)過(guò)程中沒(méi)有明顯的制造過(guò)程。軟件是通過(guò)人們的智力活動(dòng)，把知識(shí)與技術(shù)轉(zhuǎn)化成信息的一種產(chǎn)品。在軟件的運(yùn)行過(guò)程中，沒(méi)有“用壞”的問(wèn)題。軟件維護(hù)意

7、味著修正原來(lái)的設(shè)計(jì)，較為困難。與軟件開(kāi)發(fā)與維護(hù)的方法不正確有關(guān)軟件專業(yè)人員對(duì)軟件開(kāi)發(fā)和維護(hù)存在糊涂觀念，在實(shí)踐過(guò)程中采用了錯(cuò)誤的方法和技術(shù)。如忽視軟件需求分析的重要性；輕視軟件維護(hù)。消除軟件危機(jī)的途徑正確認(rèn)識(shí)“軟件”軟件程序，軟件是相關(guān)程序、數(shù)據(jù)及文檔的集合。正確認(rèn)識(shí)“軟件開(kāi)發(fā)”軟件開(kāi)發(fā)不是個(gè)體勞動(dòng)，而主要是一種有組織的團(tuán)隊(duì)活動(dòng)。研究軟件開(kāi)發(fā)的技術(shù)手段在軟件開(kāi)發(fā)中使用已證明行之有效的技術(shù)，研究和探索新的技術(shù)。更好地使用軟件工具，建立一個(gè)良好的軟件工程支撐環(huán)境。研究軟件開(kāi)發(fā)的管理方法在軟件開(kāi)發(fā)中使用已證明行之有效的工程管理方法。組織良好、管理嚴(yán)密，使各類人員協(xié)同配合，共同完成軟件開(kāi)發(fā)的工程項(xiàng)目。

8、軟件工程學(xué)的是由于“軟件危機(jī)”的出現(xiàn)和加重而產(chǎn)生的，研究用工程的方法來(lái)管理軟件的開(kāi)發(fā)。開(kāi)發(fā)一個(gè)具有一定規(guī)模和復(fù)雜性的軟件系統(tǒng)與編寫一個(gè)簡(jiǎn)單的程序不一樣。大型、復(fù)雜軟件系統(tǒng)的開(kāi)發(fā)是一項(xiàng)工程，必須按照工程化的方法組織軟件的生產(chǎn)和管理，必須經(jīng)過(guò)分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試、維護(hù)等一系列軟件過(guò)程和活動(dòng)軟件工程學(xué)的產(chǎn)生提出有效的方法和工具支持軟件開(kāi)發(fā)1968年提出軟件工程概念和思想20世紀(jì)70年代的結(jié)構(gòu)化軟件開(kāi)發(fā)方法20世紀(jì)80年代的面向?qū)ο蟮能浖_(kāi)發(fā)方法新的技術(shù): 軟件重用、快速原型、需求工程典型技術(shù): COM, Java, C+, J2EE, .Net, .支撐工具和環(huán)境：Jbuilder, Visual

9、 Studio, WebLogic, 解決危機(jī)的技術(shù)途徑20世紀(jì)80年代末，美國(guó)DoD和業(yè)界開(kāi)始認(rèn)識(shí)到管理的重要性美國(guó)DoD的一項(xiàng)研究表明，70%的項(xiàng)目由于管理不善導(dǎo)致難以控制進(jìn)步、成本和質(zhì)量；進(jìn)一步的研究發(fā)現(xiàn)：管理是影響軟件項(xiàng)目成功開(kāi)發(fā)的全局性因素，而技術(shù)只影響局部如果軟件開(kāi)發(fā)組織不能對(duì)軟件項(xiàng)目進(jìn)行有效管理，就不能充分發(fā)揮軟件開(kāi)發(fā)方法和工具的潛力，也就不能高效率地開(kāi)發(fā)出高質(zhì)量的軟件產(chǎn)品解決危機(jī)的管理途徑1.2 軟件工程軟件工程的概念軟件工程的基本原理軟件工程方法學(xué)軟件工程概念軟件工程是指導(dǎo)計(jì)算機(jī)軟件開(kāi)發(fā)與維護(hù)的一門工程學(xué)科。采用工程的概念、原理、方法和技術(shù)來(lái)開(kāi)發(fā)和維護(hù)軟件。將經(jīng)過(guò)時(shí)間和實(shí)踐考

10、驗(yàn)而證明正確的管理方法和最好的技術(shù)手段結(jié)合起來(lái)，經(jīng)濟(jì)有效地開(kāi)發(fā)和維護(hù)軟件。軟件工程是一門不斷發(fā)展的學(xué)科。軟件工程定義(Fritz Bauer,1968) The establishment and use of sound engineering principles (methods) in order to obtain economically software that is reliable and works on real machines. (1968- Fritz Bauer) 軟件工程就是建立和使用一套合理的工程原理，從而經(jīng)濟(jì)地獲得可靠的、可以在實(shí)際機(jī)器上高效運(yùn)行的軟件。軟

11、件工程定義(IEEE,1990) Software engineering. (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1). (IEEE(The Institute for Electrical an

12、d Electronic engineers) Std 610-1990.） 軟件工程是：（1）把系統(tǒng)的、規(guī)范的、 可度量的途徑應(yīng)用于軟件開(kāi)發(fā)、運(yùn)行和維護(hù)過(guò)程，也就是把工程應(yīng)用于軟件；（2）研究（1）中提到的途徑。軟件工程定義(CMU/SEI,1990) Engineering is the systematic application of scientific knowledge in creating and building cost-effective solutions to practical problems in the service of mankind. Softwar

13、e engineering is that form of engineering that applies the principles of computer science and mathematics to achieving cost-effective solutions to software problems.SEI software engineering definition from 1990 SEI Report on Undergraduate Software Engineering Education (CMU/SEI-90-TR-003):軟件工程定義 軟件工

14、程是應(yīng)用計(jì)算機(jī)科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開(kāi)發(fā)軟件的工程。它采用經(jīng)過(guò)實(shí)踐驗(yàn)證的工程的原則、方法，以提高質(zhì)量，降低成本為目的。軟件工程的本質(zhì)特性關(guān)注于大型程序的構(gòu)造控制軟件復(fù)雜性適應(yīng)軟件的經(jīng)常變化性提高軟件開(kāi)發(fā)的效率和諧合作開(kāi)發(fā)軟件使軟件有效地支持它的用戶需求軟件是有一種文化背景的人為另一種文化背景的人開(kāi)發(fā)的產(chǎn)品。軟件工程的基本原理用分階段的生命周期計(jì)劃嚴(yán)格管理堅(jiān)持進(jìn)行階段評(píng)審實(shí)行嚴(yán)格的產(chǎn)品控制采用現(xiàn)代程序設(shè)計(jì)技術(shù)結(jié)果應(yīng)能清楚地審查開(kāi)發(fā)小組的人員應(yīng)該少而精承認(rèn)不斷改進(jìn)軟件工程實(shí)踐的必要性軟件工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與管理緊密結(jié)合所形成的工程學(xué)科。通常把在軟件生命周期全過(guò)程中使用的一整

15、套技術(shù)方法的集合稱為軟件工程方法學(xué)(methodology)，也稱為范型(paradigm)。軟件工程方法學(xué)軟件工程方法學(xué)三要素軟件工程方法學(xué)包含3個(gè)要素：方法、工具和過(guò)程。方法完成軟件開(kāi)發(fā)各項(xiàng)任務(wù)的技術(shù)方法。工具為運(yùn)用方法而提供的軟件工程支撐環(huán)境（支撐分析、設(shè)計(jì)、開(kāi)發(fā)等）。過(guò)程規(guī)定了完成軟件開(kāi)發(fā)各項(xiàng)任務(wù)的工作步驟。傳統(tǒng)軟件工程方法學(xué)傳統(tǒng)軟件工程方法學(xué)是生命周期方法學(xué)軟件生命周期一個(gè)軟件定義、開(kāi)發(fā)、使用和維護(hù)，直到最終被廢棄，要經(jīng)歷的漫長(zhǎng)的時(shí)期，稱為軟件的生命周期。生命周期方法學(xué)這種方法學(xué)把軟件生命周期的全過(guò)程依次劃分為若干個(gè)階段，然后順序地完成每個(gè)階段的任務(wù)。2 面向?qū)ο蠓椒▽W(xué)面向?qū)ο笾饕?/p>

16、念對(duì)象、類、繼承、消息等。面向?qū)ο蠓椒▽W(xué)這種方法學(xué)把數(shù)據(jù)和行為看成同等重要，它是一種以數(shù)據(jù)為主線，把數(shù)據(jù)和對(duì)數(shù)據(jù)的操作緊密結(jié)合起來(lái)的方法1.3 軟件生命周期軟件生命周期概念軟件生命周期模型軟件生命周期各階段任務(wù)常見(jiàn)的軟件工程方法學(xué)（幾大公司）軟件生命周期概念軟件生命周期基本階段軟件生命周期由軟件定義、軟件開(kāi)發(fā)和軟件維護(hù)三個(gè)時(shí)期組成，每個(gè)時(shí)期又可劃分若干個(gè)階段。生命周期方法學(xué)軟件工程采用的生命周期方法學(xué)就是從時(shí)間角度對(duì)軟件開(kāi)發(fā)和維護(hù)的復(fù)雜性進(jìn)行分解，把軟件生存的漫長(zhǎng)周期依次劃分為若干個(gè)階段，每個(gè)階段都有獨(dú)立的任務(wù)，然后逐步完成每個(gè)階段的任務(wù)。 劃分軟件生存周期階段的基本原則使各階段的任務(wù)之間盡可

17、能相互獨(dú)立，同一個(gè)階段各項(xiàng)任務(wù)的性質(zhì)盡可能相同，從而降低每個(gè)階段任務(wù)的復(fù)雜程序，簡(jiǎn)化不同階段之間的聯(lián)系，有利于軟件開(kāi)發(fā)工程的組織管理。1.4 軟件生命周期模型 問(wèn)題定義 軟件定義 可行性研究 需求分析 總體設(shè)計(jì)軟件生命周期 軟件開(kāi)發(fā) 詳細(xì)設(shè)計(jì) 編碼和單元測(cè)試（實(shí)現(xiàn)） 綜合測(cè)試 運(yùn)行維護(hù) 軟件維護(hù)軟件生命周期基本階段的任務(wù)（1）軟件定義時(shí)期總目標(biāo)的確定，可行性，采用策略，系統(tǒng)功能，所需資源與成本，工程進(jìn)度表，也稱為系統(tǒng)分析時(shí)期，分為所定義，可行性研究和需求分析。（2）開(kāi)發(fā)時(shí)期具體設(shè)計(jì)和實(shí)現(xiàn)前面所定義的軟件。分為：總體設(shè)計(jì)，詳細(xì)設(shè)計(jì)，編碼和單元測(cè)試，綜合測(cè)試。（3）維護(hù)時(shí)期使軟件盡量地滿足用戶需要

18、，糾錯(cuò)，適應(yīng)新環(huán)境，滿足新需求 軟件生命周期的階段1. 問(wèn)題定義要解決的問(wèn)題是什么？2. 可行性研究問(wèn)題能夠解決嗎？3. 需求分析為了解決問(wèn)題需要做什么？4. 總體設(shè)計(jì)為了解決問(wèn)題，大概怎樣做？5. 詳細(xì)設(shè)計(jì)為了解決問(wèn)題，具體怎樣做？6. 編碼和單元測(cè)試編程實(shí)現(xiàn)，并測(cè)試每一個(gè)程序模塊，驗(yàn)證程序達(dá)到設(shè)計(jì)要求。7. 綜合測(cè)試集成測(cè)試、壓力測(cè)試、驗(yàn)收測(cè)試，驗(yàn)證系統(tǒng)滿足需求。8. 軟件維護(hù)改正性維護(hù)、適應(yīng)性維護(hù)、完善性維護(hù)、預(yù)防性維護(hù)，保障系統(tǒng)持久性滿足用戶的要求。問(wèn)題定義可行性研究需求分析總體設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼與單元測(cè)試綜合測(cè)試軟件維護(hù)要解決的問(wèn)題是什么？問(wèn)題性質(zhì)、工程目標(biāo)和規(guī)模的報(bào)告分析員：實(shí)際用戶

19、+負(fù)責(zé)人是否有解決辦法？分析員 高層邏輯模型，準(zhǔn)確和具體的工程規(guī)模和目標(biāo)，成本/效益分析等可行性報(bào)告為了解決的問(wèn)題，目標(biāo)系統(tǒng)必須做什么？準(zhǔn)確確定系統(tǒng)的功能系統(tǒng)的邏輯模型（數(shù)據(jù)流圖+數(shù)據(jù)字典+簡(jiǎn)要算法）如何解決這些問(wèn)題模塊劃分軟件結(jié)構(gòu)如何具體地實(shí)現(xiàn)系統(tǒng)：每個(gè)模塊的流程圖（程序的詳細(xì)規(guī)格說(shuō)明）通過(guò)各種類型的測(cè)試，使軟件達(dá)到預(yù)定的要求寫出正確的容易理解和容易維護(hù)的程序模塊 通過(guò)各種必要的維護(hù)活動(dòng)使系統(tǒng)持久地滿足用戶的需要軟件生命周期的各階段任務(wù)軟件工程層次模型軟件工程： 一種層次化模型質(zhì)量關(guān)注點(diǎn)過(guò)程方法工具 軟件工程層次圖軟件工程三個(gè)要素：工具、方法、過(guò)程基礎(chǔ)層，綜合方法及工具，定義方法使用的順序，

20、所需要的管理為軟件開(kāi)發(fā)提供“如何做”的技術(shù)為軟件開(kāi)發(fā)提供自動(dòng)或半自動(dòng)的軟件支撐環(huán)境，建立計(jì)算機(jī)輔助軟件工程(CASE)的軟件開(kāi)發(fā)支撐系統(tǒng)軟件工程擴(kuò)展模型軟件工程方法學(xué)例ALM（Application Lifecycle Management，應(yīng)用生命周期管理）MSF（Microsoft Solution Framework，微軟方案框架 )RUP（Rational Unified Process，統(tǒng)一軟件過(guò)程 ）OOA/OOD/OOPOOA (Object-Oriented Analysis面向?qū)ο蠓治? 分析師拿到所有來(lái)自客戶的需求了；了解需求，分析需求、技術(shù)實(shí)現(xiàn)等，分析出來(lái)一個(gè)方案，即項(xiàng)目

21、需求。分析師們分析結(jié)果出來(lái)后，形成了最早的需求模型，包括可行性報(bào)告、需求分析報(bào)告、系統(tǒng)模型、草圖等。OOD (Object Oriented Design面向?qū)ο笤O(shè)計(jì)) 設(shè)計(jì)師們拿到需求模型進(jìn)行細(xì)化，模塊化，定義所有的細(xì)節(jié)，設(shè)計(jì)軟件的詳圖，這里就是詳細(xì)的需求分析規(guī)格書和具體的設(shè)計(jì)文檔。OOP (Object Oriented Programming面象對(duì)象程序設(shè)計(jì)) 程序員按照設(shè)計(jì)圖的要求完成項(xiàng)目的實(shí)際操作部分，在項(xiàng)目里就是coding的工作和testing的工作。1.4 軟件過(guò)程軟件過(guò)程是為了獲得高質(zhì)量的軟件需要完成的一系列任務(wù)的框架，規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。A process def

22、ines Who is doing What, When, and How, in order to reach a certain goal.軟件過(guò)程定義了軟件工程的階段、應(yīng)用方法的順序、應(yīng)交付的文檔、保證軟件質(zhì)量的措施、標(biāo)志軟件開(kāi)發(fā)各階段的里程碑。 軟件過(guò)程框架模型 軟件過(guò)程是為了獲得高質(zhì)量軟件所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項(xiàng)任務(wù)的工作步驟。工作任務(wù)里程碑、交付物SQA(軟件質(zhì)量保障)點(diǎn) 公共過(guò)程框架輔助活動(dòng)框架活動(dòng)任務(wù)集合軟件過(guò)程模型軟件生命周期的每一階段都有明確的任務(wù)，把規(guī)模大、結(jié)構(gòu)復(fù)雜、管理復(fù)雜的軟件開(kāi)發(fā)變得容易控制和管理。各個(gè)階段的活動(dòng)如何銜接，開(kāi)發(fā)過(guò)程中采用什么樣的

23、策略，應(yīng)遵守什么樣的規(guī)定和制約，將這些活動(dòng)框架（忽略不必要的細(xì)節(jié)）用一種模型表示出來(lái)，稱為軟件過(guò)程模型（或軟件開(kāi)發(fā)模型或軟件生命周期模型）。軟件過(guò)程模型是軟件開(kāi)發(fā)全部過(guò)程、活動(dòng)和任務(wù)的結(jié)構(gòu)框架。常用軟件過(guò)程模型（1）瀑布模型(Waterfall Model ）（2）快速原型模型(Rapid Prototype Model)（3）增量模型 (Incremental Model)（4）螺旋模型 (Spiral Model)（5）面向?qū)ο竽Ｐ停▏娙Ｐ?、可重用組件模型）（6）統(tǒng)一軟件開(kāi)發(fā)過(guò)程（IBM RUP）（7）敏捷(靈活)過(guò)程與極限編程（8）微軟過(guò)程（Microsoft Solution Fra

24、mework）（1）瀑布模型(Waterfall Model)傳統(tǒng)瀑布模型評(píng)審評(píng)審評(píng)審評(píng)審評(píng)審瀑布模型問(wèn)題定義可行性研究需求分析總體設(shè)計(jì)詳細(xì)設(shè)計(jì)編碼與單元測(cè)試綜合測(cè)試軟件維護(hù)軟件定義時(shí)期軟件開(kāi)發(fā)時(shí)期軟件維護(hù)時(shí)期瀑布模型的特點(diǎn)階段間具有順序性和依賴性提供了軟件過(guò)程模型的基本框架,強(qiáng)調(diào)了每一階段活動(dòng)的嚴(yán)格順序。前一階段產(chǎn)品（文檔）驅(qū)動(dòng)下一階段的工作。推遲實(shí)現(xiàn)的觀點(diǎn)程序的物理實(shí)現(xiàn)集中在開(kāi)發(fā)階段的后期，用戶在最后才能看到自己的產(chǎn)品。質(zhì)量保證的觀點(diǎn)每一個(gè)階段必須完成規(guī)定的文檔；以評(píng)審確認(rèn)階段工作，即上一階段的結(jié)束，下一階段的開(kāi)始。傳統(tǒng)瀑布模型存在什么問(wèn)題？改進(jìn)的瀑布模型及時(shí)反饋：開(kāi)發(fā)時(shí)盡早知道上一階段的

25、錯(cuò)誤。維護(hù)分類：根據(jù)軟件維護(hù)的內(nèi)容和程度，確定維護(hù)的階段。評(píng)審評(píng)審評(píng)審評(píng)審評(píng)審反饋反饋反饋反饋軟件維護(hù)瀑布模型的優(yōu)缺點(diǎn)瀑布模型適合于用戶需求明確、完整、無(wú)重大變化的軟件項(xiàng)目開(kāi)發(fā)。瀑布模型的成功在很大程度上是由于它基本上是一種文檔驅(qū)動(dòng)的模型。“瀑布模型是由文檔驅(qū)動(dòng)的”，這個(gè)事實(shí)是它的一個(gè)主要缺點(diǎn)。實(shí)際項(xiàng)目很少按照該模型給出的順序進(jìn)行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統(tǒng)開(kāi)發(fā)完成。 （2）快速原型模型 (Rapid Prototype Model) 在用戶不能給出完整、準(zhǔn)確的需求說(shuō)明，或者開(kāi)發(fā)者不能確定算法的有效性、操作系統(tǒng)的適應(yīng)性或人機(jī)交互的形式等許多情況下，可以根據(jù)用戶的一

26、組基本需求，快速建造一個(gè)原型（可運(yùn)行的軟件），然后進(jìn)行評(píng)估，進(jìn)一步精化、調(diào)整原型，使其滿足用戶的要求，也使開(kāi)發(fā)者對(duì)將要做的事情有更好的理解。建造/修改原型 聽(tīng)取用 戶意見(jiàn)用戶測(cè)試運(yùn)行原型原型實(shí)現(xiàn)范型快速原型模型快速原型法是一種新型的軟件開(kāi)發(fā)方法，它使用交互的，快速建立起來(lái)的原型取代了形式的、僵硬的大量的規(guī)格說(shuō)明，用戶通過(guò)在計(jì)算機(jī)上實(shí)際運(yùn)行和試用原型系統(tǒng)而向開(kāi)發(fā)者提供真實(shí)的反饋意見(jiàn)。建立原型系統(tǒng)修改原型符合用戶需要的應(yīng)用系統(tǒng)用戶試用反饋意見(jiàn)快速原型模型快速原型驗(yàn)證規(guī)格說(shuō)明驗(yàn)證設(shè)計(jì)驗(yàn)證編碼測(cè)試綜合測(cè)試維護(hù)變化的需求驗(yàn)證維護(hù)過(guò)程開(kāi)發(fā)過(guò)程采用不帶反饋的瀑布模型，進(jìn)行快速開(kāi)發(fā)和修改。原型系統(tǒng)提交用戶評(píng)測(cè)

27、，反復(fù)修改，直到用戶滿意。原型模型存在的問(wèn)題 為了使原型盡快的工作，沒(méi)有考慮軟件的總體質(zhì)量和長(zhǎng)期的可維護(hù)性。 為了演示，可能采用不合適的操作系統(tǒng)、編程語(yǔ)言、效率低的算法，這些不理想的選擇成了系統(tǒng)的組成部分。 開(kāi)發(fā)過(guò)程不便于管理。有效的使用原型模式 建造原型僅是為了定義需求，之后就被拋棄（或被部分拋棄），實(shí)際的軟件在充分考慮了質(zhì)量和可維護(hù)性之后才被開(kāi)發(fā)。3）增量模型 (Incremental Model)是一種漸進(jìn)地開(kāi)發(fā)逐步完善的軟件版本的模型。需求分析驗(yàn)證規(guī)格說(shuō)明驗(yàn)證設(shè)計(jì)驗(yàn)證維護(hù)針對(duì)每個(gè)構(gòu)件完成詳細(xì)設(shè)計(jì)、編碼和集成，經(jīng)測(cè)試后交付給用戶需求分析一步到位；功能模塊作為增量逐步交付。增量模型分析分析

28、分析分析設(shè)計(jì)設(shè)計(jì)設(shè)計(jì)設(shè)計(jì)編碼編碼編碼編碼測(cè)試測(cè)試測(cè)試測(cè)試增量1增量2 增量3增量4 交付交付交付交付反復(fù)地應(yīng)用瀑布模型的基本成分和原型模型的迭代特征，每一個(gè)線型過(guò)程產(chǎn)生一個(gè)“增量”的發(fā)布或提交，該增量均是一個(gè)可運(yùn)行的產(chǎn)品。早期的版本實(shí)現(xiàn)用戶的基本需求，并提供給用戶評(píng)估的平臺(tái)。需求作為增量逐步交付。增量模型的優(yōu)點(diǎn)在較短時(shí)間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，并分批、逐步地向用戶提交產(chǎn)品。從第一個(gè)構(gòu)件交付之日起，用戶就能做一些有用的工作。整個(gè)軟件產(chǎn)品被分解成許多個(gè)增量構(gòu)件，開(kāi)發(fā)人員可以一個(gè)構(gòu)件一個(gè)構(gòu)件地逐步開(kāi)發(fā)。逐步增加產(chǎn)品功能可以使用戶有較充裕的時(shí)間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個(gè)全新的軟件可能給客

29、戶組織帶來(lái)的沖擊。采用增量模型比采用瀑布模型和快速原型模型需要更精心的設(shè)計(jì)，但在設(shè)計(jì)階段多付出的勞動(dòng)將在維護(hù)階段獲得回報(bào)。增量模型的困難在把每個(gè)新的增量構(gòu)件集成到現(xiàn)有軟件體系結(jié)構(gòu)中時(shí)，必須不破壞原來(lái)已經(jīng)開(kāi)發(fā)出的產(chǎn)品。此外，必須把軟件的體系結(jié)構(gòu)設(shè)計(jì)得便于按這種方式進(jìn)行擴(kuò)充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過(guò)程必須簡(jiǎn)單、方便，也就是說(shuō)，軟件體系結(jié)構(gòu)必須是開(kāi)放的。開(kāi)發(fā)人員既要把軟件系統(tǒng)看作整體。又要看成可獨(dú)立的構(gòu)件，產(chǎn)生觀念上的矛盾。多個(gè)構(gòu)件并行開(kāi)發(fā)，具有集成的風(fēng)險(xiǎn)。4）螺旋模型 (Spiral Model) 軟件風(fēng)險(xiǎn)是任何軟件開(kāi)發(fā)項(xiàng)目中都普遍存在的實(shí)際問(wèn)題，項(xiàng)目越大，軟件越復(fù)雜，承擔(dān)該項(xiàng)目所冒的風(fēng)險(xiǎn)也越大

30、。 對(duì)于復(fù)雜的大型軟件，開(kāi)發(fā)一個(gè)原型往往達(dá)不到要求。螺旋模型將瀑布模型和增量模型結(jié)合起來(lái)，加入了風(fēng)險(xiǎn)分析。在該模型中，軟件開(kāi)發(fā)是一系列的增量發(fā)布，早期的迭代中，發(fā)布的增量可能是一個(gè)紙上的模型或原型，在以后的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。 螺旋模型的基本思想是降低風(fēng)險(xiǎn)。簡(jiǎn)單的螺旋模型快速原型驗(yàn)證規(guī)格說(shuō)明驗(yàn)證設(shè)計(jì)驗(yàn)證編碼測(cè)試綜合測(cè)試維護(hù)變化的需求驗(yàn)證風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析風(fēng)險(xiǎn)分析可看作在每個(gè)階段之前都增加了風(fēng)險(xiǎn)分析過(guò)程的快速原型模型。每一個(gè)階段都可能存在不同的風(fēng)險(xiǎn)！完整的螺旋模型原型版本當(dāng)前進(jìn)度 螺旋模型風(fēng)險(xiǎn)分析工程實(shí)施用戶交流用戶評(píng)估產(chǎn)品維護(hù)項(xiàng)目產(chǎn)品增強(qiáng)項(xiàng)目新產(chǎn)品開(kāi)發(fā)項(xiàng)目

31、概念開(kāi)發(fā)項(xiàng)目計(jì)劃建造及發(fā)布螺旋模型的優(yōu)點(diǎn)和特點(diǎn)螺旋模型的優(yōu)點(diǎn)對(duì)可選方案和約束條件的強(qiáng)調(diào)有利于已有軟件的重用，也有助于把軟件質(zhì)量作為軟件開(kāi)發(fā)的一個(gè)重要目標(biāo)減少了過(guò)多測(cè)試或測(cè)試不足維護(hù)和開(kāi)發(fā)之間并沒(méi)有本質(zhì)區(qū)別螺旋模型的特點(diǎn)風(fēng)險(xiǎn)驅(qū)動(dòng)，需要相當(dāng)豐富的風(fēng)險(xiǎn)評(píng)估經(jīng)驗(yàn)和專門知識(shí)，否則風(fēng)險(xiǎn)更大主要適用于內(nèi)部開(kāi)發(fā)的大規(guī)模軟件項(xiàng)目，隨著過(guò)程的進(jìn)展演化，開(kāi)發(fā)者和用戶能夠更好的識(shí)別和對(duì)待每一個(gè)演化級(jí)別上的風(fēng)險(xiǎn)隨著迭代次數(shù)的增加，工作量加大，軟件開(kāi)發(fā)成本增加（5-1）面向?qū)ο?噴泉模型噴泉模型(Fountain Model)是面向?qū)ο竽Ｐ?。主要用于支持面向?qū)ο箝_(kāi)發(fā)過(guò)程，體現(xiàn)了軟件創(chuàng)建所固有的迭代和無(wú)間隙的特征分析設(shè)計(jì)實(shí)

32、現(xiàn)測(cè)試集成演化（5-2）面向?qū)ο?構(gòu)件集成模型(Component Integration Model) 構(gòu)件（components)也稱為組件，是一段實(shí)現(xiàn)一系列有確定接口的程序體，具有自己的功能和邏輯，能同其他構(gòu)件集成起來(lái)協(xié)調(diào)工作。該模型（又稱為可重用部件組裝模型）支持軟件重用（Reusability） ，對(duì)縮短軟件開(kāi)發(fā)周期、降低項(xiàng)目成本有重要的現(xiàn)實(shí)意義。同時(shí)，建造符合某應(yīng)用領(lǐng)域體系結(jié)構(gòu)標(biāo)準(zhǔn)的構(gòu)件，可以用來(lái)搭建分布式的、跨越不同操作平臺(tái)(集成化軟件開(kāi)發(fā)環(huán)境（ISEE）)的軟件，擴(kuò)展了軟件的應(yīng)用前景，促進(jìn)了軟件標(biāo)準(zhǔn)化、商品化的發(fā)展。在此基礎(chǔ)上專家們又提出了“基于構(gòu)件的軟件工程”(CBSE)。構(gòu)

33、件集成模型 構(gòu)件集成模型 軟件體系結(jié)構(gòu)被建立后，必須用構(gòu)件去充實(shí)，這些構(gòu)件可從復(fù)用庫(kù)中獲得，或者根據(jù)專門需要而開(kāi)發(fā)。整個(gè)過(guò)程可以演化地進(jìn)行，面向?qū)ο蠓椒ńo予技術(shù)上的支持。構(gòu)件集成模型Sommerville提出基于組件開(kāi)發(fā)有兩種思路：完成高層設(shè)計(jì)，對(duì)設(shè)計(jì)中的組件給出描述，以便找出可復(fù)用的組件，這些組件可在體系結(jié)構(gòu)層次上加入或更詳細(xì)的設(shè)計(jì)層次上加入。先根據(jù)需求搜尋可復(fù)用組件，再將設(shè)計(jì)建立在獲得的組件基礎(chǔ)上。這兩種思路可結(jié)合起來(lái)。設(shè)計(jì)系統(tǒng)體系結(jié)構(gòu)描述組件搜尋可復(fù)用組件集成系統(tǒng)先完成架構(gòu)設(shè)計(jì)的復(fù)用系統(tǒng)需求描述搜尋可復(fù)用組件對(duì)需求作某些修改體系結(jié)構(gòu)設(shè)計(jì)集成系統(tǒng)復(fù)用驅(qū)動(dòng)設(shè)計(jì)構(gòu)件技術(shù)主要有三種流行標(biāo)準(zhǔn)對(duì)象管

34、理組織OMG的CORBA微軟的COM / DCOMSUN的 EJB ( Enterprise JavaBean )OMG的CORBA對(duì)象管理組織OMG發(fā)布的公用對(duì)象請(qǐng)求代理體系結(jié)構(gòu)(Common Object Request Broker Architecture)。通過(guò)一個(gè)對(duì)象請(qǐng)求代理（ORB)提供一系列服務(wù)，使得一個(gè)構(gòu)件和其他構(gòu)件通信，而不管它們?cè)谙到y(tǒng)中的位置，實(shí)現(xiàn)了遠(yuǎn)程對(duì)象通過(guò)接口進(jìn)行通信的機(jī)制。為了解決CORBA對(duì)象引用不透明、缺少多重接口、系統(tǒng)過(guò)于復(fù)雜等問(wèn)題，專家們又開(kāi)發(fā)了新一代面向?qū)ο笾虚g件平臺(tái) ICE （ Internet Communications Engine互聯(lián)網(wǎng)通信引擎

35、）。使構(gòu)建分布式應(yīng)用系統(tǒng)更容易、性能和伸縮性更好。微軟的COM / DCOMCOM微軟提出、開(kāi)發(fā)的構(gòu)件對(duì)象模型（Component Object Model)，它提供了運(yùn)行于windows之上的單個(gè)應(yīng)用系統(tǒng)使用不同廠商生產(chǎn)的構(gòu)件的規(guī)約。DOM基于分布式環(huán)境下的COM稱為DCOM (Distribute COM)。SUN的 EJB ( Enterprise JavaBean )隨著Java在企業(yè)級(jí)應(yīng)用的地位日趨重要，Sun提出了一個(gè)統(tǒng)一的企業(yè)級(jí)Java平臺(tái)J2EE（Java 2 Enterprise Edition）。在J2EE中，EJB負(fù)責(zé)最核心的業(yè)務(wù)處理。它為服務(wù)器端的應(yīng)用程序提供了一種與廠

36、商無(wú)關(guān)的Java接口，讓任何符合EJB規(guī)范的構(gòu)件都可以運(yùn)行在每一臺(tái)這樣的服務(wù)器上。（6）統(tǒng)一軟件開(kāi)發(fā)過(guò)程統(tǒng)一軟件開(kāi)發(fā)過(guò)程（Rational Unified Process， RUP)是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟件過(guò)程模型。RUP重復(fù)一系列周期，每個(gè)周期由一個(gè)交付給用戶的產(chǎn)品結(jié)束。每個(gè)周期劃分為初始、細(xì)化、構(gòu)造和移交四個(gè)階段，每個(gè)階段圍繞著五個(gè)核心工作流（需求、分析、設(shè)計(jì)、實(shí)現(xiàn)、測(cè)試）分別迭代。RUP的“最佳實(shí)踐”軟件開(kāi)發(fā)經(jīng)驗(yàn)迭代式開(kāi)發(fā)按照原型模型，迭代開(kāi)發(fā)產(chǎn)品，獲取用戶的反饋意見(jiàn)，加深對(duì)需求的理解，逐步趨向最終產(chǎn)品。管理需求人為需求分析是一個(gè)

37、連續(xù)過(guò)程，使用有效的方法（如用例和腳本）捕獲用戶變化的需求，以驅(qū)動(dòng)設(shè)計(jì)與實(shí)現(xiàn)。使用基于構(gòu)建的體系結(jié)構(gòu)提供使用現(xiàn)有構(gòu)建和新開(kāi)發(fā)構(gòu)件定義體系結(jié)構(gòu)的方法，采用構(gòu)建來(lái)建造系統(tǒng)，從而減低軟件復(fù)雜性，提供軟件重用率?？梢暬２捎每梢暬ＵZ(yǔ)言（UML）描述系統(tǒng)模型。驗(yàn)證軟件質(zhì)量建立貫穿整個(gè)開(kāi)發(fā)過(guò)程的、全員參與的軟件質(zhì)量評(píng)估方法?？刂栖浖兏刂?、跟蹤和監(jiān)控軟件的修改，確保迭代開(kāi)發(fā)的成功。RUP軟件開(kāi)發(fā)生命周期RUP初始階段：進(jìn)行問(wèn)題定義，確定目標(biāo)，評(píng)估其可行性，降低關(guān)鍵風(fēng)險(xiǎn)。細(xì)化階段：制定項(xiàng)目計(jì)劃、配置各類資源、建立系統(tǒng)架構(gòu)（包括各類視圖）。構(gòu)造階段：開(kāi)發(fā)整個(gè)產(chǎn)品，并確保產(chǎn)品可移交給用戶。移交階段：產(chǎn)品

38、發(fā)布、安裝、用戶培訓(xùn)。 在每個(gè)階段的每次迭代的最后，用例模型、分析模型、設(shè)計(jì)模型、實(shí)現(xiàn)模型都會(huì)增量，每個(gè)階段結(jié)束的里程碑處，管理層做出是否繼續(xù)、進(jìn)度、預(yù)算、是否給下一階段提供資助等決定。 不同階段工作流的側(cè)重點(diǎn)不同，前兩階段大部分工作集中在需求、分析和架構(gòu)設(shè)計(jì)上；在構(gòu)造階段，重點(diǎn)轉(zhuǎn)移到詳細(xì)設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試上。（7）敏捷過(guò)程與極限編程2001年，為了解決許多公司的軟件團(tuán)隊(duì)陷入不斷增長(zhǎng)的過(guò)程泥潭，一批業(yè)界著名專家一起概括出了一些可以讓軟件開(kāi)發(fā)團(tuán)隊(duì)具有快速工作、響應(yīng)變化能力的價(jià)值觀和原則，他們稱自己為敏捷聯(lián)盟。敏捷開(kāi)發(fā)過(guò)程的方法很多，主要有：SCRUM，Crystal,特征驅(qū)動(dòng)軟件開(kāi)發(fā)（Featur

39、e Driven Development，簡(jiǎn)稱FDD），自適應(yīng)軟件開(kāi)發(fā)(Adaptive Software Development，簡(jiǎn)稱ASD)，以及最重要的極限編程(eXtreme Programming,簡(jiǎn)稱XP)。極限編程(XP)是于1998年由Smalltalk社群中的大師級(jí)人物Kent Beck首先倡導(dǎo)的。觀點(diǎn)在按照我的理解方式審查了軟件開(kāi)發(fā)的生命周期后，我得出一個(gè)結(jié)論：實(shí)際上滿足工程設(shè)計(jì)標(biāo)準(zhǔn)的惟一軟件文檔，就是源代碼清單。 - Jack Reeves 設(shè)計(jì)和編程都是人的活動(dòng)。忘記這一點(diǎn)，將會(huì)失去一切。 - Bjarne Stroustrup 敏捷過(guò)程敏捷軟件開(kāi)發(fā)宣言個(gè)體和交互 勝過(guò)

40、 過(guò)程和工具可以工作的軟件 勝過(guò) 面面俱到的文檔客戶合作 勝過(guò) 合同談判響應(yīng)變化 勝過(guò) 遵循計(jì)劃敏捷宣言遵循的原則我們最優(yōu)先要做的是通過(guò)盡早的、持續(xù)的交付有價(jià)值的軟件來(lái)使客戶滿意。即使到了開(kāi)發(fā)的后期，也歡迎改變需求。敏捷過(guò)程利用變化來(lái)為客戶創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個(gè)星期到幾個(gè)月，交付的時(shí)間間隔越短越好。 在整個(gè)項(xiàng)目開(kāi)發(fā)期間，業(yè)務(wù)人員和開(kāi)發(fā)人員必須天天都在一起工作。 圍繞被激勵(lì)起來(lái)的個(gè)體來(lái)構(gòu)建項(xiàng)目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。 在團(tuán)隊(duì)內(nèi)部，最具有效果并富有效率的傳遞信息的方法，就是面對(duì)面的交談。 工作的軟件是首要的進(jìn)度度量標(biāo)準(zhǔn)。 敏

41、捷過(guò)程提倡可持續(xù)的開(kāi)發(fā)速度。責(zé)任人、開(kāi)發(fā)者和用戶應(yīng)該能夠保持一個(gè)長(zhǎng)期的、恒定的開(kāi)發(fā)速度。 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計(jì)會(huì)增強(qiáng)敏捷能力。 簡(jiǎn)單是最根本的。 最好的構(gòu)架、需求和設(shè)計(jì)出于自組織團(tuán)隊(duì)。 每隔一定時(shí)間，團(tuán)隊(duì)會(huì)在如何才能更有效地工作方面進(jìn)行反省，然后相應(yīng)地對(duì)自己的行為進(jìn)行調(diào)整。敏捷過(guò)程認(rèn)為的軟件設(shè)計(jì)“壞味道”僵化性很難對(duì)系統(tǒng)進(jìn)行改動(dòng)，因?yàn)槊總€(gè)改動(dòng)都會(huì)迫使許多對(duì)系統(tǒng)其他部分的其它改動(dòng)。 脆弱性對(duì)系統(tǒng)的改動(dòng)會(huì)導(dǎo)致系統(tǒng)中和改動(dòng)的地方在概念上無(wú)關(guān)的許多地方出現(xiàn)問(wèn)題。 牢固性很難解開(kāi)系統(tǒng)的糾結(jié)，使之成為一些可在其他系統(tǒng)中重用的組件。 粘滯性做正確的事情比做錯(cuò)誤的事情要困難。 不必要的復(fù)雜性設(shè)計(jì)中包

42、含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)。 不必要的重復(fù)性設(shè)計(jì)中包含有重復(fù)的結(jié)構(gòu)，而該重復(fù)的結(jié)構(gòu)本可以使用單一的抽象進(jìn)行統(tǒng)一。 晦澀性很難閱讀、理解。沒(méi)有很好地表現(xiàn)出意圖。敏捷開(kāi)發(fā)避免“軟件腐化味” 的面向?qū)ο蟮脑O(shè)計(jì)原則單一職責(zé)原則(SRP) ：一個(gè)類應(yīng)該僅有一個(gè)引起它變化的原因。 開(kāi)放-封閉原則(OCP) ：軟件實(shí)體應(yīng)該是可以擴(kuò)展的，但是不可修改。 Liskov替換原則(LSP) ：子類型必須能夠替換掉它們的基類型。 依賴倒置原則(DIP) ：抽象不應(yīng)該依賴于細(xì)節(jié)。細(xì)節(jié)應(yīng)該依賴于抽象。 接口隔離原則(ISP) ：不應(yīng)該強(qiáng)迫客戶依賴于它們不用的方法。接口屬于客戶，不屬于它所在的類層次結(jié)構(gòu)。 重用發(fā)布等價(jià)原則(REP) ：重用的粒度就是發(fā)布的粒度。 共同封閉原則(CCP) ：包中的所有類對(duì)于同一類性質(zhì)的變化應(yīng)該是共同封閉的。一個(gè)變化若對(duì)一個(gè)包產(chǎn)生影響，則將對(duì)該包中的所有類產(chǎn)生影響，而對(duì)于其他的包不造成任何影響。 共同重用原則(CRP) ：一個(gè)包中的所有類應(yīng)該是共同重用的。如果重用了包中的一個(gè)類，那么就要重用包中的所有類。 無(wú)環(huán)依賴原則(ADP) ：在包的依賴關(guān)系圖中不允許存在環(huán)。 穩(wěn)定依賴原則(SDP) ：朝著穩(wěn)定的方向進(jìn)行依賴。 穩(wěn)定抽象原則(SAP)