軟件工程課件

1第1章

軟件工程概述1.0軟體概念軟體軟體的特點軟體發(fā)展歷程軟體概念-軟體軟體（

Software）是電腦系統(tǒng)中與硬體相互依存的另一部分，它是包括程式（Program）

，數(shù)據(jù)（Data）及其相關(guān)文檔（Document）的完整集合。Software=Program+Data+Document程式是按事先設(shè)計的功能和性能要求執(zhí)行的指令序列數(shù)據(jù)是使程式能正常操縱資訊的數(shù)據(jù)結(jié)構(gòu)文檔是與程式開發(fā)，維護和使用有關(guān)的圖文材料軟體概念-軟體的特點抽象性軟體是邏輯實體，沒有明顯的製造過程，運行和使用沒有磨損與老化問題。依存性軟體開發(fā)和運行依賴於電腦系統(tǒng)。工藝性軟體開發(fā)至今尚未完全擺脫手工工藝的開發(fā)方式。複雜性軟體邏輯結(jié)構(gòu)、開發(fā)技術(shù)、專案管理複雜。成本高開發(fā)成本、維護成本高。風(fēng)險大軟體專案的成功率低。維護難維護不能依靠原開發(fā)者，理解軟體代碼難，維護也是開發(fā)，維護成本高軟體工作涉及各種社會因素政策規(guī)章、管理思想、文化背景、資訊素養(yǎng)、技術(shù)水準、系統(tǒng)介面等。軟體的複雜性邏輯複雜軟體的邏輯結(jié)構(gòu)非常複雜開發(fā)複雜成本難以估算、進度難以控制、人員素質(zhì)要求、品質(zhì)得不到保證成本高例：軟體成本風(fēng)險大1995年美國Standish諮詢集團的統(tǒng)計分析(至90年代初的軟體專案執(zhí)行情況)成功：16.2%失?。?1％受到挑戰(zhàn)：53.8%近幾年來的統(tǒng)計數(shù)據(jù)成功：26％失敗：28％受到挑戰(zhàn)：46%維護難維護形式多樣化改正性：修改故障完善性：增加功能適應(yīng)性：移植維護成本越來越高55%到70％維護帶來的問題可能引發(fā)新的錯誤，經(jīng)維護後邏輯結(jié)構(gòu)更複雜1.1軟體危機軟體危機軟體發(fā)展歷程，軟體危機，軟體危機的表現(xiàn)。產(chǎn)生軟體危機的原因軟體特點有關(guān)，開發(fā)中的問題，維護中的問題。消除軟體危機的途徑正確認識“軟體”，重視軟體過程，採用有效的軟體開發(fā)技術(shù)和方法，引進工程管理方法。軟體發(fā)展歷程早期面向批處理有限的分佈自定義軟體第二階段多用戶即時資料庫軟體產(chǎn)品第三階段分佈式系統(tǒng)嵌入“智能”低成本硬體消費者的影響第四階段強大的桌面系統(tǒng)面向?qū)ο蠹夹g(shù)專家系統(tǒng)人工神經(jīng)網(wǎng)路並行計算網(wǎng)路電腦1950196019701980199020001968年10月，北大西洋公約組織（NATO）的科學(xué)家在德國召開的學(xué)術(shù)會議上正式提出了軟體危機問題。軟體危機軟體危機是電腦軟體開發(fā)和維護過程中所遇到的一系列嚴重問題。主要包括下列兩個方面的問題：如何開發(fā)軟體，以滿足對軟體的日益增長的需求；如何維護不斷增多的已有軟體。軟體危機的典型表現(xiàn)對軟體開發(fā)成本和進度的估計常常很不準確；用戶對交付的軟體經(jīng)常不滿意；軟體產(chǎn)品的品質(zhì)往往達不到要求；開發(fā)出來的軟體通常難以維護；軟體產(chǎn)品文檔資料不適用和不完善；軟體成本在整個系統(tǒng)總成本中所占比例逐年上升；軟體開發(fā)生產(chǎn)率的提高不能滿足對軟體需求的增長；………成本問題電腦軟體和硬體費用比越來越大IBM360OS,5000多人年，耗時4年(1963－1966)，花費2億多美元美國空軍：1955年軟體占總費用(電腦系統(tǒng))的18%，70年60%，85年達到85％美國全球軍事指揮控制系統(tǒng)，硬體1億美元，軟體高達7.2億美元軟體品質(zhì)問題軟體應(yīng)用面的擴大：科學(xué)計算、軍事、航空航太、工業(yè)控制、企業(yè)管理、辦公、家庭軟體越來越多的應(yīng)用於安全攸關(guān)的系統(tǒng)，對軟體品質(zhì)提出更高的要求80年代歐洲亞麗安娜火箭的發(fā)射失敗，原因是軟體錯誤美國阿托拉斯火箭的發(fā)射失敗，原因是軟體故障軟體的複雜性越來越高英國1986年開發(fā)的辦公室資訊系統(tǒng)Folios經(jīng)4年，因性能達不到要求，1989年取消日本第5代機因為軟體問題在投入50億美元後於1993年下馬由於軟體品質(zhì)問題導(dǎo)致失敗的軟體專案非常多專案進度問題專案進度難以控制專案延期比比皆是由於進度問題而取消的軟體專案較常見只有一小部分的專案能夠按期完成軟體維護問題軟體維護非常困難軟體維護的多樣性軟體維護的複雜性軟體維護的副作用產(chǎn)生軟體危機的原因與軟體本身的特點有關(guān)成本高、風(fēng)險大、難於維護、邏輯複雜。軟體是電腦系統(tǒng)中的邏輯實體而不是物理實體，軟體生產(chǎn)與硬體不同，在它的開發(fā)過程中沒有明顯的製造過程。軟體是通過人們的智力活動，把知識與技術(shù)轉(zhuǎn)化成資訊的一種產(chǎn)品。在軟體的運行過程中，沒有“用壞”的問題。軟體維護意味著修正原來的設(shè)計，較為困難。與軟體開發(fā)與維護的方法不正確有關(guān)軟體專業(yè)人員對軟體開發(fā)和維護存在糊塗觀念，在實踐過程中採用了錯誤的方法和技術(shù)。如忽視軟體需求分析的重要性；輕視軟體維護。消除軟體危機的途徑正確認識“軟體”軟體≠程式，軟體是相關(guān)程式、數(shù)據(jù)及文檔的集合。正確認識“軟體開發(fā)”軟體開發(fā)不是個體勞動，而主要是一種有組織的團隊活動。研究軟體開發(fā)的技術(shù)手段在軟體開發(fā)中使用已證明行之有效的技術(shù)，研究和探索新的技術(shù)。更好地使用軟體工具，建立一個良好的軟體工程支撐環(huán)境。研究軟體開發(fā)的管理方法在軟體開發(fā)中使用已證明行之有效的工程管理方法。組織良好、管理嚴密，使各類人員協(xié)同配合，共同完成軟體開發(fā)的工程專案。軟體工程學(xué)的是由於“軟體危機”的出現(xiàn)和加重而產(chǎn)生的，研究用工程的方法來管理軟體的開發(fā)。開發(fā)一個具有一定規(guī)模和複雜性的軟體系統(tǒng)與編寫一個簡單的程式不一樣。大型、複雜軟體系統(tǒng)的開發(fā)是一項工程，必須按照工程化的方法組織軟體的生產(chǎn)和管理，必須經(jīng)過分析、設(shè)計、實現(xiàn)、測試、維護等一系列軟體過程和活動軟體工程學(xué)的產(chǎn)生提出有效的方法和工具支持軟件開發(fā)1968年提出軟體工程概念和思想20世紀70年代的結(jié)構(gòu)化軟體開發(fā)方法20世紀80年代的面向?qū)ο蟮能涹w開發(fā)方法新的技術(shù):軟體重用、快速原型、需求工程典型技術(shù):COM,Java,C++,J2EE,.Net,….支撐工具和環(huán)境：Jbuilder,VisualStudio,WebLogic,…解決危機的技術(shù)途徑20世紀80年代末，美國DoD和業(yè)界開始認識到管理的重要性美國DoD的一項研究表明，70%的專案由於管理不善導(dǎo)致難以控制進步、成本和品質(zhì)；進一步的研究發(fā)現(xiàn)：管理是影響軟體專案成功開發(fā)的全局性因素，而技術(shù)只影響局部如果軟體開發(fā)組織不能對軟體專案進行有效管理，就不能充分發(fā)揮軟體開發(fā)方法和工具的潛力，也就不能高效率地開發(fā)出高質(zhì)量的軟體產(chǎn)品解決危機的管理途徑1.2軟體工程軟體工程的概念軟體工程的基本原理軟體工程方法學(xué)軟體工程概念軟體工程是指導(dǎo)電腦軟體開發(fā)與維護的一門工程學(xué)科。採用工程的概念、原理、方法和技術(shù)來開發(fā)和維護軟體。將經(jīng)過時間和實踐考驗而證明正確的管理方法和最好的技術(shù)手段結(jié)合起來，經(jīng)濟有效地開發(fā)和維護軟體。軟體工程是一門不斷發(fā)展的學(xué)科。軟體工程定義(FritzBauer,1968)Theestablishmentanduseofsoundengineeringprinciples(methods)inordertoobtaineconomicallysoftwarethatisreliableandworksonrealmachines.(1968-FritzBauer)

