【文章內(nèi)容簡介】 3。玻姆于1988年正式發(fā)表了軟件系統(tǒng)開發(fā)的“螺旋模型”，它是將瀑布模型與演化模型相結(jié)合，并且增加了兩者所忽略的風(fēng)險分析，彌補了兩者的不足之處，該模型通常用來指導(dǎo)大型軟件項目的開發(fā)軟件項目的開發(fā)。軟件風(fēng)險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復(fù)雜，承擔(dān)該項目所冒的風(fēng)險也越大。軟件風(fēng)險駕馭的目標主要是在造成危害之前及時對風(fēng)險進行識別，分析，采取對策進而消除或者減少風(fēng)險的損害。螺旋模型將開發(fā)劃分為制訂計劃，風(fēng)險分析，實施工程，客戶評估四類活動。沿著螺旋線每旋轉(zhuǎn)一圈，表示開發(fā)出一個更完善的新的軟件版本，如果開發(fā)風(fēng)險過大，開發(fā)機構(gòu)和客戶無法接受，項目就有可能就此終止。多數(shù)情況下，會沿著螺旋線繼續(xù)下去，自內(nèi)向外逐步延伸，最終得到滿意產(chǎn)品。螺旋模型開發(fā)的成敗很大程度上依賴于風(fēng)險評估的成敗。沿著螺旋線旋轉(zhuǎn)，在笛卡爾坐標的四個象限上分別表達了四類活動：制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件。風(fēng)險分析：分析所選方案，考慮如何識別和消除風(fēng)險。實施工程：實施軟件開發(fā)。客戶評估：評價軟件功能和性能，提出修改建議。 螺旋模型的優(yōu)點：設(shè)計上的靈活性,可以在項目的各個階段進行變更；以小的分段來構(gòu)建大型系統(tǒng),使成本計算變得簡單容易；客戶始終參與每個階段的開發(fā),保證了項目不偏離正確方向以及項目的可控性；隨著項目推進,客戶始終掌握項目的最新信，從而他或她能夠和管理層有效地交互；客戶認可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。螺旋模型的缺點：很難讓用戶確信這種演化方法的結(jié)果是可以控制的；建設(shè)周期長，而軟件技術(shù)發(fā)展比較快，所以經(jīng)常出現(xiàn)軟件開發(fā)完畢后，和當前的技術(shù)水平有了較大的差距，無法滿足當前用戶需求。 （三）面向?qū)ο蟮膰娙Ｐ驮诿嫦驅(qū)ο蟮姆椒ㄖ?，提出了于瀑布模型相對?yīng)的噴泉模型，該模型的主要特點是認為軟件生命周期的各個階段是相互重疊和多次反復(fù)的，它是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計活動，設(shè)計活動結(jié)束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。其優(yōu)點是可以提高軟件項目開發(fā)效率，節(jié)省開發(fā)時間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。噴泉一詞本身就體現(xiàn)了迭代和無間隙的特性。噴泉模型的優(yōu)點：軟件項目開發(fā)效率高，節(jié)省開發(fā)時間，適應(yīng)于面向?qū)ο蟮能浖_發(fā)過程。噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計活動，設(shè)計活動結(jié)束后才開始編碼活動。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。噴泉模型的缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。此外這種模型要求嚴格管理文檔，使得審核的難度加大，尤其是面對可能隨時加入各種信息、需求與資料的情況。形式化方法模型包含了一組活動，他們導(dǎo)致了計算機軟件的數(shù)學(xué)規(guī)約。形式化方法使得軟件工程師們能夠通過應(yīng)用一個嚴格的數(shù)學(xué)符號體系來規(guī)約、開發(fā)、和驗證基于計算機的系統(tǒng)。在開發(fā)中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟件過程模型難以克服的很多問題。二義性、不完整性、不一致性能被更容易地發(fā)現(xiàn)和糾正，而不是通過專門的評審，是通過對應(yīng)用的數(shù)學(xué)分析。 形式化方法提供了可以產(chǎn)生無缺陷軟件的承諾。UML（Unified Modeling Language）統(tǒng)一建模語言,是用來對軟件密集型系統(tǒng)進行可視化建模的一種通用語言。UML被廣泛應(yīng)用于數(shù)據(jù)建模，業(yè)務(wù)建模，對象建模，組件建模等。UML與具體的程序設(shè)計語言無關(guān)，它只是一種建模語言而不是一種方法學(xué)，和其它的計算機語言一樣，也是由基本詞匯和語法兩個部分構(gòu)成。UML定義了一些建立模型、表達某種特定含義所需要的基本元素，這些元素稱為元模型，相當于語言中的基本詞匯，例如用例、類等。在此基礎(chǔ)上，還定義了這些元模型互相之間關(guān)系的規(guī)則，以及如何用這些元素和規(guī)則繪制圖形以建立模型來映射現(xiàn)實世界，這些規(guī)則和圖形稱為UML模型表示法或圖示。UML正處于不斷演化和完善過程之中，最初的UML標準只是作為一種面向?qū)ο筝o助的工具而設(shè)計的，即為軟件的設(shè)計意圖提供一種非形式化的捕獲和表達手段和工具。因此，早期UML版本中存在著的一些因UML工具廠商不同而引入的分歧和模糊定義，正隨著UML標準的演化而被逐步消除，讓其向著成為一種形式化建模語言規(guī)范的方向不斷演化。與此同時，UML也正在變得越來越龐大，但當我們只是運用UML來進行面向?qū)ο笤O(shè)計時，并不需要用到所有的UML內(nèi)容，而是可以學(xué)習(xí)和使用UML那些最適合的部分。用例圖用例圖用來描述軟件需求模型中的系統(tǒng)功能，通過一組用例可以描述軟件系統(tǒng)能夠給用戶提供的功能。用例圖可以作為整個系統(tǒng)開發(fā)過程中的開發(fā)依據(jù)，指導(dǎo)和驅(qū)動其他模型。類圖類圖(Class Diagram)是由類、相關(guān)建模元素及其關(guān)系構(gòu)成的圖，用來描述類之間的靜態(tài)關(guān)系。類圖在系統(tǒng)中處在核心位，也是UML中最為重要的一種圖。在系統(tǒng)的不同開發(fā)階段，類圖可以具有不同的抽象程度。隨著開發(fā)的深入，類圖應(yīng)該越來越詳細、具體。類圖可以分為：界面類、控制類和實體類。界面類位于系統(tǒng)與外界的交界處，承擔(dān)系統(tǒng)與外界的信息功能。界面類處在用例圖中參與者與用例的關(guān)聯(lián)處，可以根據(jù)用例圖發(fā)現(xiàn)界面類。在界面類的設(shè)計中主要關(guān)注屬性和消息方法；控制類承擔(dān)著事務(wù)處理，控制調(diào)控的控制作用。一個用例中最少會有一個控制類，用來控制用例中的事件順序，也可以在多個用例之間協(xié)調(diào)用例之間的聯(lián)系。在控制類的設(shè)計中主要關(guān)注類的方法。實體類對應(yīng)著現(xiàn)實中的客觀實物，用來保存信息，一般對應(yīng)著數(shù)據(jù)表、文件等。在實體類的設(shè)計中主要關(guān)注類的屬性；交互圖交互圖 用來描述對象之間,以及對象與參與者之間的動態(tài)協(xié)作關(guān)系以及協(xié)作過程中行為次序的圖形文檔。交互圖的類型包含順序圖和協(xié)作圖，其作用是分析為了實現(xiàn)一個用例的功能所參與的對象，以及這些對象相互之間的動態(tài)消息聯(lián)系?；顒訄D活動圖是UML的動態(tài)視圖之一，用來描述事物或?qū)ο蟮幕顒幼兓鞒??；顒訄D可以用來：描述工作流或者業(yè)務(wù)流程；描述工程組織過程；描述算法流程。關(guān)系數(shù)據(jù)庫中的關(guān)系必須滿足一定的要求，即滿足不同的范式。目前關(guān)系數(shù)據(jù)庫有六種范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎(chǔ)上進一步滿足更多要求的稱為第二范式（2NF），其余范式以次類推。一般說來，數(shù)據(jù)庫只需滿足第三范式（3NF）就行了。第一范式（1NF）。所謂第一范式（1NF）是指數(shù)據(jù)庫表的每一列都是不可分割的基本數(shù)據(jù)項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復(fù)的屬性。如果出現(xiàn)重復(fù)的屬性，就可能需要定義一個新的實體，新的實體由重復(fù)的屬性構(gòu)成，新實體與原實體之間為一對多關(guān)系。在第一范式（1NF）中表的每一行只包含一個實例的信息。簡而言之，第一范式就是無重復(fù)的列。第二范式（2NF）。第二范式（2NF）是在第一范式（1NF）的基礎(chǔ)上建立起來的，即滿足第二范式（2NF）必須先滿足第一范式（1NF）。第二范式（2NF）要求數(shù)據(jù)庫表中的每個實例或行必須可以被唯一地區(qū)分。為實現(xiàn)區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識。第二范式（2NF）要求實體的屬性完全依賴于主關(guān)鍵字。所謂完全依賴是指不能存在僅依賴主關(guān)鍵字一部分的屬性，如果存在，那么這個屬性和主關(guān)鍵字的這一部分應(yīng)該分離出來形成一個新的實體，新實體與原實體之間是一對多的關(guān)系。為實現(xiàn)區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二范式就是屬性完全依賴于主鍵。第三范式（3NF）。滿足第三范式（3NF）必須先滿足第二范式（2NF）。簡而言之，第三范式（3NF）要求一個數(shù)據(jù)庫表中不包含已在其它表中已包含的非主關(guān)鍵字信息。簡而言之，第三范式就是屬性不依賴于其它非主屬性。因為數(shù)據(jù)模型的內(nèi)容是問題域和解域所共享的知識模型，所以可以用問題域的語言來描述它，也可以用解域的語言來描述它，還可以用介于二者之間的語言來描述，故產(chǎn)生了以下三種常用的數(shù)據(jù)模型：概念數(shù)據(jù)模型。它反映了人們對現(xiàn)實世界的認知與理解，是從現(xiàn)實世界到人類大腦的映射。故它以問題域的語言解釋數(shù)據(jù)模型，由一系列應(yīng)用領(lǐng)域的概念組成。物理數(shù)據(jù)模型。它是以解域的語言解釋數(shù)據(jù)模型，是面向計算機物理表示的模型，描述了數(shù)據(jù)在儲存介質(zhì)上的組織結(jié)構(gòu)，它不但與具體的DBMS有關(guān)，而且還與操作系統(tǒng)和硬件有關(guān)。每一種邏輯數(shù)據(jù)模型在實現(xiàn)時都有起對應(yīng)的物理數(shù)據(jù)模型。邏輯數(shù)據(jù)模型。這是用戶從數(shù)據(jù)庫所看到的模型，是具體的DBMS所支持的數(shù)據(jù)模型，如網(wǎng)狀數(shù)據(jù)模型(Network Data Model)、層次數(shù)據(jù)模型(Hierarchical Data Model)等等。此模型既要面向用戶，又要面向系統(tǒng)，主要用于數(shù)據(jù)庫管理系統(tǒng)（DBMS）的實現(xiàn)。本章結(jié)合白碗窯鎮(zhèn)政府的實際情況，對樂山鎮(zhèn)政府車輛管理系統(tǒng)的設(shè)計采用的開發(fā)技術(shù)進行介紹， ，MFC微軟基礎(chǔ)類、面向?qū)ο蟮木幊陶Z言C，以及所使用的開發(fā)工具Microsoft Visual studio 2010和SQL Server2010.第三章 系統(tǒng)需求分析本章首先對白窯鎮(zhèn)鎮(zhèn)政府現(xiàn)有的車輛管理方法進行了分析，介紹了現(xiàn)有管理的不足和改進之處。然后對系統(tǒng)的整個框架做出了需求分析。最后對系統(tǒng)中車輛管理的每個詳細步驟進行了分析，并畫出了流程圖。軟件的需求分析指的是分析調(diào)研各種用戶在功能、性能、設(shè)計、行為約束等方面對將要實現(xiàn)的軟件系統(tǒng)的期望。在軟件生存周期中，軟件需求分析是非常重要的一步，同時也是決定性的一步。需求分析的好壞將直接影響到軟件系統(tǒng)的使用性。如果沒有做好需求分析，而只是憑空想象用戶可能需求是什么，這樣是不可行的，最終得到的產(chǎn)品也肯定達不到用戶的要求。我們只有做好了前期的需求分析，才能夠?qū)④浖目傮w概念以及功能和性能描述為具體需求的規(guī)格說明，才可以奠定軟件的開發(fā)基礎(chǔ)。對本系統(tǒng)來說，我們要實現(xiàn)一個白窯鎮(zhèn)鎮(zhèn)政府內(nèi)部的車輛管理系統(tǒng)，我們需要結(jié)合白窯鎮(zhèn)鎮(zhèn)政府的實際情況調(diào)研各種部門不同用戶的需求以及相關(guān)政策，包括普通員工的需求，部門領(lǐng)導(dǎo)的需求、白窯鎮(zhèn)鎮(zhèn)政府現(xiàn)存的車輛方法以及員工對現(xiàn)有管理方法的態(tài)度、意見及存在的問題等。車輛系統(tǒng)要切實全面的考慮到各級員工的需求，因為各級員工對車輛的使用情況和需求情況可能不同。同時在進行需求分析時，也需要考慮到部門領(lǐng)導(dǎo)或者單位領(lǐng)導(dǎo)的要求，因為車輛管理的最終的目的是要提高工作效率，從而最終提升整個白窯鎮(zhèn)鎮(zhèn)政府的工作效益。通過詳細的需求分析，我們可以弄清系統(tǒng)的工作原理，弄清系統(tǒng)的整體框架，確定其主要功能。首先我們要調(diào)查系統(tǒng)的使用者。系統(tǒng)的使用者中最主要的就是系統(tǒng)管理員，系統(tǒng)管理員不但要安排車輛的分配，還要維護系統(tǒng)的運行。所以系統(tǒng)管理員是最主要的調(diào)研對象。其次我們要調(diào)研系統(tǒng)中的車輛申請者，車輛申請者分布在白窯鎮(zhèn)鎮(zhèn)政府內(nèi)各個部門，需要進行詳盡的調(diào)研。然后要對車輛審批人員進行調(diào)研。最后還要對車輛的維修人員和車輛的保養(yǎng)人員進行調(diào)研。通過對各類使用者的調(diào)研和細致的分析，我們可以清楚地知道各類使用者在系統(tǒng)中的角色和系統(tǒng)需求，為后面系統(tǒng)的設(shè)計詳細打下基礎(chǔ)。 業(yè)務(wù)需求（Business requirement）表示組織或客戶高層次的目標。業(yè)務(wù)需求通常來自項目投資人、購買產(chǎn)品的客戶、實際用戶的管理者、市場營銷部門或產(chǎn)品策劃部門。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。使用前景和范圍（vision and scope）文檔來記錄業(yè)務(wù)需求，這份文檔有時也被稱作項目輪廓圖或市場需求（project charter 或 market requirement）文檔。白碗窯鎮(zhèn)政府公務(wù)用車管理系統(tǒng)的主要有車輛狀態(tài)管理模塊、車輛費用管理模塊、車輛檔案管理模塊三個模塊構(gòu)成，每個模塊的功能如下：（一）車輛狀態(tài)管理模塊中的功能有車輛狀態(tài)信息查詢、車輛狀態(tài)信息推遲、車輛信息提醒。（二）車輛費用管理模塊中的功能有費用錄入，費用查詢、費用修改、費用統(tǒng)計，生成報表。（三）車輛檔案管理模塊中的功能有檔案錄入，檔案查詢、檔案修改、檔案統(tǒng)計。（四）具有配套的系統(tǒng)后臺管理維護功能，能夠?qū)ο到y(tǒng)數(shù)據(jù)庫信息進行管理與維護。（五）響應(yīng)速度合理，安全性較高。（六）系統(tǒng)運行穩(wěn)定，并且應(yīng)易于維護。（一）車輛狀態(tài)管理模塊流程圖圖31 車輛狀態(tài)管理模塊流程圖（二）車輛費用管理模塊流程圖圖32 車輛費用管理模塊流程圖（三）車輛檔案管理模塊流程圖圖33 車輛檔案管理模塊流程圖功能需求（functional requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。功能需求有時也被稱作行為需求（behavīoral requirement），因為習(xí)慣上總是用“應(yīng)該”對其進行描述：“系統(tǒng)應(yīng)該發(fā)送電子郵件來通知用戶已接受其預(yù)定”。功能需求描述是開發(fā)人員需要實現(xiàn)什么。以下從白碗鎮(zhèn)政府公務(wù)用車管理系統(tǒng)的實際需求分析，系統(tǒng)涉及到以下角色：角色職責(zé)或功能租車人系統(tǒng)主要參與者， 對公務(wù)車使用者，并支付用車費用。物業(yè)管理人員系統(tǒng)主要參與者，對公務(wù)車進行狀態(tài)管理，費用管理和檔案管理。系統(tǒng)管理員管理和維護整個系統(tǒng)，對系統(tǒng)出現(xiàn)的異常情況進行處理。在結(jié)構(gòu)分析方法中，通常采用數(shù)據(jù)流圖(DDF)和數(shù)據(jù)字典(DD)工具。其中，數(shù)據(jù)流圖是描述數(shù)據(jù)處理過程的工具。數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫系統(tǒng)邏輯模型及信息從輸入到輸出的移動變換過程。它是一種非常好的工具，一般把功能級數(shù)據(jù)流圖細化后得到的數(shù)據(jù)流圖很復(fù)雜，可以采用數(shù)據(jù)流圖分層表示，用劃分圖的方法把一個主要功能都細化成為一張數(shù)據(jù)流分圖。畫數(shù)據(jù)流圖的基本步驟概括的說，就是自外向里、自頂鄉(xiāng)下、逐層細化、完善求精。以下從業(yè)