【正文】 加工名：系統(tǒng)盈利統(tǒng)計加工編號：簡要描述：對系統(tǒng)的周、月、季度以及年的盈利費用進行統(tǒng)計輸入數(shù)據(jù)流：統(tǒng)計條件輸出數(shù)據(jù)流：統(tǒng)計信息加工邏輯：在費用記錄中，統(tǒng)計一周，一個月，一個季度甚至一年的盈利費，并在前臺顯示盈利狀況根據(jù)數(shù)據(jù)流圖我們可以看出，該功能由用車人開始，結(jié)束于費用記錄，其中物業(yè)管理人員和用車人為操作實體。同時該模塊還涉及“車輛狀態(tài)信息記錄”一個數(shù)據(jù)存儲文件。車輛狀態(tài)信息管理過程即是用戶對所用的車輛的使用狀態(tài)進行管理的過程。圖36 車輛管理狀態(tài)數(shù)據(jù)流圖車輛管理狀態(tài)模塊加工和終點描述：表38 終點“車輛狀態(tài)信息記錄”詞條描述終點名稱：車輛狀態(tài)信息記錄別名：無簡述：記錄車輛狀態(tài)的文件數(shù)據(jù)流：車輛狀態(tài)信息表39 加工“車輛狀態(tài)信息查詢”詞條描述加工名：車輛狀態(tài)信息查詢加工編號：簡要描述：獲取用戶正在使用的車的狀態(tài)信息輸入數(shù)據(jù)流：查詢條件輸出數(shù)據(jù)流：用車信息加工邏輯：從狀態(tài)信息記錄中，獲取用戶所用車的狀態(tài)信息集合表310 加工“車輛狀態(tài)信息推遲”詞條描述加工名：車輛狀態(tài)信息推遲加工編號：簡要描述：車輛快使用到期后，用車人不能及時的歸還，需要把車的使用的時間延長輸入數(shù)據(jù)流：狀態(tài)延長信息輸出數(shù)據(jù)流：推遲結(jié)果加工邏輯：在前臺獲取用戶延長的時間，在數(shù)據(jù)庫里修改車輛的歸還時間 表311 加工“車輛到期提醒”詞條描述加工名：車輛到期提醒加工編號：簡要描述：當車輛還有1天時間就到了車輛歸還時間，系統(tǒng)提醒用戶車輛要到歸還時間了輸入數(shù)據(jù)流：無輸出數(shù)據(jù)流：提醒信息加工邏輯：在車輛狀態(tài)信息中獲取還有1天到期的使用車輛，并把提醒的信息以短信方式給用車人。相應(yīng)的數(shù)據(jù)字典描述將在數(shù)據(jù)需求中詳細展開。在該模塊中，輸入數(shù)據(jù)有“費用信息”、“提醒信息”、“車輛狀態(tài)延遲信息”、“用車信息”、“查詢條件”，輸出數(shù)據(jù)有“日志信息集合”、“操作結(jié)果”、“用車信息”、“租車信息”。圖35 一層數(shù)據(jù)流圖表34加工“車輛狀態(tài)管理”詞條描述加工名：車輛狀態(tài)管理加工編號：1簡要描述：對公務(wù)用車的使用的狀態(tài)進行管理輸入數(shù)據(jù)流：提醒信息、車輛狀態(tài)延遲信息輸出數(shù)據(jù)流：租車信息加工邏輯：完成對車輛狀態(tài)信息查詢、狀態(tài)信息推遲、車輛到期提醒表35“車輛費用管理”詞條描述加工名：車輛費用管理加工編號：2簡要描述：對公務(wù)用車的費用進行管理輸入數(shù)據(jù)流：費用信息，用車信息輸出數(shù)據(jù)流：用車信息加工邏輯：公務(wù)用車費用收費、修改費用、系統(tǒng)盈利統(tǒng)計表36加工“車輛檔案管理”詞條描述加工名：車輛檔案管理加工編號：3簡要描述：對車輛的檔案進行管理輸入數(shù)據(jù)流：車輛信息輸出數(shù)據(jù)流：操作結(jié)果加工邏輯：對車輛檔案信息進行添加、統(tǒng)計、修改、查詢表37加工“日志管理”詞條描述加工名：日志管理加工編號：4簡要描述：對系統(tǒng)操作日志進行管理輸入數(shù)據(jù)流：查詢條件輸出數(shù)據(jù)流：日志信息集合加工邏輯：對系統(tǒng)操作維護管理根據(jù)數(shù)據(jù)流圖我們可以看出，該功能由用車人開始，結(jié)束于費用管理，其中用車人和物業(yè)管理人員為操作實體。其中用車人通過系統(tǒng)能夠租用公務(wù)用車；同時物業(yè)管理人員主要對公務(wù)用車進行管理、同時租用公務(wù)用車管理收費的過程；除此之外，系統(tǒng)管理員在整個過程中參與系統(tǒng)的維護操作，主要對系統(tǒng)日志進行查詢與監(jiān)控。畫數(shù)據(jù)流圖的基本步驟概括的說，就是自外向里、自頂鄉(xiāng)下、逐層細化、完善求精。數(shù)據(jù)流圖從數(shù)據(jù)傳遞和加工的角度，以圖形的方式刻畫系統(tǒng)邏輯模型及信息從輸入到輸出的移動變換過程。在結(jié)構(gòu)分析方法中，通常采用數(shù)據(jù)流圖(DDF)和數(shù)據(jù)字典(DD)工具。物業(yè)管理人員系統(tǒng)主要參與者，對公務(wù)車進行狀態(tài)管理，費用管理和檔案管理。功能需求描述是開發(fā)人員需要實現(xiàn)什么。（一）車輛狀態(tài)管理模塊流程圖圖31 車輛狀態(tài)管理模塊流程圖（二）車輛費用管理模塊流程圖圖32 車輛費用管理模塊流程圖（三）車輛檔案管理模塊流程圖圖33 車輛檔案管理模塊流程圖功能需求（functional requirement）規(guī)定開發(fā)人員必須在產(chǎn)品中實現(xiàn)的軟件功能，用戶利用這些功能來完成任務(wù)，滿足業(yè)務(wù)需求。（五）響應(yīng)速度合理，安全性較高。（三）車輛檔案管理模塊中的功能有檔案錄入，檔案查詢、檔案修改、檔案統(tǒng)計。白碗窯鎮(zhèn)政府公務(wù)用車管理系統(tǒng)的主要有車輛狀態(tài)管理模塊、車輛費用管理模塊、車輛檔案管理模塊三個模塊構(gòu)成，每個模塊的功能如下：（一）車輛狀態(tài)管理模塊中的功能有車輛狀態(tài)信息查詢、車輛狀態(tài)信息推遲、車輛信息提醒。業(yè)務(wù)需求描述了組織為什么要開發(fā)一個系統(tǒng)，即組織希望達到的目標。 業(yè)務(wù)需求（Business requirement）表示組織或客戶高層次的目標。最后還要對車輛的維修人員和車輛的保養(yǎng)人員進行調(diào)研。其次我們要調(diào)研系統(tǒng)中的車輛申請者，車輛申請者分布在白窯鎮(zhèn)鎮(zhèn)政府內(nèi)各個部門，需要進行詳盡的調(diào)研。系統(tǒng)的使用者中最主要的就是系統(tǒng)管理員，系統(tǒng)管理員不但要安排車輛的分配，還要維護系統(tǒng)的運行。通過詳細的需求分析，我們可以弄清系統(tǒng)的工作原理，弄清系統(tǒng)的整體框架，確定其主要功能。車輛系統(tǒng)要切實全面的考慮到各級員工的需求，因為各級員工對車輛的使用情況和需求情況可能不同。我們只有做好了前期的需求分析，才能夠?qū)④浖目傮w概念以及功能和性能描述為具體需求的規(guī)格說明，才可以奠定軟件的開發(fā)基礎(chǔ)。需求分析的好壞將直接影響到軟件系統(tǒng)的使用性。軟件的需求分析指的是分析調(diào)研各種用戶在功能、性能、設(shè)計、行為約束等方面對將要實現(xiàn)的軟件系統(tǒng)的期望。然后對系統(tǒng)的整個框架做出了需求分析。此模型既要面向用戶，又要面向系統(tǒng)，主要用于數(shù)據(jù)庫管理系統(tǒng)（DBMS）的實現(xiàn)。邏輯數(shù)據(jù)模型。它是以解域的語言解釋數(shù)據(jù)模型，是面向計算機物理表示的模型，描述了數(shù)據(jù)在儲存介質(zhì)上的組織結(jié)構(gòu)，它不但與具體的DBMS有關(guān)，而且還與操作系統(tǒng)和硬件有關(guān)。故它以問題域的語言解釋數(shù)據(jù)模型，由一系列應(yīng)用領(lǐng)域的概念組成。因為數(shù)據(jù)模型的內(nèi)容是問題域和解域所共享的知識模型，所以可以用問題域的語言來描述它，也可以用解域的語言來描述它，還可以用介于二者之間的語言來描述，故產(chǎn)生了以下三種常用的數(shù)據(jù)模型：概念數(shù)據(jù)模型。簡而言之，第三范式（3NF）要求一個數(shù)據(jù)庫表中不包含已在其它表中已包含的非主關(guān)鍵字信息。第三范式（3NF）。為實現(xiàn)區(qū)分通常需要為表加上一個列，以存儲各個實例的唯一標識。第二范式（2NF）要求實體的屬性完全依賴于主關(guān)鍵字。第二范式（2NF）要求數(shù)據(jù)庫表中的每個實例或行必須可以被唯一地區(qū)分。第二范式（2NF）。在第一范式（1NF）中表的每一行只包含一個實例的信息。所謂第一范式（1NF）是指數(shù)據(jù)庫表的每一列都是不可分割的基本數(shù)據(jù)項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復(fù)的屬性。一般說來，數(shù)據(jù)庫只需滿足第三范式（3NF）就行了。滿足最低要求的范式是第一范式（1NF）。關(guān)系數(shù)據(jù)庫中的關(guān)系必須滿足一定的要求，即滿足不同的范式?；顒訄D活動圖是UML的動態(tài)視圖之一，用來描述事物或?qū)ο蟮幕顒幼兓鞒?。在實體類的設(shè)計中主要關(guān)注類的屬性；交互圖交互圖 用來描述對象之間,以及對象與參與者之間的動態(tài)協(xié)作關(guān)系以及協(xié)作過程中行為次序的圖形文檔。在控制類的設(shè)計中主要關(guān)注類的方法。在界面類的設(shè)計中主要關(guān)注屬性和消息方法；控制類承擔著事務(wù)處理，控制調(diào)控的控制作用。界面類位于系統(tǒng)與外界的交界處，承擔系統(tǒng)與外界的信息功能。隨著開發(fā)的深入，類圖應(yīng)該越來越詳細、具體。類圖在系統(tǒng)中處在核心位，也是UML中最為重要的一種圖。用例圖可以作為整個系統(tǒng)開發(fā)過程中的開發(fā)依據(jù)，指導(dǎo)和驅(qū)動其他模型。與此同時，UML也正在變得越來越龐大，但當我們只是運用UML來進行面向?qū)ο笤O(shè)計時，并不需要用到所有的UML內(nèi)容，而是可以學(xué)習和使用UML那些最適合的部分。UML正處于不斷演化和完善過程之中，最初的UML標準只是作為一種面向?qū)ο筝o助的工具而設(shè)計的，即為軟件的設(shè)計意圖提供一種非形式化的捕獲和表達手段和工具。UML定義了一些建立模型、表達某種特定含義所需要的基本元素，這些元素稱為元模型，相當于語言中的基本詞匯，例如用例、類等。UML被廣泛應(yīng)用于數(shù)據(jù)建模，業(yè)務(wù)建模，對象建模，組件建模等。 形式化方法提供了可以產(chǎn)生無缺陷軟件的承諾。在開發(fā)中使用形式化方法時，它們提供了一種機制，能夠消除使用其它軟件過程模型難以克服的很多問題。形式化方法模型包含了一組活動，他們導(dǎo)致了計算機軟件的數(shù)學(xué)規(guī)約。噴泉模型的缺點：由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。噴泉模型不像瀑布模型那樣，需要分析活動結(jié)束后才開始設(shè)計活動，設(shè)計活動結(jié)束后才開始編碼活動。噴泉一詞本身就體現(xiàn)了迭代和無間隙的特性。由于噴泉模型在各個開發(fā)階段是重疊的，因此在開發(fā)過程中需要大量的開發(fā)人員，因此不利于項目的管理。該模型的各個階段沒有明顯的界限，開發(fā)人員可以同步進行開發(fā)。 （三）面向?qū)ο蟮膰娙Ｐ驮诿嫦驅(qū)ο蟮姆椒ㄖ校岢隽擞谄俨寄Ｐ拖鄬?yīng)的噴泉模型，該模型的主要特點是認為軟件生命周期的各個階段是相互重疊和多次反復(fù)的，它是一種以用戶需求為動力，以對象為驅(qū)動的模型，主要用于描述面向?qū)ο蟮能浖_發(fā)過程。 螺旋模型的優(yōu)點：設(shè)計上的靈活性,可以在項目的各個階段進行變更；以小的分段來構(gòu)建大型系統(tǒng),使成本計算變得簡單容易；客戶始終參與每個階段的開發(fā),保證了項目不偏離正確方向以及項目的可控性；隨著項目推進,客戶始終掌握項目的最新信，從而他或她能夠和管理層有效地交互；客戶認可這種公司內(nèi)部的開發(fā)方式帶來的良好的溝通和高質(zhì)量的產(chǎn)品。實施工程：實施軟件開發(fā)。沿著螺旋線旋轉(zhuǎn)，在笛卡爾坐標的四個象限上分別表達了四類活動：制定計劃：確定軟件目標，選定實施方案，弄清項目開發(fā)的限制條件。多數(shù)情況下，會沿著螺旋線繼續(xù)下去，自內(nèi)向外逐步延伸，最終得到滿意產(chǎn)品。螺旋模型將開發(fā)劃分為制訂計劃，風險分析，實施工程，客戶評估四類活動。軟件風險是任何軟件開發(fā)項目中都普遍存在的實際問題，項目越大，軟件越復(fù)雜，承擔該項目所冒的風險也越大。螺旋模型由巴利瀑布模型的優(yōu)點：促進軟件開發(fā)工程化，為項目提供了按階段劃分的檢查點；降低軟件開發(fā)的復(fù)雜度，當前一階段完成后，只需去關(guān)注后續(xù)階段；可以在增量模型中使用瀑布模型。理想化的瀑布模型是單邊逐一而下的，認為人在工作過程中不可能犯錯誤。羅伊斯在1970年提出，在20世紀80年代以前，瀑布模型一直都是唯一被廣泛采用的軟件開發(fā)模型。對于每個中間構(gòu)件只要保證其管理的客戶機數(shù)量限制在允許的范圍之內(nèi)，對于系統(tǒng)的性能幾乎不會有任何的影響。異構(gòu)性:對于網(wǎng)絡(luò)分布的業(yè)務(wù)處理對象適合多種不同的數(shù)據(jù)庫環(huán)境，可以訪問若干種不同的后臺數(shù)據(jù)庫。為了方便系統(tǒng)的實施，可以集中業(yè)務(wù)邏輯。對于新增客戶機的要求，可以利用新增中間件服務(wù)器的方法進行滿足，使得整個三層系統(tǒng)的可擴張性得到提高。：調(diào)整整個系統(tǒng)資源利用率，對于多個任務(wù)進行恰當?shù)姆峙?。服?wù)器主要作用有:事務(wù)處理和組件管理的功能；實現(xiàn)了多種中間件的功能；保證了系統(tǒng)的安全性控制，系統(tǒng)的擴展功能和系統(tǒng)的狀態(tài)監(jiān)控。，其核心是Web應(yīng)用服務(wù)器，它的作用主要是為處理系統(tǒng)的業(yè)務(wù)應(yīng)用提供安全控制，事務(wù)處理和保證多用戶發(fā)出瀏覽器請求時的性能調(diào)整。，具有非常好的擴展性，功能強大，并且在Windows平臺上有著很好的運行性能，他是微軟推出的三層系統(tǒng)架構(gòu)，主要有數(shù)據(jù)庫服務(wù)器，Web應(yīng)用服務(wù)器和客戶端瀏覽器三層組成。這種三層架構(gòu)降低了層層之間的依賴關(guān)系，使得新的實現(xiàn)替代舊的實現(xiàn)變得更加容易，如果某一層發(fā)現(xiàn)了漏洞，只需要修改本層的應(yīng)用程序，在保證層層之間接口不變的前提下，不再需要去修改別的層。這就表明，如果客戶端想數(shù)據(jù)庫服務(wù)器端發(fā)出請求，實際上并不是直接的，而是通COM/DCOM與組件層的鏈接，再經(jīng)組件層完成和數(shù)據(jù)庫之間的交互，最終將結(jié)果發(fā)送給請求者。這三個層次區(qū)分的目的是“高內(nèi)聚，低禍合”。所謂的三層架構(gòu)是邏輯上的三層，可以置于一臺機器上，并不一定是物理上放在單臺機器上，也不只是使用B/S架構(gòu)的才叫做三層架構(gòu)。通過點擊鏈接，瀏覽者同樣向服務(wù)器發(fā)出請求，不同于靜態(tài)頁面的是此時服務(wù)器會根據(jù)頁面的特性來作出反應(yīng)，在數(shù)據(jù)庫讀取用戶請求的信息，并將結(jié)果發(fā)送并顯示在客戶的瀏覽器。這種傳統(tǒng)的頁面顯示技術(shù)己經(jīng)跟不上時代的發(fā)展要求，并且互動性不強，只有重新編寫HTML進行更新信息，并重新上傳至服務(wù)器，導(dǎo)致效率很低，而且浪費網(wǎng)頁資源。而C/S僅僅開發(fā)客戶端，能夠訪問數(shù)據(jù)即可，在開發(fā)的過程中也不需要其他多余的設(shè)備，只要利用計算機進行編碼?？傊瑑煞N體系結(jié)構(gòu)各有各自的優(yōu)缺點，本系統(tǒng)在了解到兩種架構(gòu)的基礎(chǔ)上，為了集中兩種架構(gòu)帶來的優(yōu)點，將采用B/S和C/S的混合模式進行開發(fā)。但無論服務(wù)器選擇何種操作系統(tǒng)，對于用戶的桌面操作不會有影響，并且在Linux操作系統(tǒng)是開源的操作系統(tǒng)，在成本上要遠遠優(yōu)于windows。所以客戶機的數(shù)量并不會影響系統(tǒng)的運行。另外，該模型對于操作系統(tǒng)有很大的要求，并且可能增加軟件開發(fā)的成本，不同的軟件并不是在每一種操作系統(tǒng)上都是兼容的，所以針對不同的操作系統(tǒng)，需要特定的改進來適應(yīng)各種各樣的操作系統(tǒng)。 C/S模式的缺點：上邊己經(jīng)提到，該模式下對專業(yè)軟件要求較高，因此相對而言，維護的成本會很高。服務(wù)器處于啟動狀態(tài)后，隨時等待處理客戶端發(fā)來的請求。（2）服務(wù)器端較輕的數(shù)據(jù)處理負荷該模式由數(shù)據(jù)庫服務(wù)器程序和客戶機應(yīng)用程序兩個部分組成。對于前臺的可能違背的若干規(guī)則，以及類似于訪問者權(quán)限的不相同的運行數(shù)據(jù)，都不會集中在服務(wù)器程序集中的實現(xiàn)。對于樂山鎮(zhèn)政府的車輛管理系統(tǒng)，為了后期開發(fā)更為簡捷，選擇合適的模式非常重要，下邊我們通過分析兩種模式的優(yōu)缺點決定開發(fā)此系統(tǒng)的合適的方法。用戶可以直接通過外網(wǎng)隨時隨地操作共同的數(shù)據(jù)庫，接入方式?jīng)]有任何限制，使得相應(yīng)的權(quán)限得到有效的保護，使服務(wù)器更加安全和穩(wěn)定，所以當前大部分的管理系統(tǒng)或應(yīng)用系統(tǒng)都采用這種模式進行開發(fā)。這種模式基于當前越來越成熟的瀏覽器技術(shù)，利用J