軟體工程就是建立和使用一套合理的工程原理，從而經(jīng)濟地獲得可靠的、可以在實際機器上高效運行的軟體。軟體工程定義(IEEE,1990)Softwareengineering.(1)Theapplicationofasystematic,disciplined,quantifiableapproachtothedevelopment,operation,andmaintenanceofsoftware;thatis,theapplicationofengineeringtosoftware.(2)Thestudyofapproachesasin(1).(IEEE(TheInstituteforElectricalandElectronicengineers)Std610-1990.）

軟體工程是：（1）把系統(tǒng)的、規(guī)範的、可度量的途徑應(yīng)用於軟體開發(fā)、運行和維護過程，也就是把工程應(yīng)用於軟體；（2）研究（1）中提到的途徑。軟體工程定義(CMU/SEI,1990)

Engineeringisthe

systematicapplicationofscientificknowledge

increatingandbuildingcost-effectivesolutionstopracticalproblemsintheserviceofmankind.

Softwareengineeringisthat

formofengineering

thatappliestheprinciplesofcomputerscienceandmathematics

toachievingcost-effectivesolutionstosoftwareproblems.SEIsoftwareengineeringdefinitionfrom1990SEIReportonUndergraduateSoftwareEngineeringEducation(CMU/SEI-90-TR-003):軟體工程定義軟體工程是應(yīng)用電腦科學(xué)、數(shù)學(xué)及管理科學(xué)等原理開發(fā)軟體的工程。它採用經(jīng)過實踐驗證的工程的原則、方法，以提高品質(zhì)，降低成本為目的。軟體工程的本質(zhì)特性關(guān)注於大型程式的構(gòu)造控制軟體複雜性適應(yīng)軟體的經(jīng)常變化性提高軟體開發(fā)的效率和諧合作開發(fā)軟體使軟體有效地支持它的用戶需求軟體是有一種文化背景的人為另一種文化背景的人開發(fā)的產(chǎn)品。軟體工程的基本原理用分階段的生命週期計畫嚴格管理堅持進行階段評審實行嚴格的產(chǎn)品控制採用現(xiàn)代程式設(shè)計技術(shù)結(jié)果應(yīng)能清楚地審查開發(fā)小組的人員應(yīng)該少而精承認不斷改進軟體工程實踐的必要性軟體工程包括技術(shù)和管理兩方面的內(nèi)容，是技術(shù)與管理緊密結(jié)合所形成的工程學(xué)科。通常把在軟體生命週期全過程中使用的一整套技術(shù)方法的集合稱為軟體工程方法學(xué)(methodology)，也稱為範型(paradigm)。軟體工程方法學(xué)軟體工程方法學(xué)三要素軟體工程方法學(xué)包含3個要素：方法、工具和過程。方法完成軟體開發(fā)各項任務(wù)的技術(shù)方法。工具為運用方法而提供的軟體工程支撐環(huán)境（支撐分析、設(shè)計、開發(fā)等）。過程規(guī)定了完成軟體開發(fā)各項任務(wù)的工作步驟。傳統(tǒng)軟體工程方法學(xué)傳統(tǒng)軟體工程方法學(xué)是生命週期方法學(xué)軟體生命週期一個軟體定義、開發(fā)、使用和維護，直到最終被廢棄，要經(jīng)歷的漫長的時期，稱為軟體的生命週期。生命週期方法學(xué)這種方法學(xué)把軟體生命週期的全過程依次劃分為若干個階段，然後順序地完成每個階段的任務(wù)。2面向?qū)ο蠓椒▽W(xué)面向?qū)ο笾饕拍顚ο?、類、繼承、消息等。面向?qū)ο蠓椒▽W(xué)這種方法學(xué)把數(shù)據(jù)和行為看成同等重要，它是一種以數(shù)據(jù)為主線，把數(shù)據(jù)和對數(shù)據(jù)的操作緊密結(jié)合起來的方法1.3軟體生命週期軟體生命週期概念軟體生命週期模型軟體生命週期各階段任務(wù)常見的軟體工程方法學(xué)（幾大公司）軟體生命週期概念軟體生命週期基本階段軟體生命週期由軟體定義、軟體開發(fā)和軟體維護三個時期組成，每個時期又可劃分若干個階段。生命週期方法學(xué)軟體工程採用的生命週期方法學(xué)就是從時間角度對軟體開發(fā)和維護的複雜性進行分解，把軟體生存的漫長週期依次劃分為若干個階段，每個階段都有獨立的任務(wù)，然後逐步完成每個階段的任務(wù)。劃分軟體生存週期階段的基本原則使各階段的任務(wù)之間盡可能相互獨立，同一個階段各項任務(wù)的性質(zhì)盡可能相同，從而降低每個階段任務(wù)的複雜程式，簡化不同階段之間的聯(lián)繫，有利於軟體開發(fā)工程的組織管理。1.4軟體生命週期模型

問題定義軟體定義可行性研究

需求分析

總體設(shè)計軟體生命週期軟體開發(fā) 詳細設(shè)計

編碼和單元測試（實現(xiàn)）

綜合測試 運行維護

軟體維護軟體生命週期基本階段的任務(wù)（1）軟體定義時期總目標的確定，可行性，採用策略，系統(tǒng)功能，所需資源與成本，工程進度表，也稱為系統(tǒng)分析時期，分為所定義，可行性研究和需求分析。（2）開發(fā)時期具體設(shè)計和實現(xiàn)前面所定義的軟體。分為：總體設(shè)計，詳細設(shè)計，編碼和單元測試，綜合測試。（3）維護時期使軟體儘量地滿足用戶需要，糾錯，適應(yīng)新環(huán)境，滿足新需求軟體生命週期的階段1.問題定義要解決的問題是什麼？2.可行性研究問題能夠解決嗎？3.需求分析為了解決問題需要做什麼？4.總體設(shè)計為了解決問題，大概怎樣做？5.詳細設(shè)計為了解決問題，具體怎樣做？6.編碼和單元測試編程實現(xiàn)，並測試每一個程式模組，驗證程式達到設(shè)計要求。7.綜合測試集成測試、壓力測試、驗收測試，驗證系統(tǒng)滿足需求。8.軟體維護改正性維護、適應(yīng)性維護、完善性維護、預(yù)防性維護，保障系統(tǒng)持久性滿足用戶的要求。問題定義可行性研究需求分析總體設(shè)計詳細設(shè)計編碼與單元測試綜合測試軟體維護要解決的問題是什麼？問題性質(zhì)、工程目標和規(guī)模的報告分析員：實際用戶+負責(zé)人是否有解決辦法？分析員高層邏輯模型，準確和具體的工程規(guī)模和目標，成本/效益分析等可行性報告為了解決的問題，目標系統(tǒng)必須做什麼？準確確定系統(tǒng)的功能系統(tǒng)的邏輯模型（數(shù)據(jù)流圖+數(shù)據(jù)字典+簡要演算法）如何解決這些問題模組劃分軟體結(jié)構(gòu)如何具體地實現(xiàn)系統(tǒng)：每個模組的流程圖（程式的詳細規(guī)格說明）通過各種類型的測試，使軟體達到預(yù)定的要求寫出正確的容易理解和容易維護的程式模組通過各種必要的維護活動使系統(tǒng)持久地滿足用戶的需要軟體生命週期的各階段任務(wù)軟體工程層次模型軟體工程：一種層次化模型品質(zhì)關(guān)注點過程方法工具

軟體工程層次圖軟體工程三個要素：工具、方法、過程基礎(chǔ)層，綜合方法及工具，定義方法使用的順序，所需要的管理為軟體開發(fā)提供“如何做”的技術(shù)為軟體開發(fā)提供自動或半自動的軟體支撐環(huán)境，建立電腦輔助軟體工程(CASE)的軟體開發(fā)支撐系統(tǒng)軟體工程擴展模型軟體工程方法學(xué)例ALM（ApplicationLifecycleManagement，應(yīng)用生命週期管理）MSF（MicrosoftSolutionFramework，微軟方案框架)RUP（RationalUnifiedProcess，統(tǒng)一軟體過程

）OOA/OOD/OOPOOA

