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