(Object-OrientedAnalysis面向?qū)ο蠓治?分析師拿到所有來自客戶的需求了；瞭解需求，分析需求、技術(shù)實現(xiàn)等，分析出來一個方案，即專案需求。分析師們分析結(jié)果出來後，形成了最早的需求模型，包括可行性報告、需求分析報告、系統(tǒng)模型、草圖等。OOD(ObjectOrientedDesign面向?qū)ο笤O(shè)計)設(shè)計師們拿到需求模型進行細化，模組化，定義所有的細節(jié)，設(shè)計軟體的詳圖，這裏就是詳細的需求分析規(guī)格書和具體的設(shè)計文檔。OOP(ObjectOrientedProgramming面象對象程式設(shè)計)程式員按照設(shè)計圖的要求完成專案的實際操作部分，在專案裏就是coding的工作和testing的工作。1.4軟體過程軟體過程是為了獲得高質(zhì)量的軟體需要完成的一系列任務(wù)的框架，規(guī)定了完成各項任務(wù)的工作步驟。AprocessdefinesWhoisdoingWhat,When,andHow,inordertoreachacertaingoal.軟體過程定義了軟體工程的階段、應(yīng)用方法的順序、應(yīng)交付的文檔、保證軟體品質(zhì)的措施、標誌軟體開發(fā)各階段的里程碑。軟體過程框架模型軟體過程是為了獲得高質(zhì)量軟體所需要完成的一系列任務(wù)的框架，它規(guī)定了完成各項任務(wù)的工作步驟。工作任務(wù)里程碑、交付物SQA(軟體品質(zhì)保障)點公共過程框架輔助活動框架活動任務(wù)集合軟體過程模型軟體生命週期的每一階段都有明確的任務(wù)，把規(guī)模大、結(jié)構(gòu)複雜、管理複雜的軟體開發(fā)變得容易控制和管理。各個階段的活動如何銜接，開發(fā)過程中採用什麼樣的策略，應(yīng)遵守什麼樣的規(guī)定和制約，將這些活動框架（忽略不必要的細節(jié)）用一種模型表示出來，稱為軟體過程模型（或軟體開發(fā)模型或軟體生命週期模型）。軟體過程模型是軟體開發(fā)全部過程、活動和任務(wù)的結(jié)構(gòu)框架。常用軟體過程模型（1）瀑布模型(WaterfallModel）（2）快速原型模型(RapidPrototypeModel)（3）增量模型(IncrementalModel)（4）螺旋模型(SpiralModel)（5）面向?qū)ο竽Ｐ停▏娙Ｐ汀⒖芍赜媒M件模型）（6）統(tǒng)一軟體開發(fā)過程（IBMRUP）（7）敏捷(靈活)過程與極限編程（8）微軟過程（MicrosoftSolutionFramework）（1）瀑布模型(WaterfallModel)傳統(tǒng)瀑布模型評審評審評審評審評審瀑布模型問題定義可行性研究需求分析總體設(shè)計詳細設(shè)計編碼與單元測試綜合測試軟體維護軟體定義時期軟體開發(fā)時期軟體維護時期瀑布模型的特點階段間具有順序性和依賴性提供了軟體過程模型的基本框架,強調(diào)了每一階段活動的嚴格順序。前一階段產(chǎn)品（文檔）驅(qū)動下一階段的工作。推遲實現(xiàn)的觀點程式的物理實現(xiàn)集中在開發(fā)階段的後期，用戶在最後才能看到自己的產(chǎn)品。品質(zhì)保證的觀點每一個階段必須完成規(guī)定的文檔；以評審確認階段工作，即上一階段的結(jié)束，下一階段的開始。傳統(tǒng)瀑布模型存在什麼問題？改進的瀑布模型及時回饋：開發(fā)時儘早知道上一階段的錯誤。維護分類：根據(jù)軟體維護的內(nèi)容和程度，確定維護的階段。評審評審評審評審評審回饋回饋回饋回饋軟體維護瀑布模型的優(yōu)缺點瀑布模型適合於用戶需求明確、完整、無重大變化的軟體專案開發(fā)。瀑布模型的成功在很大程度上是由於它基本上是一種文檔驅(qū)動的模型。“瀑布模型是由文檔驅(qū)動的”，這個事實是它的一個主要缺點。實際專案很少按照該模型給出的順序進行；用戶常常難以清楚地給出所有需求；用戶必須有耐心，等到系統(tǒng)開發(fā)完成。（2）快速原型模型

(RapidPrototypeModel)在用戶不能給出完整、準確的需求說明，或者開發(fā)者不能確定演算法的有效性、操作系統(tǒng)的適應(yīng)性或人機交互的形式等許多情況下，可以根據(jù)用戶的一組基本需求，快速建造一個原型（可運行的軟體），然後進行評估，進一步精化、調(diào)整原型，使其滿足用戶的要求，也使開發(fā)者對將要做的事情有更好的理解。建造/修改原型

聽取用戶意見用戶測試運行原型原型實現(xiàn)範型快速原型模型快速原型法是一種新型的軟體開發(fā)方法，它使用交互的，快速建立起來的原型取代了形式的、僵硬的大量的規(guī)格說明，用戶通過在電腦上實際運行和試用原型系統(tǒng)而向開發(fā)者提供真實的回饋意見。建立原型系統(tǒng)修改原型符合用戶需要的應(yīng)用系統(tǒng)用戶試用回饋意見快速原型模型快速原型驗證規(guī)格說明驗證設(shè)計驗證編碼測試綜合測試維護變化的需求驗證維護過程開發(fā)過程採用不帶回饋的瀑布模型，進行快速開發(fā)和修改。原型系統(tǒng)提交用戶評測，反復(fù)修改，直到用戶滿意。原型模型存在的問題⑴為了使原型儘快的工作，沒有考慮軟體的總體品質(zhì)和長期的可維護性。⑵為了演示，可能採用不合適的操作系統(tǒng)、編程語言、效率低的演算法，這些不理想的選擇成了系統(tǒng)的組成部分。

⑶開發(fā)過程不便於管理。有效的使用原型模式建造原型僅是為了定義需求，之後就被拋棄（或被部分拋棄），實際的軟體在充分考慮了品質(zhì)和可維護性之後才被開發(fā)。3）增量模型(IncrementalModel)是一種漸進地開發(fā)逐步完善的軟體版本的模型。需求分析驗證規(guī)格說明驗證設(shè)計驗證維護針對每個構(gòu)件完成詳細設(shè)計、編碼和集成，經(jīng)測試後交付給用戶需求分析一步到位；功能模組作為增量逐步交付。增量模型分析分析分析分析設(shè)計設(shè)計設(shè)計設(shè)計編碼編碼編碼編碼測試測試測試測試增量1增量2增量3增量4交付交付交付交付●●●●●反復(fù)地應(yīng)用瀑布模型的基本成分和原型模型的迭代特徵，每一個線型過程產(chǎn)生一個“增量”的發(fā)佈或提交，該增量均是一個可運行的產(chǎn)品。早期的版本實現(xiàn)用戶的基本需求，並提供給用戶評估的平臺。需求作為增量逐步交付。增量模型的優(yōu)點在較短時間內(nèi)向用戶提交可完成部分工作的產(chǎn)品，並分批、逐步地向用戶提交產(chǎn)品。從第一個構(gòu)件交付之日起，用戶就能做一些有用的工作。整個軟體產(chǎn)品被分解成許多個增量構(gòu)件，開發(fā)人員可以一個構(gòu)件一個構(gòu)件地逐步開發(fā)。逐步增加產(chǎn)品功能可以使用戶有較充裕的時間學(xué)習(xí)和適應(yīng)新產(chǎn)品，從而減少一個全新的軟體可能給客戶組織帶來的衝擊。採用增量模型比採用瀑布模型和快速原型模型需要更精心的設(shè)計，但在設(shè)計階段多付出的勞動將在維護階段獲得回報。增量模型的困難在把每個新的增量構(gòu)件集成到現(xiàn)有軟體體系結(jié)構(gòu)中時，必須不破壞原來已經(jīng)開發(fā)出的產(chǎn)品。此外，必須把軟體的體系結(jié)構(gòu)設(shè)計得便於按這種方式進行擴充，向現(xiàn)有產(chǎn)品中加入新構(gòu)件的過程必須簡單、方便，也就是說，軟體體系結(jié)構(gòu)必須是開放的。開發(fā)人員既要把軟體系統(tǒng)看作整體。又要看成可獨立的構(gòu)件，產(chǎn)生觀念上的矛盾。多個構(gòu)件並行開發(fā)，具有集成的風(fēng)險。4）螺旋模型(SpiralModel)軟體風(fēng)險是任何軟體開發(fā)專案中都普遍存在的實際問題，專案越大，軟體越複雜，承擔(dān)該專案所冒的風(fēng)險也越大。

對於複雜的大型軟體，開發(fā)一個原型往往達不到要求。螺旋模型將瀑布模型和增量模型結(jié)合起來，加入了風(fēng)險分析。在該模型中，軟體開發(fā)是一系列的增量發(fā)佈，早期的迭代中，發(fā)佈的增量可能是一個紙上的模型或原型，在以後的迭代中，逐步產(chǎn)生系統(tǒng)更加完善的版本。螺旋模型的基本思想是降低風(fēng)險。簡單的螺旋模型快速原型驗證規(guī)格說明驗證設(shè)計驗證編碼測試綜合測試維護變化的需求驗證風(fēng)險分析風(fēng)險分析風(fēng)險分析風(fēng)險分析風(fēng)險分析風(fēng)險分析可看作在每個階段之前都增加了風(fēng)險分析過程的快速原型模型。每一個階段都可能存在不同的風(fēng)險！完整的螺旋模型原型版本當前進度

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

(ComponentIntegrationModel)

構(gòu)件（components)也稱為組件，是一段實現(xiàn)一系列有確定介面的程式體，具有自己的功能和邏輯，能同其他構(gòu)件集成起來協(xié)調(diào)工作。該模型（又稱為可重用部件組裝模型）支持軟體重用（Reusability）

，對縮短軟體開發(fā)週期、降低專案成本有重要的現(xiàn)實意義。同時，建造符合某應(yīng)用領(lǐng)域體系結(jié)構(gòu)標準的構(gòu)件，可以用來搭建分佈式的、跨越不同操作平臺(集成化軟體開發(fā)環(huán)境（ISEE）)的軟體，擴展了軟體的應(yīng)用前景，促進了軟體標準化、商品化的發(fā)展。在此基礎(chǔ)上專家們又提出了“基於構(gòu)件的軟體工程”(CBSE)。構(gòu)件集成模型

構(gòu)件集成模型軟體體系結(jié)構(gòu)被建立後，必須用構(gòu)件去充實，這些構(gòu)件可從複用庫中獲得，或者根據(jù)專門需要而開發(fā)。整個過程可以演化地進行，面向?qū)ο蠓椒ńo予技術(shù)上的支持。構(gòu)件集成模型Sommerville提出基於組件開發(fā)有兩種思路：完成高層設(shè)計，對設(shè)計中的組件給出描述，以便找出可複用的組件，這些組件可在體系結(jié)構(gòu)層次上加入或更詳細的設(shè)計層次上加入。先根據(jù)需求搜尋可複用組件，再將設(shè)計建立在獲得的組件基礎(chǔ)上。這兩種思路可結(jié)合起來。設(shè)計系統(tǒng)體系結(jié)構(gòu)描述組件搜尋可複用組件集成系統(tǒng)先完成架構(gòu)設(shè)計的複用系統(tǒng)需求描述搜尋可複用組件對需求作某些修改體系結(jié)構(gòu)設(shè)計集成系統(tǒng)複用驅(qū)動設(shè)計構(gòu)件技術(shù)主要有三種流行標準對象管理組織OMG的CORBA微軟的COM/DCOMSUN的EJB(EnterpriseJavaBean)OMG的CORBA對象管理組織OMG發(fā)佈的公用對象請求代理體系結(jié)構(gòu)(CommonObjectRequestBrokerArchitecture)。通過一個對象請求代理（ORB)提供一系列服務(wù)，使得一個構(gòu)件和其他構(gòu)件通信，而不管它們在系統(tǒng)中的位置，實現(xiàn)了遠程對象通過介面進行通信的機制。為了解決CORBA對象引用不透明、缺少多重介面、系統(tǒng)過於複雜等問題，專家們又開發(fā)了新一代面向?qū)ο笾虚g件平臺ICE（InternetCommunicationsEngine—互聯(lián)網(wǎng)通信引擎）。使構(gòu)建分佈式應(yīng)用系統(tǒng)更容易、性能和伸縮性更好。微軟的COM/DCOMCOM微軟提出、開發(fā)的構(gòu)件對象模型（ComponentObjectModel)，它提供了運行於windows之上的單個應(yīng)用系統(tǒng)使用不同廠商生產(chǎn)的構(gòu)件的規(guī)約。DOM基於分佈式環(huán)境下的COM稱為DCOM(DistributeCOM)。SUN的EJB(EnterpriseJavaBean)隨著Java在企業(yè)級應(yīng)用的地位日趨重要，Sun提出了一個統(tǒng)一的企業(yè)級Java平臺—J2EE（Java2EnterpriseEdition）。在J2EE中，EJB負責(zé)最核心的業(yè)務(wù)處理。它為伺服器端的應(yīng)用程式提供了一種與廠商無關(guān)的Java介面，讓任何符合EJB規(guī)範的構(gòu)件都可以運行在每一臺這樣的伺服器上。（6）統(tǒng)一軟體開發(fā)過程統(tǒng)一軟體開發(fā)過程（RationalUnifiedProcess，RUP)是由Rational公司的Booch、Jacobson、Rumbaugh提出的軟體過程模型。RUP重複一系列週期，每個週期由一個交付給用戶的產(chǎn)品結(jié)束。每個週期劃分為初始、細化、構(gòu)造和移交四個階段，每個階段圍繞著五個核心工作流（需求、分析、設(shè)計、實現(xiàn)、測試）分別迭代。RUP的“最佳實踐”軟體開發(fā)經(jīng)驗迭代式開發(fā)按照原型模型，迭代開發(fā)產(chǎn)品，獲取用戶的回饋意見，加深對需求的理解，逐步趨向最終產(chǎn)品。管理需求人為需求分析是一個連續(xù)過程，使用有效的方法（如用例和腳本）捕獲用戶變化的需求，以驅(qū)動設(shè)計與實現(xiàn)。使用基於構(gòu)建的體系結(jié)構(gòu)提供使用現(xiàn)有構(gòu)建和新開發(fā)構(gòu)件定義體系結(jié)構(gòu)的方法，採用構(gòu)建來建造系統(tǒng)，從而減低軟體複雜性，提供軟體重用率。可視化建模採用可視化建模語言（UML）描述系統(tǒng)模型。驗證軟體品質(zhì)建立貫穿整個開發(fā)過程的、全員參與的軟體品質(zhì)評估方法?？刂栖涹w變更控制、跟蹤和監(jiān)控軟體的修改，確保迭代開發(fā)的成功。RUP軟體開發(fā)生命週期RUP初始階段：進行問題定義，確定目標，評估其可行性，降低關(guān)鍵風(fēng)險。細化階段：制定專案計畫、配置各類資源、建立系統(tǒng)架構(gòu)（包括各類視圖）。構(gòu)造階段：開發(fā)整個產(chǎn)品，並確保產(chǎn)品可移交給用戶。移交階段：產(chǎn)品發(fā)佈、安裝、用戶培訓(xùn)。在每個階段的每次迭代的最後，用例模型、分析模型、設(shè)計模型、實現(xiàn)模型都會增量，每個階段結(jié)束的里程碑處，管理層做出是否繼續(xù)、進度、預(yù)算、是否給下一階段提供資助等決定。不同階段工作流的側(cè)重點不同，前兩階段大部分工作集中在需求、分析和架構(gòu)設(shè)計上；在構(gòu)造階段，重點轉(zhuǎn)移到詳細設(shè)計、實現(xiàn)和測試上。（7）敏捷過程與極限編程2001年，為了解決許多公司的軟體團隊陷入不斷增長的過程泥潭，一批業(yè)界著名專家一起概括出了一些可以讓軟體開發(fā)團隊具有快速工作、回應(yīng)變化能力的價值觀和原則，他們稱自己為敏捷聯(lián)盟。敏捷開發(fā)過程的方法很多，主要有：SCRUM，Crystal,特徵驅(qū)動軟體開發(fā)（FeatureDrivenDevelopment，簡稱FDD），自適應(yīng)軟體開發(fā)(AdaptiveSoftwareDevelopment，簡稱ASD)，以及最重要的極限編程(eXtremeProgramming,簡稱XP)。極限編程(XP)是於1998年由Smalltalk社群中的大師級人物KentBeck首先宣導(dǎo)的。觀點在按照我的理解方式審查了軟體開發(fā)的生命週期後，我得出一個結(jié)論：實際上滿足工程設(shè)計標準的惟一軟體文檔，就是源代碼清單。--JackReeves設(shè)計和編程都是人的活動。忘記這一點，將會失去一切。--BjarneStroustrup敏捷過程敏捷軟體開發(fā)宣言個體和交互 勝過 過程和工具可以工作的軟體 勝過 面面俱到的文檔客戶合作 勝過 合同談判回應(yīng)變化 勝過 遵循計畫敏捷宣言遵循的原則我們最優(yōu)先要做的是通過儘早的、持續(xù)的交付有價值的軟體來使客戶滿意。即使到了開發(fā)的後期，也歡迎改變需求。敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。經(jīng)常性地交付可以工作的軟體，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。在整個專案開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。圍繞被激勵起來的個體來構(gòu)建專案。給他們提供所需的環(huán)境和支持，並且信任他們能夠完成工作。在團隊內(nèi)部，最具有效果並富有效率的傳遞資訊的方法，就是面對面的交談。工作的軟體是首要的進度度量標準。敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。簡單是最根本的。最好的構(gòu)架、需求和設(shè)計出於自組織團隊。每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應(yīng)地對自己的行為進行調(diào)整。敏捷過程認為的軟體設(shè)計“壞味道”僵化性很難對系統(tǒng)進行改動，因為每個改動都會迫使許多對系統(tǒng)其他部分的其他改動。脆弱性對系統(tǒng)的改動會導(dǎo)致系統(tǒng)中和改動的地方在概念上無關(guān)的許多地方出現(xiàn)問題。牢固性很難解開系統(tǒng)的糾結(jié)，使之成為一些可在其他系統(tǒng)中重用的組件。粘滯性做正確的事情比做錯誤的事情要困難。不必要的複雜性設(shè)計中包含有不具任何直接好處的基礎(chǔ)結(jié)構(gòu)。不必要的重複性設(shè)計中包含有重複的結(jié)構(gòu)，而該重複的結(jié)構(gòu)本可以使用單一的抽象進行統(tǒng)一。晦澀性很難閱讀、理解。沒有很好地表現(xiàn)出意圖。敏捷開發(fā)避免“軟體腐化味”的

面向?qū)ο蟮脑O(shè)計原則單一職責(zé)原則(SRP)：一個類應(yīng)該僅有一個引起它變化的原因。開放-封閉原則(OCP)：軟體實體應(yīng)該是可以擴展的，但是不可修改。Liskov替換原則(LSP)：子類型必須能夠替換掉它們的基類型。依賴倒置原則(DIP)：抽象不應(yīng)該依賴於細節(jié)。細節(jié)應(yīng)該依賴於抽象。介面隔離原則(ISP)：不應(yīng)該強迫客戶依賴於它們不用的方法。介面屬於客戶，不屬於它所在的類層次結(jié)構(gòu)。重用發(fā)佈等價原則(REP)：重用的粒度就是發(fā)佈的粒度。共同封閉原則(CCP)：包中的所有類對於同一類性質(zhì)的變化應(yīng)該是共同封閉的。一個變化若對一個包產(chǎn)生影響，則將對該包中的所有類產(chǎn)生影響，而對於其他的包不造成任何影響。共同重用原則(CRP)：一個包中的所有類應(yīng)該是共同重用的。如果重用了包中的一個類，那麼就要重用包中的所有類。無環(huán)依賴原則(ADP)：在包的依賴關(guān)係圖中不允許存在環(huán)。穩(wěn)定依賴原則(SDP)：朝著穩(wěn)定的方向進行依賴。穩(wěn)定抽象原則(SAP)：包的抽象程度應(yīng)該和其穩(wěn)定程度一致。極限編程極限編程(eXtremeProgramming，XP)是敏捷過程中最有名的一個,適於小型專案。極限編程對於傳統(tǒng)的軟體工程中看來是“極端的”實踐.極限編程的有效實踐1、完整團隊XP專案的所有參與者（開發(fā)人員、客戶、測試人員等）一起工作在一個開放的場所中，他們是同一個團隊的成員。這個場所的牆壁上隨意懸掛著大幅的、顯著的圖表以及其他一些顯示他們進度的東西。2、計畫遊戲計畫是持續(xù)的、循序漸進的。每2周，開發(fā)人員就為下2周估算候選特性的成本，而客戶則根據(jù)成本和商務(wù)價值來選擇要實現(xiàn)的特性。3、客戶測試作為選擇每個所期望的特性的一部分，客戶可以根據(jù)腳本語言來定義出自動驗收測試來表明該特性可以工作。4、簡單設(shè)計團隊保持設(shè)計恰好和當前的系統(tǒng)功能相匹配。它通過了所有的測試，不包含任何重複，表達出了編寫者想表達的所有東西，並且包含盡可能少的代碼。5、結(jié)對編程所有的產(chǎn)品軟體都是由兩個程式員、並排坐在一起在同一臺機器上構(gòu)建的。6、測試驅(qū)動開發(fā)編寫單元測試是一個驗證行為，更是一個設(shè)計行為。同樣，它更是一種編寫文檔的行為。編寫單元測試避免了相當數(shù)量的回饋迴圈，尤其是功功能能驗證方面的回饋迴圈。程式員以非常短的迴圈週期工作，他們先增加一個失敗的測試，然後使之通過。極限編程的有效實踐7、改進設(shè)計隨時利用重構(gòu)方法改進已經(jīng)腐化的代碼，保持代碼盡可能的乾淨、具有表達力。8、持續(xù)集成團隊總是使系統(tǒng)完整地被集成。一個人拆入（Checkin）後，其他所有人責(zé)任代碼集成。9、集體代碼所有權(quán)任何結(jié)對的程式員都可以在任何時候改進任何代碼。沒有程式員對任何一個特定的模組或技術(shù)單獨負責(zé)，每個人都可以參與任何其他方面的開發(fā)。10、編碼標準系統(tǒng)中所有的代碼看起來就好像是被單獨一人編寫的。11、隱喻將整個系統(tǒng)聯(lián)繫在一起的全局視圖；它是系統(tǒng)的未來影像，是它使得所有單獨模組的位置和外觀變得明顯直觀。如果模組的外觀與整個隱喻不符，那麼你就知道該模組是錯誤的。12、可持續(xù)的速度團隊只有持久才有獲勝的希望。他們以能夠長期維持的速度努力工作，他們保存精力，他們把專案看作是馬拉松長跑，而不是全速短跑。XP專案的整體開發(fā)過程XP迭代開發(fā)過程XPvaluesCommunicationSimplicityFeedbackCourageRespect（8）微軟過程Microsoft解決方案框架(MSF)是一種成熟的、系統(tǒng)的技術(shù)專案方法，它基於一套制定好的原理、模型、準則、概念、指南，以及來自Microsoft的、經(jīng)過檢驗的做法。MSF提供了一個靈活的和可伸縮的框架，其適應(yīng)能力能夠滿足任何專案（不論其規(guī)模和複雜性）的要求，以規(guī)劃、構(gòu)建和部署業(yè)務(wù)驅(qū)動的技術(shù)解決方案。MSF的觀點是，沒有哪個單一的結(jié)構(gòu)或者過程能夠適應(yīng)所有專案的環(huán)境和要求。儘管如此，但是它也認為：對指導(dǎo)的需求是存在的。作為一個框架，MSF就提供了這樣一種指導(dǎo)，而不會強迫實施很多限制性的細節(jié)，否則這只會將其用處限制到有限範圍的專案方案裏。微軟軟體生命週期階段劃分和主要里程碑微軟過程的生命週期模型94/27內(nèi)容摘要基於電腦的系統(tǒng)系統(tǒng)工程的任務(wù)可行性分析95/27內(nèi)容摘要基於電腦的系統(tǒng)系統(tǒng)工程的任務(wù)可行性分析96/27

所謂基於電腦的系統(tǒng)是指：通過處理資訊來完成某些預(yù)定義目標而組織在一起的元素的集合或排列。組成基於電腦系統(tǒng)的元素主要有：軟體、硬體、人員、資料庫、文檔和規(guī)程（Procedure）基於電腦的系統(tǒng)97/27系統(tǒng)元素軟體—指電腦程式、數(shù)據(jù)結(jié)構(gòu)和相關(guān)的工作產(chǎn)品，以實現(xiàn)所需要的邏輯方法、規(guī)程或控制硬體—指提供計算能力的電子設(shè)備、支持數(shù)據(jù)流的互連設(shè)備（如網(wǎng)路交換器、電信設(shè)備）和提供外部世界功能的電子機械設(shè)備（如感測器、馬達等）人員—指硬體和軟體的用戶和操作者98/27資料庫—指通過軟體訪問並持久存儲的大型的有組織的資訊集合。文檔—指描繪系統(tǒng)的使用和/或操作的描述性資訊（如模型、規(guī)格說明、硬複製手冊、聯(lián)機幫助檔、Web站點）。規(guī)程（procedures）—指定義每個系統(tǒng)元素的特定使用或系統(tǒng)所處的過程性語境的步驟。99/27系統(tǒng)的層次結(jié)構(gòu)基於電腦的系統(tǒng)本身可以成為一個更大的基於電腦系統(tǒng)中的一個元素，稱其為那個更大系統(tǒng)的宏元素。這樣，基於電腦的系統(tǒng)可呈現(xiàn)一個層次結(jié)構(gòu)。100/27工廠自動化

系統(tǒng)101/27內(nèi)容摘要基於電腦的系統(tǒng)系統(tǒng)工程的任務(wù)可行性分析102/27電腦系統(tǒng)工程電腦系統(tǒng)工程是一個問題求解的活動，其目的是分析基於電腦的系統(tǒng)的功能、性能等要求，並把它們分配到基於電腦系統(tǒng)的各個系統(tǒng)元素中，確定它們的約束條件和介面。

103/27系統(tǒng)工程的任務(wù)識別用戶的要求標識系統(tǒng)的功能和性能範圍，確定系統(tǒng)的功能、性能、約束和介面。104/27系統(tǒng)建模和模擬通?？煽紤]建立如下模型：硬體系統(tǒng)模型：描述基於電腦系統(tǒng)中的硬體（包括電腦、受系統(tǒng)控制的其他硬體設(shè)備等）配置、通信協(xié)議、拓撲結(jié)構(gòu)、以及確?；峨娔X系統(tǒng)的安全性、可靠性、性能等要求的措施。軟體系統(tǒng)模型：描述各軟體子系統(tǒng)的功能、性能等要求，它們在硬體系統(tǒng)中的部署情況，以及軟體子系統(tǒng)之間的交互。人機介面模型：描述人如何與基於電腦的系統(tǒng)進行交互，包括用戶環(huán)境、用戶的活動、人機交互的語法和語義等。數(shù)據(jù)模型：描述基於電腦的系統(tǒng)使用了哪些資料庫管理系統(tǒng)，如果使用多個數(shù)據(jù)庫管理系統(tǒng)，還應(yīng)描述它們之間的數(shù)據(jù)轉(zhuǎn)換方式，必要時可給出主要的數(shù)據(jù)結(jié)構(gòu)。105/27系統(tǒng)模型通常可用圖形描述，並加以相應(yīng)的文字說明。必要時，在系統(tǒng)建模後可構(gòu)造原型，進行系統(tǒng)模擬，以分析所建的模型能否滿足整個基於電腦的系統(tǒng)的要求。106/27成本估算及進度安排對將開發(fā)的基於電腦的系統(tǒng)進行成本估算，並作出進度安排?？尚行苑治鰪慕?jīng)濟、技術(shù)、法律等方面分析所給出的解決方案是否可行，通常只有當解決方案可行並有一定的經(jīng)濟效益和/或社會效益時才開始真正的基於電腦的系統(tǒng)的開發(fā)。生成系統(tǒng)規(guī)格說明107/27內(nèi)容摘要基於電腦的系統(tǒng)系統(tǒng)工程的任務(wù)可行性分析108/27可行性分析開發(fā)一個基於電腦的系統(tǒng)通常都受到資源（人力、財力、設(shè)備等）和時間上的限制，可行性分析主要從經(jīng)濟、技術(shù)、法律等方面分析所給出的解決方案是否可行，能否在規(guī)定的資源和時間的約束下完成。109/27經(jīng)濟可行性分析經(jīng)濟可行性主要進行成本效益分析，從經(jīng)濟角度，確定系統(tǒng)是否值得開發(fā)?；峨娔X的系統(tǒng)的成本主要包括：購置硬體、軟體（如數(shù)據(jù)庫管理系統(tǒng)、第三方開發(fā)的構(gòu)件等）和設(shè)備（如感測器等）的費用系統(tǒng)的開發(fā)費用系統(tǒng)安裝、運行和維護費用人員培訓(xùn)費用110/27效益經(jīng)濟效益包括使用基於電腦的系統(tǒng)後可增加的收入和可節(jié)省的運行費用（如操作人員數(shù)、工作時間、消耗的物資等）。在進行成本效益分析時通常只統(tǒng)計五年內(nèi)的經(jīng)濟效益。社會效益指使用基於電腦的系統(tǒng)後對社會產(chǎn)生的影響（如提高了辦事效益，使用戶滿意等），通常社會效益只能定性地估計。經(jīng)濟效益通?？捎秘泿诺臅r間價值、投資回收期和純收入來度量。111/27貨幣的時間價值設(shè)：當前金額為P，年利率為i，n年後的金額為F，則計算時，累計經(jīng)濟效益應(yīng)折合成當前金額例如，一個基於電腦的系統(tǒng)使用後，每年產(chǎn)生的經(jīng)濟效益為10萬，如果年利率為5%，那麼，五年內(nèi)該系統(tǒng)的累計經(jīng)濟效益是43．2948萬，而不是50萬。112/27投資回收期：累計的經(jīng)濟效益正好等於投資數(shù)（成本）所需的時間。純收入：累計經(jīng)濟效益–

投資數(shù)當純收入大於零時，該工程值得投資開發(fā)當純收入小於零時，該工程不值得投資（除非它有明顯的社會效益）當純收入等於零時，通常也不值得投資顯然，純收入越大越好。113/27技術(shù)可行性分析技術(shù)可行性主要根據(jù)系統(tǒng)的功能、性能、約束條件等，分析在現(xiàn)有資源和技術(shù)條件下系統(tǒng)能否實現(xiàn)。技術(shù)可行性分析通常包括風(fēng)險分析、資源分析和技術(shù)分析。114/27風(fēng)險分析：分析在給定的約束條件下設(shè)計和實現(xiàn)系統(tǒng)的風(fēng)險。採用不成熟的技術(shù)可能造成技術(shù)風(fēng)險人員流動可能給專案帶來風(fēng)險成本和人員估算不合理造成的預(yù)算風(fēng)險風(fēng)險分析的目的是找出風(fēng)險，評價風(fēng)險的大小，並有效地控制和緩解風(fēng)險。115/27資源分析：論證是否具備系統(tǒng)開發(fā)所需的各類人員、軟體、硬體等資源和相應(yīng)的工作環(huán)境。例如，有一支開發(fā)過類似專案的開發(fā)和管理的團隊，或者開發(fā)人員比較熟悉系統(tǒng)所處的領(lǐng)域，並有足夠的人員保證，所需的硬體和支撐軟體能通過合法的手段獲取，那麼從技術(shù)角度看，可以認為具備設(shè)計和實現(xiàn)系統(tǒng)的條件。116/27技術(shù)分析：分析當前的科學(xué)技術(shù)是否支持系統(tǒng)開發(fā)的各項活動。在技術(shù)分析過程中，分析員收集系統(tǒng)的性能、可靠性、可維護性和生產(chǎn)率方面的資訊，分析實現(xiàn)系統(tǒng)功能、性能所需的技術(shù)、方法、演算法或過程，從技術(shù)角度分析可能存在的風(fēng)險，以及這些技術(shù)問題對成本的影響。技術(shù)可行性分析時通常需進行系統(tǒng)建模，必要時可建造原型和進行系統(tǒng)模擬117/27法律可行性分析研究系統(tǒng)開發(fā)過程中可能涉及到的合同、侵權(quán)、責(zé)任以及各種與法律相抵觸的問題。1990年我國頒佈了《中華人民共和國著作權(quán)法》，其中將電腦軟體作為著作權(quán)法的保護對象。1991年國務(wù)院頒佈了《電腦軟體保護條例》。這兩個法律檔是法律可行性分析的主要依據(jù)。118/27方案的選擇和折衷一個基於電腦的系統(tǒng)可以有多個可行的實現(xiàn)方案，每個方案對成本、時間、人員、技術(shù)、設(shè)備都有不同的要求，不同方案開發(fā)出來的系統(tǒng)在功能、性能方面也會有所不同。因此要在多個可行的實現(xiàn)方案中作出選擇。方案評估的依據(jù)是待開發(fā)系統(tǒng)的功能、性能、成本、開發(fā)時間、採用的技術(shù)、設(shè)備、風(fēng)險以及對開發(fā)人員的要求等。由於系統(tǒng)的功能和性能受到多種因素的影響，某些因素之間相互關(guān)聯(lián)和制約。如，為達到高的精度就可能導(dǎo)致長的執(zhí)行時間，為達到高可靠性就會導(dǎo)致高的成本等等。因此，在必要時應(yīng)進行折衷。119/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理120/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理121/42AlanDavis把需求工程定義為“直到（但不包括）把軟體分解為實際架構(gòu)構(gòu)件之前的所有活動”

HerbKrasner定義了需求工程的五階段生命週期：需求定義和分析、需求決策、形成需求規(guī)格、需求實現(xiàn)與驗證、需求演進管理MatthiasJarke和KlausPohl提出了三階段週期的說法：獲取、表示和驗證…

…122/42本書將軟體需求工程細分為：需求獲取、需求分析與協(xié)商、系統(tǒng)建模、需求規(guī)約、需求驗證和需求管理六個階段。123/42需求獲取系統(tǒng)分析人員通過與用戶的交流、對現(xiàn)有系統(tǒng)的觀察及對任務(wù)進行分析，確定系統(tǒng)或產(chǎn)品範圍的限制性描述、與系統(tǒng)或產(chǎn)品有關(guān)的人員及特徵列表、系統(tǒng)的技術(shù)環(huán)境的描述、系統(tǒng)功能的列表及應(yīng)用於每個需求的領(lǐng)域限制、一組描述不同運行條件下系統(tǒng)或產(chǎn)品使用狀況的應(yīng)用場景以及為更好地定義需求而開發(fā)的任意原型。需求獲取的工作產(chǎn)品為進行需求分析提供了基礎(chǔ)124/42需求分析與協(xié)商

需求獲取結(jié)束後，分析活動對需求進行分類組織，分析每個需求其他需求的關(guān)係來，檢查需求的一致性、重疊和遺漏的情況，並根據(jù)用戶的需要對需求進行排序。在需求獲取階段，經(jīng)常出現(xiàn)以下問題：用戶提出的要求超出軟體系統(tǒng)可以實現(xiàn)的範圍或?qū)崿F(xiàn)能力；不同的用戶提出了相互衝突的需求125/42系統(tǒng)建模

建模工具的使用在用戶和系統(tǒng)分析人員之間建立了統(tǒng)一的語言和理解的橋樑，同時系統(tǒng)分析人員借助建模技術(shù)對獲取的需求資訊進行分析，排除錯誤和彌補不足，確保需求文檔正確反映用戶的真實意圖。常用的分析和建模方法有面向數(shù)據(jù)流方法、面向數(shù)據(jù)結(jié)構(gòu)方法和麵向?qū)ο蟮姆椒ā?26/42需求規(guī)約軟體需求規(guī)約是分析任務(wù)的最終產(chǎn)物，通過建立完整的資訊描述、詳細的功能和行為描述、性能需求和設(shè)計約束的說明、合適的驗收標準，給出對目標軟體的各種需求。需求規(guī)約作為用戶和開發(fā)者之間的一個協(xié)議，在之後的軟體工程各個階段發(fā)揮重要作用。127/42需求驗證作為需求開發(fā)階段工作的復(fù)查手段，需求驗證對功能的正確性、完整性和清晰性，以及其他需求給予評價。為保證軟體需求定義的品質(zhì)，評審應(yīng)以專門指定的人員負責(zé)，並按規(guī)程嚴格進行。128/42在實際的開發(fā)過程中，獲取、分析、建模、編寫規(guī)約和驗證這些需求開發(fā)活動不會是線性地、順序地完成。實際上，這些活動是交叉的、遞增的和反復(fù)的。129/42需求管理需求工程包括獲取、分析、規(guī)定、驗證和管理軟體需求，而“軟體需求管理”則是對所有相關(guān)活動的規(guī)劃和控制。換句話說，需求管理就是：一種獲取、組織並記錄系統(tǒng)需求的系統(tǒng)化方案，以及一個使用戶與專案團隊對不斷變更的系統(tǒng)需求達成並保持一致的過程。130/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理131/42軟體需求包括功能需求性能需求用戶或人的因素環(huán)境需求介面需求文檔需求數(shù)據(jù)需求資源使用需求安全保密要求可靠性需求軟體成本消耗與開發(fā)進度需求其他非功能性要求

132/42需求獲取方法與策略建立順暢的通信途徑訪談與調(diào)查觀察用戶操作流程組成聯(lián)合小組用況（UseCase）133/42建立順暢的通信途徑建立分析所需要的通信途徑，以保證能順利地對問題進行分析。134/42訪談與調(diào)查在具體的實踐中，通常採用折衷的方法，即適當?shù)赜嫯嫼妹嬲?，但不要過於詳細，允許有一定的靈活性。一般按照如下原則進行準備：所提問的問題應(yīng)該循序漸進，從整體的方面開始提問，接下來的問題應(yīng)有助於對前面的問題更好的理解和細化；不要限制用戶對問題的回答，這有可能會引出原先沒有注意的問題；提問和回答在匯總後應(yīng)能夠反映用戶需求的全貌。135/42例子：“賽艇比賽成績計算系統(tǒng)”的第一次面談的準備計畫初次與Dartchurch航行俱樂部的航行秘書（DR）接觸，面談有關(guān)事宜。(在電話交談時，瞭解到他們希望得到的是一個“價廉”的，基於PC的系統(tǒng)，以用於計算賽艇比賽成績)時間：2005-6-5地點：對方場地主要問題確定基本問題。確定DR的角色――還涉及其他人員嗎？調(diào)查財物方面事宜。系統(tǒng)（大致上）是如何運作的？當前存在的問題是什麼？他們都希望做些什麼？136/42觀察用戶操作流程到用戶的實際工作環(huán)境中對用戶的工作流程進行觀察，瞭解用戶實際的操作環(huán)境、操作過程和操作要求，對照用戶提交的問題陳述，對用戶需求可以有更全面、更細緻的認識。137/42組成聯(lián)合小組便利的應(yīng)用規(guī)約技術(shù)(FacilitatedApplicationSpecificationTechniques,FAST)

：打破用戶（需方）和開發(fā)者（供方）的界限，共同組成一個聯(lián)合小組，發(fā)揮各自的長處，共同負責(zé)專案的推進，這樣有助於發(fā)揮各自優(yōu)勢並增進解和協(xié)調(diào)138/42FAST基本原則在中立的地點舉行由開發(fā)者和用戶出席的會議；建立準備和參與會議的規(guī)則；建議一個足夠正式的議程以便可以進行自由的交流；一個“協(xié)調(diào)者”(他可以是用戶、開發(fā)者或其他外人)來控制會議；使用一種“定義機制”(它可以是工作表、圖表、牆上膠黏紙或牆板)；目標是標識問題、提出解決方案的要素、商議不同的方法、以及在有利於完成目標的氛圍中刻畫出初步的需求。139/42FAST會議步驟1) 當舉行了開發(fā)者和用戶之間的初步訪談後，確定一個FAST會議的時間地點，並在會議日之前將產(chǎn)品請求發(fā)佈給所有的與會者。2) 要求每個FAST出席者會前列出一組圍繞系統(tǒng)環(huán)境的對象，以及對這些對象的操作或?qū)ο笾g的交互功能，並開發(fā)出約束列表(如，成本、規(guī)模大小、權(quán)重)和性能標準列表(如，速度、精度)。這些列表可以不是窮盡的，但是，希望每套列表反映的是每個人對系統(tǒng)的感覺。3) 進行FAST會議時，當團隊的每個成員提出單個列表後，整個團隊將創(chuàng)建一個組合的列表，該組合列表刪去冗餘項，並加入在表達過程中出現(xiàn)的新思想。在建好所有主題的組合列表後，開始討論活動。縮短、加長或重新組合列表以適當?shù)胤从硨⒈婚_發(fā)的產(chǎn)品。140/42FAST會議步驟(續(xù))4) 一旦創(chuàng)建了意見一致的列表，應(yīng)該將團隊分為更小的小組，每個小組力圖為每個列表中的一個或多個項開發(fā)出小型的規(guī)約（即對包含在列表中的單詞或短語的精細化）。每個小組然後將他們開發(fā)的每個小規(guī)約提交給所有的FAST出席者討論，進行添加、刪除或進一步的精化等工作。（在所有討論過程中，團隊可能提出某些不能在會議過程中解決的問題，此時要保留問題列表以使這些思想在以後的活動中產(chǎn)生作用。）5) 在小規(guī)約完成後，每個FAST的出席者提出一個針對產(chǎn)品的確切標準列表，並將該列表提交給團隊，然後創(chuàng)建一個意見一致的確定的標準列表。這個列表作為需求獲取的結(jié)果，為需求分析和建模提供基礎(chǔ)資訊。141/42用況（UseCase）當需求作為非正式會議、Fast的一部分而收集起來之後，分析員就可以創(chuàng)建一組標識一串待建造系統(tǒng)的使用場景。創(chuàng)建用況模型的主要步驟如下：確定誰會直接使用該系統(tǒng)，即參與者（Actor）選取其中一個參與者定義該參與者希望系統(tǒng)做什麼，參與者希望系統(tǒng)作的每件事將成為一個用況對每件事來說，何時參與者會使用系統(tǒng)，通常會發(fā)生什麼，這就是用況的基本過程描述該用況的基本過程142/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理143/42需求分析原則1．必須能夠表示和理解問題的資訊域2．必須能夠定義軟體將完成的功能3．必須能夠表示軟體的行為(作為外部事件的結(jié)果)4．必須劃分描述數(shù)據(jù)、功能和行為的模型，從而可以分層次地揭示細節(jié)5．分析過程應(yīng)該從要素資訊移向細節(jié)資訊144/42資訊域資訊域：包括資訊內(nèi)容、資訊流、以及資訊結(jié)構(gòu)。資訊內(nèi)容表示了單個數(shù)據(jù)和控制對象，目標軟體所有處理的資訊集合由它們構(gòu)成。例如，數(shù)據(jù)對象“工資”是一組重要數(shù)據(jù)體的組合：領(lǐng)款人的姓名、淨付款數(shù)、付款總額、扣除額等等145/42資訊流表示了數(shù)據(jù)和控制在系統(tǒng)中流動時的變化方式，輸入對象被變換為中間資訊(數(shù)據(jù)和/或控制)，然後進一步被變換為輸出資訊結(jié)構(gòu)表示了各種數(shù)據(jù)和控制項的內(nèi)部組織數(shù)據(jù)或控制項將被組織為n維表還是樹形結(jié)構(gòu)？在結(jié)構(gòu)的語境內(nèi)，什麼資訊是和其他資訊相關(guān)的？資訊包含在單個結(jié)構(gòu)中，還是使用不同的結(jié)構(gòu)？在某資訊結(jié)構(gòu)中的資訊如何和在另一個結(jié)構(gòu)中的資訊相關(guān)？146/42抽象、分解與多視點分析問題抽象方法要求分析人員在分析過程中捕捉用戶描述或問題本身固有的一般-特殊關(guān)係首先關(guān)注一般問題的解決途徑，進而指導(dǎo)特殊問題的解決方法。147/42問題分解的目的是要能以層次化的方式對問題進行分解和不斷細化。較大規(guī)?；蜉^為複雜的問題可以被分解為若干子問題進行理解和分析分解可以逐級進行，直至子問題被分解為一個容易分析理解的部分例如橫向分解縱向分解148/42需求協(xié)商協(xié)商的過程就是討論需求衝突，找出每個人都滿意的折衷方案協(xié)商不是簡單的邏輯或技術(shù)上的爭論要注意組織和行政方面的因素①不一致的目標②責(zé)任的喪失或轉(zhuǎn)移③組織文化④組織管理態(tài)度和士氣⑤部門差異149/42通常會議是解決衝突最快的方式參加者應(yīng)該包括發(fā)現(xiàn)衝突、遺漏或重疊的分析員，以及可以解決發(fā)現(xiàn)的問題的專案相關(guān)人員會議應(yīng)該討論那些非正式討論不能解決的問題通常會議分為三個階段：敘述階段討論階段決策階段150/42需求建模在軟體需求分析階段，所創(chuàng)建的模型，要著重於描述系統(tǒng)要做什麼，而不是如何去做目標軟體的模型不應(yīng)涉及軟體實現(xiàn)細節(jié)151/42常用的分析方法：面向數(shù)據(jù)流的結(jié)構(gòu)化分析方法(SA)面向數(shù)據(jù)結(jié)構(gòu)的分析方法面向?qū)ο蟮姆治龇椒?OOA)152/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理153/42需求規(guī)約的原則1． 從現(xiàn)實中分離功能，即描述要“做什麼”而不是“怎樣實現(xiàn)”。2． 要求使用面向處理的規(guī)約語言（或稱系統(tǒng)定義語言），討論來自環(huán)境的各種刺激可能導(dǎo)致系統(tǒng)做出什麼樣的功能性反應(yīng)，來定義一個行為模型，從而得到“做什麼”的規(guī)約。3． 如果被開發(fā)軟體只是一個基於電腦的系統(tǒng)中的一個元素，那麼整個大系統(tǒng)也包括在規(guī)格說明的描述之中。4． 規(guī)約必須包括系統(tǒng)運行環(huán)境。154/42需求規(guī)約的原則(續(xù))5． 規(guī)約必須是一個認識模型，而不是設(shè)計或?qū)崿F(xiàn)的模型。6． 規(guī)約必須是可操作的，以便能夠利用它決定對於任意給定的測試用例，已提出的解決方案是否都能滿足規(guī)約。7． 規(guī)約必須允許不完備性並允許擴充。8． 規(guī)約必須局部化和鬆散耦合。它所包括的資訊必須局部化，這樣當資訊被修改時，只要修改某個單個的段落（理想情況）。同時，規(guī)約應(yīng)被鬆散地構(gòu)造（即松耦合），以便能夠很容易地加入和刪去一些段落。155/42需求規(guī)約Ⅰ.引言A.系統(tǒng)參考文獻B.整體描述C.軟體專案約束Ⅱ.資訊描述A.資訊內(nèi)容表示B.資訊流表示：ⅰ數(shù)據(jù)流ⅱ控制流Ⅲ.功能描述A.功能劃分B.功能描述：ⅰ處理說明ⅱ限制∕局限ⅲ性能需求ⅳ設(shè)計約束ⅴ支撐圖C.控制描述ⅰ控制規(guī)約ⅱ設(shè)計約束Ⅳ.行為描述A.系統(tǒng)狀態(tài)B.事件和回應(yīng)Ⅴ.檢驗標準A.性能範圍B.測試種類C.期望的軟體回應(yīng)D.特殊的考慮Ⅵ.參考書目Ⅶ.附錄156/42引言：陳述軟體目標，在基於電腦的系統(tǒng)語境內(nèi)進行描述。資訊描述：給出軟體必須解決問題的詳細描述，記錄資訊內(nèi)容和關(guān)係、流和結(jié)構(gòu)。功能描述：描述解決問題所需的每個功能。其中包括，為每個功能說明一個處理過程；敘述設(shè)計約束；敘述性能特徵；用一個或多個圖形來形象地表示軟體的整體結(jié)構(gòu)和軟體功能與其他系統(tǒng)元素間的相互影響。行為描述：描述作為外部事件和內(nèi)部產(chǎn)生的控制特徵的軟體操作。檢驗標準：描述檢驗系統(tǒng)成功的標誌。即對系統(tǒng)進行什麼樣的測試，得到什麼樣的結(jié)果，就表示系統(tǒng)已經(jīng)成功實現(xiàn)了。它是“確認測試”的基礎(chǔ)。參考書目：包含了對所有和該軟體相關(guān)的文檔的引用，其中包括其他的軟體工程文檔、技術(shù)參考文獻、廠商文獻以及標準。附錄：包含了規(guī)約的補充資訊，表格數(shù)據(jù)、演算法的詳細描述、圖表以及其他材料。157/42需求驗證需求驗證目的是要檢驗需求是否能夠反映用戶的意願評審人員評審時往往需要檢查以下內(nèi)容：系統(tǒng)定義的目標是否與用戶的要求一致；系統(tǒng)需求分析階段提供的文檔資料是否齊全；文檔中的描述是否完整、清晰、準確地反映了用戶要求；被開發(fā)專案的數(shù)據(jù)流與數(shù)據(jù)結(jié)構(gòu)是否確定且充足；主要功能是否已包括在規(guī)定的軟體範圍之內(nèi)，是否都已充分說明；設(shè)計的約束條件或限制條件是否符合實際；開發(fā)的技術(shù)風(fēng)險是什麼；是否詳細制定了檢驗標準，它們能否對系統(tǒng)定義是否成功進行確認。

158/42內(nèi)容摘要需求工程概述需求獲取需求分析、協(xié)商與建模需求規(guī)約與驗證需求管理第4章形式化說明技術(shù)4.1 概述4.2 有窮狀態(tài)機4.3 Petri網(wǎng)4.4 Z語言4.5 小結(jié)4.1 概述4.1.1非形式化方法的缺點非形式化是指用自然語言描述軟體需求（如系統(tǒng)規(guī)格說明書）。因此，可能存在矛盾性、二義性、含糊性、不完整性、抽象層次混亂等問題。4.1.2形式化方法的優(yōu)點形式化方法是指在軟體工程中引入數(shù)學(xué)方法和模型。利用數(shù)序的簡潔性、嚴謹性、科學(xué)性，克服非形式化方法的缺點。4.1.3應(yīng)用形式化方法的準則“軟體需求”是軟體產(chǎn)品的高層、概念模型，而“形式化方法”是嚴謹、科學(xué)的數(shù)學(xué)方法，因此，在形式化方法的應(yīng)用方面應(yīng)考慮適度性、實用性、實用性。常用的形式化方法較嚴格的形式化方法（語法和語義都嚴謹）：有窮狀態(tài)機、Petri網(wǎng)、Z語言………半形式化方法（語法和語義都不太嚴謹）：系統(tǒng)流程圖、數(shù)據(jù)流圖、數(shù)據(jù)字典、ER圖、資料庫範式、狀態(tài)轉(zhuǎn)換圖、層次方框圖、Warnier圖、IPO圖、IPO表………4.1.1非形式化方法的缺點矛盾性在需求規(guī)格說明書（ReqirementSpecifications）中對同一問題前後存在不同的描述。二義性需求規(guī)格說明書的讀者對其中同一問題的描述存在不同的理解。含糊性需求規(guī)格說明書中對某一問題的描述不清晰、不可理解、不知如何實現(xiàn)、不具可操作性。不完整性需求規(guī)格說明書中對某一問題的描述不完整。只說明了局部，沒有說明整體；或者只說明了概要，未說明細節(jié)。因此不具可操作性。抽象層次混亂在不同層次的抽象模型中內(nèi)容混亂，如在高層模型中混有底層細節(jié)，造成讀者不能理解系統(tǒng)的整體功能和下級功能。4.1.2形式化方法的優(yōu)點可嚴謹?shù)孛枋鲕涹w需求中的問題可簡介、準確描述物理現(xiàn)象、對象或動作的結(jié)果問題；適用於描述詳細的需求規(guī)格；可用數(shù)學(xué)方法驗證需求。可在軟體工程不同階段平滑過渡從需求、到設(shè)計、到實現(xiàn)都基於同一系統(tǒng)模型，平滑過渡?？商峁└邔哟_認手段可用數(shù)學(xué)方法證明軟體工程各階段的正確性（可回溯性），如“設(shè)計”符合“規(guī)格說明”、“編碼實現(xiàn)”符合“設(shè)計”。形式化方法的適用性問題形式化方法能較好地解決需求的“二義性”、“含糊性”問題。但不能解決需求的矛盾性、完整性等問題，這些問題涉及工程管理。4.1.3應(yīng)用形式化方法的準則應(yīng)該選用適當?shù)囊?guī)格說明表示方法應(yīng)該採用形式化，但不要過分形式化應(yīng)該估算推行形式化的成本應(yīng)該引入形式化方法的顧問與諮詢應(yīng)該結(jié)合傳統(tǒng)的、證明有效的開發(fā)方法應(yīng)該在採用形式化的同時，建立詳盡的文檔應(yīng)該堅持品質(zhì)保障活動應(yīng)該不總是盲目依賴形式化方法應(yīng)該重視測試應(yīng)該重視重用4.2 有窮狀態(tài)機4.2.1 有窮狀態(tài)機概念4.2.2 有窮狀態(tài)機例子4.2.3 有窮狀態(tài)機方法評價4.2.1 有窮狀態(tài)機概念通過簡單例子引入有窮狀態(tài)機的基本概念：一個保險箱上裝了一個複合鎖，鎖有三個位置，分別標記為1、2、3，轉(zhuǎn)盤可向左(L)或向右(R)轉(zhuǎn)動。這樣，在任意時刻轉(zhuǎn)盤都有6種可能的運動，即1L、1R、2L、2R、3L和3R。保險箱的組合密碼是1L、3R、2L，轉(zhuǎn)盤的任何其他運動都將引起報警。引例——保險箱的狀態(tài)轉(zhuǎn)換圖4.1保險箱的狀態(tài)轉(zhuǎn)換圖

引例——保險箱的狀態(tài)轉(zhuǎn)換有窮狀態(tài)機——概念一個有窮狀態(tài)機包括下述5個部分：狀態(tài)集J、輸入集K、由當前狀態(tài)和當前輸入確定下一個狀態(tài)(次態(tài))的轉(zhuǎn)換函數(shù)T、初始態(tài)S和終態(tài)集F。狀態(tài)集J：有所有可能的狀態(tài)構(gòu)成的有窮集合；輸入集K：引發(fā)狀態(tài)變換的可能的外部輸入（或操作）；轉(zhuǎn)換函數(shù)T：由當前狀態(tài)和當前輸入變換到下一個狀態(tài)(次態(tài))的函數(shù)（或規(guī)則）；初始態(tài)S∈J，狀態(tài)機的初始狀態(tài)；終態(tài)集F∪J，狀態(tài)機的終止狀態(tài)集；引例——保險箱的有窮狀態(tài)機狀態(tài)集J：｛保險箱鎖定，A，B，保險箱解鎖，報警｝。輸入集K：｛1L，1R，2L，2R，3L，3R｝。轉(zhuǎn)換函數(shù)T：見“狀態(tài)轉(zhuǎn)換表”初始態(tài)S：保險箱鎖定終態(tài)集F：｛保險箱解鎖，報警｝有窮狀態(tài)機——形式化表示一個有窮狀態(tài)機可以表示為一個5元組(J，K，T，S，F(xiàn))，其中：J是一個有窮的非空狀態(tài)集；K是一個有窮的非空輸入集；T是一個從(J-F)×K到J的轉(zhuǎn)換函數(shù)；S∈J，是一個初始狀態(tài)；F∪J，是終態(tài)集。擴展的有窮狀態(tài)機——增加謂詞集一個有窮狀態(tài)機可以表示為一個6元組(J,K,P,T,S,F)，其中：J是一個有窮的非空狀態(tài)集；K是一個有窮的非空輸入集；P是一個有窮的非空謂詞集(條件函數(shù)集合)；T是一個從(J-F)×K×P到J的轉(zhuǎn)換函數(shù)；S∈J，是一個初始狀態(tài)；F∪J，是終態(tài)集。4.2.2 有窮狀態(tài)機例子-電梯