mrp管理信息系統(tǒng)畢業(yè)論文

1、<p><b>　　摘 要</b></p><p>　　所謂MIS（管理信息系統(tǒng)--Management Information System）系統(tǒng) ，是一個由人、計算機及其他外圍設備等組成的能進行信息的收集、傳遞、存貯、加工、維護和使用的系統(tǒng)。一個完整的MIS應包括：輔助決策系統(tǒng)（DSS）、工業(yè)控制系統(tǒng)（CCS）、辦公自動化系統(tǒng)（OA）以及數據庫、模型庫、方法庫、知識庫和與上級

2、機關及外界交換信息的接口。而MRP(Material Requirement Planning 物料需求計劃)是被設計并用于制造業(yè)庫存管理信息處理的系統(tǒng)，它解決了如何實現(xiàn)制造業(yè)庫存管理目標——在正確的時間按正確的數量得到所需的物料這一難題。MRP是當今眾所周知的ERP的雛形，MRP與ERP的庫存管理思想又源于求解制造業(yè)基本方程。</p><p>　　中小企業(yè)在我國經濟發(fā)展中占有重要地位，隨著全球經濟一體化的發(fā)展及

3、中國加入WTO，中小企業(yè)將面臨外資企業(yè)和國外產品與服務的嚴峻挑戰(zhàn)，因此，如果我國的中小企業(yè)不借助先進的管理思想轉變經營觀念、使用信息化提高企業(yè)的管理水平和工作效率，將很難在今后的國際競爭中取勝。企業(yè)管理在很多方面、很大程度上都必須借助信息化來完成。隨著電腦知識日趨普及，同時市場經濟快速多變，競爭激烈，因此企業(yè)采用計算機對生產計劃進行管理已成為趨勢及必然。</p><p>　　本文是采用Visual Basic作為

4、開發(fā)工具，SQL Server作為后臺數據庫而開發(fā)的MRP管理信息系統(tǒng)，可以實現(xiàn)對產品信息、廠商信息、合同收賬、合同信息、制造技術統(tǒng)計的管理。</p><p>　　關鍵詞：管理信息系統(tǒng); MRP; 商品庫存調度; Visual Basic.NET; SQL Server2000</p><p><b>　　Abstract</b></p><p&g

5、t;　　The so-called MIS (Management Information System) is composed of a people, computers and other peripheral devices and so on ,the usage of which contains information collection, transmission, storage, processing, mai

6、ntenance and so on . A complete MIS should include: decision support system (DSS), industrial control systems (CCS), office automation (OA) and database, model base, method base, knowledge base and with the higher author

7、ities and external exchange of information interfaces. MRP (Mate</p><p>　　Playing an important role of SMEs in China's economic development, with the development of global economic integration and China&

8、#39;s accession to the WTO, SMEs will face severe challenges of foreign-funded enterprises and foreign products and services. If China's small and medium enterprises lack the aid of advanced management thinking to ch

9、ange their management concepts and the use of information technology to improve enterprise management level and efficiency, it will be difficult to win in the </p><p>　　Ask is using Visual Basic as a develop

10、ment tool, MRP management information system, developed by the SQL Server as the back-end database of product information, vendor information, contracts receivable, contract information, manufacturing, management of tech

11、nical statistics.</p><p>　　Keywords: MIS; MRP; Visual Basic.NET; SQL Server2000</p><p><b>　　目 錄</b></p><p><b>　　引 言I</b></p><p><b>　

12、　第一章 緒論1</b></p><p>　　1. 1物料需求計劃(MRP)簡介1</p><p>　　1. 2國內現(xiàn)狀1</p><p><b>　　1.3項目意義2</b></p><p><b>　　1.4系統(tǒng)目標3</b></p><p>　　

13、第二章 需求分析4</p><p>　　2.1 功能需求5</p><p><b>　　2.2性能需求6</b></p><p>　　2.3 界面需求7</p><p>　　第三章 系統(tǒng)分析8</p><p>　　3.1 識別參與者8</p><p><

14、b>　　3.2識別用例9</b></p><p>　　3.3 定義系統(tǒng)對象12</p><p>　　3.4 定義類間的關系13</p><p>　　第四章 系統(tǒng)設計15</p><p>　　4.1建立交互作用圖15</p><p>　　4.2 建立活動圖16</p><

15、;p>　　4.3 建立時序圖17</p><p>　　4.4數據庫設計18</p><p>　　第五章 系統(tǒng)實現(xiàn)25</p><p>　　5.1 登錄界面設置25</p><p>　　5.2 系統(tǒng)管理功能設置26</p><p>　　5.3訂單管理功能設置28</p><p>

16、;　　5.4出入庫管理功能設置29</p><p>　　5.5查詢管理功能設置30</p><p>　　5.6 問題分析31</p><p>　　第六章 系統(tǒng)測試33</p><p>　　6.1 系統(tǒng)測試概述33</p><p>　　6.2 系統(tǒng)測試方法33</p><p>　　6

17、.3 測試內容34</p><p>　　6.4測試結果36</p><p>　　6. 5系統(tǒng)評價36</p><p><b>　　總 結37</b></p><p><b>　　致 謝I</b></p><p><b>　　參考文獻I</b>

18、</p><p><b>　　附 錄1</b></p><p><b>　　引 言</b></p><p>　　MRP是以物料計劃人員或存貨管理人員為核心的物料需求計劃體系，它的涵蓋范圍僅僅為物料管理這一塊。 主要用于非獨立性需求（相關性需求）性質的庫存控制。 企業(yè)怎樣才能在規(guī)定的時間，規(guī)定的地點，按照規(guī)定的數量得到

19、真正需要的物料，換句話說，就是庫存管理怎樣才能符合生產計劃的要求，這是物料需求計劃所解決的。</p><p>　　物料需求計劃是以物料計劃人員或存貨管理人員為核心的物料需求計劃體系，它的涵蓋范圍僅僅為物料管理這一塊。物料需求計劃是一種以計算機為基礎的生產計劃與控制系統(tǒng)，它根據總生產進度計劃中規(guī)定的最終產品的交貨日期，編制所構成最終產品的裝配件、部件、零件的生產進度計劃、對外的采購計劃、對內的生產計劃。它可以用來計

20、算物料需求量和需求時間,從而降低庫存量。</p><p>　　本系統(tǒng)前臺采用Visual Basic.NET作為開發(fā)工具，它全面支持面向對象的程序設計,包括數據抽象,封裝,對象與屬性,類與成員,繼承和多態(tài)等。后臺用SQL Server2000來儲存相應的數據，SQL語言包含查詢、定義、操控和控制4個部分，是一種功能齊全的數據庫語言。它的主要功能就是同各種數據庫建立聯(lián)系，進行溝通。</p><p

21、>　　本系統(tǒng)可以作為ERP的一部分直接使用，也可以在制造型中小型企業(yè)單獨使用。通過這套系統(tǒng)的運用，可以大大的減少人力、物力和財力，進而實現(xiàn)高的效益，提高企業(yè)的競爭力。</p><p><b>　　第一章 緒論</b></p><p>　　1. 1物料需求計劃(MRP)簡介</p><p>　　物料需求計劃(Materials Requi

22、rement Planning，簡稱MRP)的基本思想就是把企業(yè)作為一個有機的整體，從整體優(yōu)化的角度出發(fā)，通過運用科學的方法把企業(yè)各種資源和產、供、銷、財各個環(huán)節(jié)實行合理有效的計劃、組織、控制和調整，使他們在生產經營過程中得以協(xié)調有序地發(fā)揮作用。</p><p>　　制定MRP所需的關鍵信息要素有三個:</p><p>　　主生產計劃(Master Production Schedule，

23、簡稱MPS )即是每一最終產品的生產計劃，據此可以推算出所需的相關物料。</p><p>　　物料清單(Bill Of Materials，簡稱BOM )它說明一個最終產品是由哪些零部件、原材料所構成的，這些零部件的時間數量上的相互關系是什么。</p><p>　　庫存紀錄。庫存中有哪些物料，有多少，己經準備，再進多少，從而在制定新的加工、采購計劃時減掉相應的數量。</p>

24、<p><b>　　1. 2國內現(xiàn)狀</b></p><p>　　由于應用MRP涉及到國家經濟體制、人的素質、企業(yè)的生產經營機制、傳統(tǒng)管理方法和管理基礎等一系列實際問題，因此引進MRP系統(tǒng)的企業(yè)，未能使其迅速、全面地轉化為生產力，普遍出現(xiàn)了實施難度大、周期長、反復多、見效慢等現(xiàn)象。有的企業(yè)幾年時間才實施二、三個軟件模塊的功能，有的企業(yè)甚至中途擱淺，不了了之。這種應用現(xiàn)狀與西方工業(yè)發(fā)

25、達國家的企業(yè)相比，無論是從總體應用水平、項目實施周期和系統(tǒng)投入產出，還是從應用規(guī)劃、應用范圍、應用數量和應用效果來看，都存在著很大的差距，這不僅嚴重影響了我國企業(yè)管理水平、整體素質和經濟效益的提高，而且也制約了整個國民經濟的發(fā)展和提高。</p><p><b>　　1.3項目意義</b></p><p>　　二十世紀60年代初，隨著計算機技術的發(fā)展，一種新的生產管理技

26、術—物料需求計劃MRP ( Material Requirement Planning)首先在美國發(fā)展起來。到80年代已經形成為一種綜合計劃管理系統(tǒng)的通用軟件包，在世界各國的制造型企業(yè)得到了廣泛應用。其間經歷了三個發(fā)展階段:基本MRP、制造資源計劃(后來又簡稱MRPID和ERP。</p><p>　　60年代初期，多品種小批量生產被認為是最重要的生產模式，生產中多余的消耗和資源分配的不合理首先表現(xiàn)在物料的多余庫存

27、上。為了解決原材料的庫存問題，出現(xiàn)了以相關需求原則、最少投入和關鍵路徑為基礎的“物料需求計劃”，簡稱MRP。隨著國內國際市場競爭環(huán)境的日益激烈，企業(yè)對自身資源的管理范圍在不斷擴大，對制造資源的計劃也在逐漸細化并且精確化，單純面向物料的MRP擴展到對與生產能力相關的人力和設備等更多資源的計劃與控制，逐漸引入了資源計劃與保證、安排生產、執(zhí)行監(jiān)控與反饋等功能，這就是閉環(huán)MRP。之后又加入了對制造范圍的資金控制，計劃方法的</p>

28、<p>　　名稱隨著控制對象的升級而改為“制造資源計劃(Manufacturing Resource Planning) "，即MRP II。目前先進的ERP ( Enterprise Resource Planning)系統(tǒng)又是在MRPII的基礎上擴展了管理范圍，這是因為考慮到靠企業(yè)自己的資源不可能有效的參與市場競爭，必須把經營過程中有關各方如供應商、銷售網絡、客戶、市場等納入系統(tǒng)，才能有效的安排企業(yè)的銷—供—產

29、活動，滿足企業(yè)利用全社會的市場資源的要求。盡管如此MRP仍然是ERP的核心功能。近年來，業(yè)界流行的術語已經變成了ERP, SCM ( Supply Chain Management，或全球運籌(Global Logistics)等新名詞，因此，可能有人會懷疑MRP是否己經落伍。其實，ERP系統(tǒng)是MRP系統(tǒng)的延伸與擴大;不少新一代的應用系統(tǒng)只是將工作流的應用觀念加入到MRP系統(tǒng)之中，只是改變了它的執(zhí)行方式和實施方式。因此，MRP仍然是制

30、造業(yè)運作模式中最根本的基礎，它仍具有極大的價值，非常值得我們努力學習的。同時隨著計算機技術的飛速發(fā)展，計算機在企業(yè)信息管理中應用的普及，利用計算機實現(xiàn)企業(yè)</p><p><b>　　1.4系統(tǒng)目標</b></p><p>　　結合相關性需求的特點和改善企業(yè)生產經營的需要，對物料需求計劃(MRP )系統(tǒng)提出了以下的目標:最大限度地保證訂貨任務的按期完成;提高庫存管理的

31、服務水平，最大限度地降低庫存量，包括中間庫存和在制品庫存，以減少在庫存上的資金積壓;提高計劃的可靠性，實現(xiàn)均衡生產;集成管理職能，提高管理效率。</p><p>　　物料需求計劃(MRP)系統(tǒng)的基本指導思想是:只在需要的時候，向需要的部門按需要的數量，提供所需要的物料。就是說，它既要防止物料供應滯后于對它們的需求，也要防止物料過早地出產和進貨，以免增加庫存，造成物資和資金的積壓。</p><p

32、><b>　　第二章 需求分析</b></p><p>　　需求分析是指在充分了解客戶情況之后，與客戶一起討論對系統(tǒng)的具體要求，針對其現(xiàn)行體制中的不足及目前所需，制訂出一套需求方案。需求分析應該完全以企業(yè)的需要及實際情況為出發(fā)點，為企業(yè)合理地選擇系統(tǒng)提供基本保障。需求分析是整個系統(tǒng)實施過程中至關重要的一步，客戶需求是否合理決定了整個系統(tǒng)實施的成敗。首先調查組織機構情況，包括了解該組織的

33、部門組成情況，各部門的職能等，為分析信息流程準備。然后調查各部門的業(yè)務活動情況，包括了解各個部門輸入和使用什么數據，如何加工處理這些數據，輸出什么信息，輸出到什么部門，輸出結果的格式是什么。協(xié)助用戶明確對新系統(tǒng)的各種要求，包括信息要求、處理要求、完全性與完整性要求。最后確定新系統(tǒng)的邊界，確定哪些功能由計算機完成或將來準備讓計算機完成，哪些活動由人工完成。由計算機完成的功能就是新系統(tǒng)應該實現(xiàn)的功能。需求分析應遵守以下原則：</p&g

34、t;<p><b>　　解決邏輯問題</b></p><p>　　需求分析是對問題的識別和說明過程，分析員要回答的是“系統(tǒng)必須做什么”的問題。需求分析的基本原則是給出要完成的功能和處理信息，而不考慮實現(xiàn)的細節(jié)，即需求分析工作應集中在明確系統(tǒng)要完成的功能是什么，而不是要考慮系統(tǒng)怎樣才能實現(xiàn)這些功能。</p><p><b>　　以運行環(huán)境為基礎&

35、lt;/b></p><p>　　需求分析工作應以運行環(huán)境為基礎，實事求是。系統(tǒng)分析人員可以參考，但不能照搬其他類似的系統(tǒng)開發(fā)時的分析工作，更不能不負責任，憑個人的主觀想象辦事。</p><p><b>　　用戶參與</b></p><p>　　需求分析工作是系統(tǒng)分析人員同用戶不斷交互的過程。因此，在工作中客戶（開發(fā)委托者或開發(fā)委托者兼系

36、統(tǒng)使用者）應參加分析工作，以保證交互的充分性和工作效率。同時，需求分析工作也應有客戶所指定的人員參加。</p><p>　　需求分析可以從幾方面入手，一般是功能需求、性能需求和界面需求。</p><p><b>　　2.1 功能需求</b></p><p>　　功能需求 （functional requirement）是規(guī)定開發(fā)人員必須在產品中

37、實現(xiàn)的軟件功能，用戶利用這些功能來完成任務，滿足業(yè)務需求。功能需求有時也被稱作行為需求 （behavioral requirement），因為習慣上總是用“應該”對其進行描述：“系統(tǒng)應該發(fā)送電子郵件來通知用戶已接受其預定”。功能需求描述是開發(fā)人員需要實現(xiàn)什 么。用戶需求不總是被轉變成功能需求。產品特性，所謂特性（feature），是指一組邏輯上相關的功能需求，它們?yōu)橛脩籼峁┠稠椆δ?，使業(yè)務目標 得以滿足。對商業(yè)軟件而言，特性則是一組能被

38、客戶識別，并幫助他決定是否購買的需求，也就是產品說明書中用著重號標明的部分?？蛻粝Ｍ玫降漠a品特性和用戶的任務相關的需求不完全是一回事。一項特性可以包括多個用例，每個用例又要求實現(xiàn)多項功能需求，以便用戶能夠執(zhí)行某項任務。</p><p>　　本文所講到的商品庫存調度管理信息系統(tǒng)是非常實用的一套系統(tǒng)，它廣泛的用于企業(yè)、公司的生產銷售管理，是一套嚴謹、功能完整的管理系統(tǒng)。該系統(tǒng)的主要功能是用戶與簡單的客戶管理集商品生

39、產、出入庫、銷售、訂單的跟蹤和記錄，還具有非常重要的統(tǒng)計功能。系統(tǒng)功能大致有以下幾個功能：</p><p>　　2.1.1 登錄功能</p><p>　　★ 登錄：輸入用戶名進行判斷后，根據用戶權限，進入不同的功能界面 。</p><p>　　★ 修改：此功能能對用戶的密碼進行修改，提高安全性。</p><p>　　2.1.2 系統(tǒng)管理功能&

40、lt;/p><p>　　★ 用戶信息：屬于管理者權限，可以修改添加用戶以及其權限和密碼。</p><p>　　★ 廠商信息：顯示和企業(yè)有業(yè)務聯(lián)系的所有廠商信息，可以進行信息修改，但不能進行刪除操作。</p><p>　　★ 類別信息：與廠商信息的功能相似。</p><p>　　★ 商品信息：它負責提供基本的設置，是管理員擁有的一個管理模塊，顯示、

41、修改、添加商品各種信息。</p><p>　　2.1.3 出入庫管理功能</p><p>　　★ 出庫：通過事先判斷庫存是否充足，以及修改后庫存是否充足，修改商品的庫存數量，進行出庫。</p><p>　　★ 入庫：窗體中顯示當前入庫信息，經手人為登錄用戶，能實現(xiàn)入庫添加和修改。</p><p>　　2.1.4 查詢統(tǒng)計功能</p>

42、;<p>　　查詢統(tǒng)計：雖然不是必不可少的模塊，但是在真正使用中起到非常重要的作用，甚至可以在該模塊中自動生成報表以及各種統(tǒng)計的數據文件。在本系統(tǒng)中，一共包括了訂單查詢、庫存查詢以及入庫查詢，屬于為客戶提供“售后服務”的位置。</p><p><b>　　2.2性能需求</b></p><p>　　該系統(tǒng)要滿足以下的性能需求:</p>&l

43、t;p>　　★ 縮短計劃生成的時間</p><p>　　運用該系統(tǒng)之后，相關人員只需作少量數據的輸入工作，就可以完成原來花費大量人力和時間才能完成的生產計劃編制工作。</p><p><b>　　★ 界面友好</b></p><p>　　軟件與用戶界面的友好性是用戶能夠方便有效的使用該軟件的關鍵部分。因此系統(tǒng)均采用圖形界面顯示和鼠標的操作

44、方式，方便靈活。</p><p><b>　　★ 靈活性</b></p><p>　　由于市場的多變性和生產過程中會出現(xiàn)一些不確定因素，因此系統(tǒng)應</p><p>　　提供對這些不確定因素采取措施的功能。</p><p><b>　　2.3 界面需求</b></p><p>

45、　　界面設計與測試規(guī)則界面是軟件與用戶交互的最直接的層，界面的好壞決定用戶對軟件的第一印象。而且設計良好的界面能夠引導用戶自己完成相應的操作，起到向導的作用。同時界面如同人的面孔，具有吸引用戶的直接優(yōu)勢。按照界面設計應遵循的易用性、規(guī)范性、幫助設施、合理性和美觀性，并根據上述的功能需求分析進行界面設計。本系統(tǒng)在設計各個界面以及其之間的關聯(lián)時是在畫出整個系統(tǒng)的流程圖的基礎上進行的。具體的流程圖如1-1所示。</p><

46、p>　　圖2-1 系統(tǒng)流程圖</p><p><b>　　第三章 系統(tǒng)分析</b></p><p><b>　　3.1 識別參與者</b></p><p>　　識別參與者，我們可以從以下幾個角度來展開，誰將使用該系統(tǒng)的主要功能；誰將需要該系統(tǒng)的支持以完成其工作；誰將需要安裝、維護、管理該系統(tǒng)，以及保持該系統(tǒng)處于工作

47、狀態(tài)；系統(tǒng)需要處理哪些硬件設備與該系統(tǒng)發(fā)生交互的是什么系統(tǒng)；誰或什么系統(tǒng)對本系統(tǒng)產生的結果感興趣。在這個過程中，我們可以通過畫出系統(tǒng)結構圖來明確顯示參與者。系統(tǒng)結構圖是對軟件系統(tǒng)結構的總體設計的圖形顯示。在需求分析階段已經從系統(tǒng)開發(fā)的角度出發(fā)，把系統(tǒng)按功能逐次分割成層次結構，使每一部分完成簡單的功能且各個部分之間又保持一定的聯(lián)系，這就是功能設計。在設計階段，基于這個功能的層次結構把各個部分組合起來成為系統(tǒng)。</p><

48、;p>　　該系統(tǒng)的系統(tǒng)結構圖按步驟可劃分為：</p><p>　　第一步：進行登錄，如果成功，進入第二步；</p><p>　　第二步：打開系統(tǒng)的主界面，根據相應的權限，在菜單中加以控制。如果有相應的操作，則分別跳入不同的步驟，共有四種選擇；</p><p>　　★ 系統(tǒng)管理：再模塊中可以對用戶信息、廠商信息、商品類別信息和商品信息進行設置和管理；</p

49、><p>　　★ 訂單管理：在該模塊中可以對訂單的記錄信息進行相應的管理操作：</p><p>　　★ 出入庫管理：在該模塊中可以對入庫、出庫兩部分記錄進行相應的管理；</p><p>　　★ 查詢統(tǒng)計：在該模塊中，可以對訂單、庫存以及出入庫的記錄進行一定條件下的查詢。</p><p>　　根據上述的系統(tǒng)結構可也識別出參與者有：庫存管理系統(tǒng)、系統(tǒng)

50、管理員、出入庫管理員、查詢統(tǒng)計、后臺數據庫</p><p>　　圖2-1清楚顯示了系統(tǒng)結構。</p><p><b>　　圖3-1系統(tǒng)結構圖</b></p><p><b>　　3.2識別用例</b></p><p>　　系統(tǒng)的用例分析是UML建模的第一步。用例圖由參與者（Actor）、用例（Use

51、 Case）以及它們之間的關系構成的用于描述系統(tǒng)功能的動態(tài)視圖稱為用例圖。用例圖（User Case）是被稱為參與者的外部用戶所能觀察到的系統(tǒng)功能的模型圖，呈現(xiàn)了一些參與者和一些用例，以及它們之間的關系，主要用于對系統(tǒng)、子系統(tǒng)或類的功能行為進行建模。用例圖展示了用例之間以及同用例參與者之間是怎樣相互聯(lián)系的。用例圖用于對系統(tǒng)、子系統(tǒng)或類的行為進行可視化，使用戶能夠理解如何使用這些元素，并使開發(fā)者能夠實現(xiàn)這些元素。將每個系統(tǒng)中的用戶分出工作

52、狀態(tài)的屬性和工作內容，方便建模，防止功能重復和多余的類。 用例圖定義了系統(tǒng)的功能需求，它是從系統(tǒng)的外部看系統(tǒng)功能，并不描述系統(tǒng)內部對功能的具體實現(xiàn)。上述已經確立了庫存管理系統(tǒng)的各個功能模塊，包括系統(tǒng)管理、訂單管理、出入庫管理、商品管理、廠商管理查詢統(tǒng)計等。根據以上的需求分析和參與者識別，可以畫出用例圖，如圖2-2所示。</p><p><b>　　圖3-2 用例圖</b></p>

53、<p>　　在選中了部分用戶描述進入迭代過程后，為了確保設計和編碼產生完全符合需要的系統(tǒng)，就要對選中的描述進行細化分析，這實際上是一個細化的需求分析過程，會產生更多的需求信息，必須有效的組織和處理它們。一從系統(tǒng)的角度研究事件及行為產品用例的細化分析，首先應該從系統(tǒng)的角度研究外部參與者與我們將要創(chuàng)建的軟件系統(tǒng)之間如何交互。交互期間，參與者產生一個發(fā)送給系統(tǒng)的事件，通常要求系統(tǒng)響應這個操作。根據分析的需要，在SSD中可以考慮每

54、個相鄰系統(tǒng)與系統(tǒng)的交互過程，從而發(fā)現(xiàn)和定義盡可能多的事件，發(fā)現(xiàn)事件的粒度可以根據具體情況來決定，圖2-3便是細化的用例圖。</p><p>　　圖3-3 具體用例圖</p><p>　　3.3 定義系統(tǒng)對象</p><p>　　常用的識別類的方法有：名詞識別法、系統(tǒng)實體識別法、使用重用、從用例中識別類等。</p><p><b>　

55、　★ 名詞識別法 </b></p><p>　　識別問題域中的實體，實體的描述通常用名詞、名詞短語、名詞性代詞的形式出現(xiàn)。用指定語言對系統(tǒng)進行描述；從系統(tǒng)描述中標識名詞、名詞短語、名詞性代詞；識別確定（取、舍）類。</p><p>　　★ 系統(tǒng)實體識別法 </p><p>　　不關心系統(tǒng)的運作流程及實體之間的通信狀態(tài)，而只考慮系統(tǒng)中的人員、組織、地點、表

56、格、報告等實體，經過分析將他們識別為類（或對象）。</p><p>　　被標識的實體有：系統(tǒng)需要存儲、分析、處理的信息實體、系統(tǒng)內部需要處理的設備、與系統(tǒng)交互的外部系統(tǒng)、系統(tǒng)相關人員、系統(tǒng)的組織實體。在確定類時，常使用兩類技術：</p><p>　　★ 分解技術：將整體類和組合類分解。可控制單個類的規(guī)模。 </p><p>　　★ 抽象技術：根據一些類的相似性建

57、立抽象類，并建立抽象類與這些類之間的繼承關系。抽象類實現(xiàn)了系統(tǒng)內部的重用，很好地控制了復雜性，并為所有子類定義了一個公共的界面，使設計局部化，提高系統(tǒng)的可修改性和可維護性。</p><p>　　根據下述原則進一步確定類：</p><p>　　★去掉冗余類：如兩個類表述同一信息，應保留最具有描述能力的類。</p><p>　　★去掉不相干的類：刪除與問題無關或關系不大

58、的類。</p><p>　　★刪除模糊的類：有些初始類邊界定義不確切，范圍太廣，應該刪除。</p><p>　　★刪除那些性質獨立性不強的，而應該是類“屬性”的候選類。</p><p>　　★所描述的操作不適宜作為對象類，并被其自身所操縱，所描述的只是實現(xiàn)過程中的暫時的對象，應刪去。</p><p>　　通過名詞識別法和系統(tǒng)實體識別法等方法可

59、以識別出系統(tǒng)的幾個類,以</p><p>　　下用類圖這種簡單明了的方法分別表示出類的名稱，屬性，操作。圖2-4所</p><p><b>　　示便是類圖。</b></p><p><b>　　圖3-4 類圖</b></p><p>　　3.4 定義類間的關系</p><p>

60、;　　兩個或多個類之間的相互依賴關系就是關聯(lián)，實現(xiàn)關聯(lián)的方式有多種。關聯(lián)通常用描述性動詞和動詞詞組表示?？梢詮膯栴}陳述中抽去所有可能的關聯(lián)表述，在銀行網絡系統(tǒng)示例中所有可能的關聯(lián)，大多數是直接抽取問題中的動詞詞組而得到的。但在陳述中，有些動詞詞組表述的關聯(lián)是不明顯的，或在問題陳述中是找不到的，還有一些關聯(lián)與客觀世界或人的假設有關，必須同用戶一起確定這種關聯(lián)。圖2-5很好的顯示了類之間的關系。</p><p>&l

61、t;b>　　圖3-5 類關系</b></p><p><b>　　第四章 系統(tǒng)設計</b></p><p>　　4.1建立交互作用圖</p><p>　　交互作用圖即協(xié)作圖,協(xié)作圖是時序圖之外另一種表示交互的方法。時序圖描述信息隨時間的交互，而協(xié)作圖描述核對線結構相關的信息。協(xié)作圖可以說明類操作中用到的參數、局部變量以及操作

62、中的永久鏈。當實現(xiàn)一個行為時，消息編號對應程序中潛逃的調用結構和信號傳遞過程。使用協(xié)作圖可以顯示對象角色之間的關系，如為實現(xiàn)某個操作或達到某種結果而在對象間交換的一組消息。如果需要強調時間和序列，最好選擇序列圖；如果需要強調上下文相關，最好選擇協(xié)作圖。協(xié)作圖用于顯示對象之間如何進行交互以執(zhí)行特定用例或用例中特定部分的行為。協(xié)作圖顯示對象之間的關系，它更有利于理解對給定對象的所有影響，也更適合過程設計。協(xié)作圖的格式決定了它們更適合在分析活

63、動中使用。此外，協(xié)作圖很難顯示補充的說明性信息，例如時間、判定點或其他非結構化的信息，而在序列圖中這些信息可以方便地添加到注釋中協(xié)作圖強調參與一個交互對象的組織，它由以下基本元素組成：活動者（Actor）、對象（Object）、連接（Link）和消息（Message）。圖4-1是出庫時的協(xié)作圖。</p><p><b>　　圖4-1 協(xié)作圖</b></p><p>&

64、lt;b>　　4.2 建立活動圖</b></p><p>　　在UML中，活動圖中活動用圓角矩形表示，與狀態(tài)的圖形符號相比，活動的圖形符號更接近橢圓，兩個活動之間用帶箭頭的線進行連接。活動圖是闡明了業(yè)務用例實現(xiàn)的工作流程。業(yè)務用例由一系列活動組成，它們共同為業(yè)務主角生成某些工件。活動圖與傳統(tǒng)的流程圖非常相似，活動圖是面向對象的，描述的是對象活動的順序關系所遵循的規(guī)則，它著重表現(xiàn)的是系統(tǒng)的行為，而

65、非系統(tǒng)的處理過程。一個活動圖可能包括以下元素：活動狀態(tài)表示在工作流程中執(zhí)行某個活動或步驟。轉移表示各種活動狀態(tài)的先后順序。這種轉移可稱為完成轉移。它不同于一般的轉移，因為它不需要明顯的觸發(fā)器事件，而是通過完成活動（用活動狀態(tài)表示）來觸發(fā)。決策，為其定義了一組警戒條件。這些警戒條件決定在活動完成后將執(zhí)行一組備選轉移中的哪一個轉移。同步示意條能夠顯示業(yè)務用例的工作流程中的并行線程。系統(tǒng)的活動圖4-2所示。</p><p&

66、gt;　　圖4-2 系統(tǒng)活動圖</p><p><b>　　4.3 建立時序圖</b></p><p>　　時序圖描述了對象之間傳遞消息的時間順序，用來表示用例中的行為順序。當執(zhí)行用力行為時，時序圖中的消息對應類操作或狀態(tài)流中引起轉換的觸發(fā)事件。時序圖描述對象是如何交互的，并且將重點放在消息序列上。也就是說，描述消息是如何在對象間發(fā)送和接收的。時序圖有兩個坐標軸：縱坐

67、標軸顯示時間，橫坐標軸顯示對象。每一個對象的表示方法是：矩形框中寫有對象或類名，且名字下面有下劃線；同時有一條縱向的虛線表示對象在序列中的執(zhí)行情況 ( 即發(fā)送和接收的消息對象的活動 ) ， 這條虛線稱為對象的生命線。對象間的通信用對象的生命線之間的水平的消息線來表示，消息線的箭頭說明消息的類型，如同步，異步或簡單 。 瀏覽時序圖的方法是，從上到下查看對象間交換的消息，分析那些隨著時間的流逝而發(fā)生的消息交換。</p><

68、;p>　　時序圖中包括如下元素：角色，對象，生命線，激活期和消息。角色（Actor）可以是人或者其他系統(tǒng)。對象(Object)代表時序圖中的對象在交互中所扮演的角色，位于時序圖頂部和對象代表對象實例類角色。對象一般包含以下三種命名方式：第一種方式包含對象名和類名；第二種方式只顯示類名不顯示對象名，即為一個匿名對象；第三種方式只顯示對象名不顯示類名。生命線(Lifeline) 生命線代表時序圖中的對象在一段時期內的存在。時序圖中每個

69、對象和底部中心都有一條垂直的虛線，這就是對象的生命線，對象間的消息存在于兩條虛線間。激活期(Activation)代表時序圖中的對象執(zhí)行一項操作的時期，在時序圖中每條生命線上的窄的矩形代表活動期。它可以被理解成C語言語義中一對花括號“{}”中的內容。消息(Message)是定義交互和協(xié)作中交換信息的類，用于對實體間的通信內容建模，信息用于在實體間傳遞信息。允許實體請求其他的服務，類角色通過發(fā)送和接受信息進行通信。圖4-3是系統(tǒng)的時序圖。

70、</p><p><b>　　圖4-3 時序圖</b></p><p><b>　　4.4數據庫設計</b></p><p>　　數據庫是存儲在一起的相關數據的集合，這些數據是結構化的，無有害的或不必要的兀余，并為多種應用服務;數據的存儲獨立十使用它的程序;對數據庫插入新數據，修改和檢索原有數據均能按一種公用的和可控制的方

71、式進行。當某個系統(tǒng)中存在結構上完全分開的若干個數據庫時，則該系統(tǒng)包含一個“數據庫集合”。</p><p><b>　　★ 數據庫體系結構</b></p><p>　　數據庫的體系結構分二級:內部級(internal)，概念級(conceptual)和外</p><p>　　部級(external)。這個二級結構有時也稱為“二級模式結構”，或“數

72、據抽象的二個級別”，最早是在1971年通過的DBTG報告中提出，后來收入在1975年的美國ANS工/SPARC報告中。雖然現(xiàn)在DBMS的產品多種多樣，在不同的操作系統(tǒng)支持下工作，但是大多數系統(tǒng)在總的體系結構上都具有二級模式的結構特征。從某個角度看到的數據特性稱為“數據視圖”(data view)o</p><p>　　外部級最接近用戶，是單個用戶所能看到的數據特性。單個用戶使用的數據視圖的描述稱為“外模式”。&l

73、t;/p><p>　　概念級涉及到所有用戶的數據定義，是全局的數據視圖。全局數據視圖的描述稱為“概念模式”。</p><p>　　內部級最接近十物理存儲設備，涉及到實際數據存儲的結構。物理存儲數據視圖的描述稱為“內模式”。</p><p>　　數據庫的二級模式結構是數據的二個抽象級別。它把數據的具體組織留給DBMS去做，用戶只要抽象地處理數據，Ifn不必關心數據在計算機

74、中的表示和存儲，這樣就減輕了用戶使用系統(tǒng)的負擔。</p><p>　　二級結構之間往往差別很大，為了實現(xiàn)這二個抽象級別的聯(lián)系和轉換，DBMS在二級結構之間提供兩個層次的映象(mappings):外模式/模式映象，模式/內模式映象。</p><p>　　★ 數據庫的主要特點</p><p>　　實現(xiàn)數據共亨：數據共亨包含所有用戶可同時存取數據庫中的數據，也包括用戶可以

75、用各種方式通過接口使用數據庫，并提供數據共亨。</p><p>　　減少數據的兀余度：同文件系統(tǒng)相比，由十數據庫實現(xiàn)了數據共亨，從}fn避免了用戶各自建立應用文件。減少了大量重復數據，減少了數據兀余，維護了數據的一致性。</p><p>　　數據的獨立性：數據的獨立性包括數據庫中數據庫的邏輯結構和應用程序相互獨立，也包括數據物理結構的變化不影響數據的邏輯結構。</p><

76、;p>　　數據實現(xiàn)集中控制：文件管理方式中，數據處十一種分散的狀態(tài)，不同的用戶或同一用戶在不同處理中其文件之間毫無關系。利用數據庫可對數據進行集中控制和管理，并通過數據模型表示各種數據的組織以及數據間的聯(lián)系。</p><p>　　本系統(tǒng)后臺連接的數據庫名稱為Sample02，數據庫Sample02包含以下9個表：</p><p>　　★CATEGORY表，用來記錄商品信息，如表4-1

77、</p><p>　　★FACTORY表，用來記錄廠商信息，如表4-2</p><p>　　★INNOTE表，記錄入庫信息，如表4-3</p><p>　　★ORDERNOTE表，記錄訂單信息，如表4-4</p><p>　　★OUTNOTE表，記錄出庫信息，如表4-5</p><p>　　★PURVIEW表，記錄權限

78、信息，如表4-6</p><p>　　★SORT表，記錄商品種類信息，如表4-7</p><p>　　★STORE表，記錄庫存信息，如表4-8</p><p>　　★USER表，記錄用戶信息，如表4-9</p><p>　　表4-1 CATEGORY表</p><p>　　表4-2 FACTORY表</p&g

79、t;<p>　　表4-3 INNOTE表</p><p>　　表4-4 INNOTE表</p><p>　　表4-5 OUTNOTE表</p><p>　　表4-6 PURVIEW表</p><p>　　表4-7 SORT表</p><p>　　表4-8 STORE表</p>&

80、lt;p>　　表4-9 USER表</p><p>　　從用戶角度來看，一個視圖是從一個特定的角度來查看數據庫中的數據。從數據庫系統(tǒng)內部來看，一個視圖是由SELECT語句組成的查詢定義的虛擬表。從數據庫系統(tǒng)內部來看，視圖是由一張或多張表中的數據組成的，從數據庫系統(tǒng)外部來看，視圖就如同一張表一樣，對表能夠進行的一般操作都可以應用于視圖，例如查詢，插入，修改，刪除操作等。而視圖是一個虛擬表，其內容由查詢定義。

81、同真實的表一樣，視圖包含一系列帶有名稱的列和行數據。但是，視圖并不在數據庫中以存儲的數據值集形式存在。行和列數據來自由定義視圖的查詢所引用的表，并且在引用視圖時動態(tài)生成。對其中所引用的基礎表來說，視圖的作用類似于篩選。定義視圖的篩選可以來自當前或其它數據庫的一個或多個表，或者其它視圖。分布式查詢也可用于定義使用多個異類源數據的視圖。該數據庫中有五個用戶視圖，用來數據調用時不同表之間的連接，如下所示：</p><p&g

82、t;　　GOODSVIEW：顯示經過轉變的消息信息</p><p>　　圖4-1 GOODSVIEW圖</p><p>　　INVIEW：顯示經過轉變的入庫信息, 其關系圖：</p><p>　　圖4-2 INVIEW圖</p><p>　　STOREVIEW：顯示經過轉變的庫存信息，其關系圖：</p><p>

83、　　圖4-2 STOREVIEW圖</p><p>　　ORDERVIEW：顯示經過轉變的訂單信息：</p><p>　　圖4-3 ORDERVIEW圖</p><p>　　OUTVIEW：顯示經過轉變的出庫信息，其關系圖：</p><p>　　圖4-3 OUTVIEW圖</p><p><b>　　第

84、五章 系統(tǒng)實現(xiàn)</b></p><p>　　本論文是用VB開發(fā)的，界面設計的簡單明了。根據上述的需求分析、系統(tǒng)分析和系統(tǒng)設計，系統(tǒng)應用程序分為五大模塊：登錄模塊、系統(tǒng)管理模塊、訂單管理模塊、出入庫管理模塊和查詢管理模塊。</p><p>　　5.1 登錄界面設置 </p><p>　　登錄界面設計圖見圖4-1，根據界面提示，用戶輸入姓名和密碼后，選擇所

85、需服務。點擊取消便能夠重新輸入，也可以點擊修改密碼進入圖4-2所示的修改密碼解碼界面，這項功能通過對用戶的密碼進行修改，可以提高安全性。當用戶修改密碼后。密碼將會被保存在后臺，下次登錄就需要使用新的密碼。點擊登錄便能根據用戶信息確定用戶的權限進而進入相應的模塊。權限設置分為四類，權限不同進入的界面不同，進而能進行的操作也有所區(qū)別。附錄中的代碼將詳細的顯示不同的權限又怎樣不同的功能以及這些功能的實現(xiàn)。</p><p&g

86、t;　　圖4-1 登錄界面 圖4-2 修改密碼</p><p>　　5.2 系統(tǒng)管理功能設置</p><p>　　系統(tǒng)管理是管理員擁有的權限，是最高權限。在這個功能模塊里，包含用戶管理、廠商管理、類別管理、商品管理，系統(tǒng)管理員可以根據訂單生產等計劃更改或查詢各種信息。</p><p>　　用戶管理界面是指由管理員才能登錄的界面，

87、在這個界面中，管理員有權利對系統(tǒng)的所有用戶進行管理，除了查詢用戶資料外還包括修改密碼、添加用戶、更改權限等。</p><p>　　圖4-3 用戶管理界面</p><p>　　廠商管理界面中能夠顯示供貨商和銷售商的具體信息，包括地址、聯(lián)系電話和廠商名字，在這個?？旆N，管理員除了查詢相關信息外，還能根據具體情況修改廠商具體信息，圖5-4便是廠商管理模塊。</p><p&g

88、t;　　圖4-4 廠商管理界面</p><p>　　類別管理界面能夠顯示企業(yè)生產的商品種類和所需的原材料種類，擁有更新和還原功能，主要是通過將不同的產品進行編號代替名字，是在別的模塊中進行操作能夠簡單方便。圖5-5顯示的是類別管理界面。</p><p>　　圖4-5 類別管理界面</p><p>　　商品管理界面顯示企業(yè)制造時所能需要的各種商品信息，包括商品編號

89、、名稱、類別、廠商名稱、型號、對應價格以及備注；同時還可以進行增加修改的信息，功能比較齊全。 商品管理非常重要，前面的廠商信息以及類別信息都是為了商品管理做準備。圖4-5便是界面。</p><p><b>　　圖4-5 原料管理</b></p><p>　　5.3訂單管理功能設置</p><p>　　訂單管理界面是銷售人員和儲備進行更改的界面，

90、庫存管理人員也可以進行查詢。在這個界面中，銷售人員可以將企業(yè)的訂單輸入，儲備人員也可以根據計劃將要購入的原材料訂單輸入。圖4-6是訂單管理界面。</p><p>　　圖4-6 訂單管理界面</p><p>　　5.4出入庫管理功能設置</p><p>　　出入庫管理是記錄出入庫詳細記錄的，具體到日期、經手人、備注，出入庫管理很重要，它關系到庫存的多少，進而影響到生

91、產進度和計劃。銷售人員和生產人員都需要根據庫存來制定工作計劃。圖4-7是入庫界面和出庫界面。</p><p>　　圖4-7 出入庫界面</p><p>　　5.5查詢管理功能設置</p><p>　　查詢功能模塊是權限別較低的模塊之一，多有的用戶都可以進行查詢。查詢模塊是為各部門制定工作計劃的標準。查詢功能主要有訂單查詢、庫存查詢和出入庫查詢，與上面相對應，在這里

92、的各項功能是只能查詢不能修改和添加，權限受限制。圖4-8、圖4-9和圖4-10分別顯示的是訂單查詢、庫存查詢和出入庫查詢。通過訂單查詢生產作業(yè)人員可以結合庫存制訂詳細的生產計劃。</p><p>　　圖4-8 訂單查詢界面</p><p>　　圖4-9 庫存界面</p><p>　　圖4-10 出入庫查詢界面</p><p><b&

93、gt;　　5.6 問題分析</b></p><p>　　5.6.1數據庫的還原與備份 </p><p>　　還原：選擇數據庫，單擊鼠標右鍵，選擇“所有任務”的子菜單“還原數據庫”，在彈出的對話框中點擊添加選擇要還原的數據備份的路徑的，確定。</p><p>　　備份：選擇數據庫，單擊鼠標右鍵，選擇“所有任務”的子菜單“備 份數據庫”，在彈

94、出的對話框中點擊添加選擇要添加的設備，確定。</p><p>　　5.6.2 SqlConnection、SqlCommand、SqldataAdapter、DataSet、DataTable</p><p>　　通過SqlConnection連接數據庫，是連接SQL Server數據源的對象，在其基礎上用SqlCommand定義查詢或其他命令語句，SqldataAdapter是數據適配器

95、，可以從數據源檢索并填充DataSet中的表，也能將DataSet中的更改更新到數據源，而DataSet是包含DataTable所表的0個或多個表的集合。</p><p>　　5.6.3 Oper對象</p><p>　　其功能是用來存放當前操作對象，后繼操作可以根據這一對象 的具體值來確認究竟是要執(zhí)行怎樣的操作。</p><p>　　5.6.4 Try…Catch

96、…Finally捕捉異常</p><p>　　在Try語句中輸入要捕捉的異常的代碼，如果發(fā)現(xiàn)異常，則跳入Catch 語句，進行錯誤處理，而是重要執(zhí)行的是Finally語句。</p><p>　　5.6.5 ContexMenu、ToolTip、DataGrid控件</p><p>　　ContexMenu控件:添加MenuItem子菜單，在程序運行時只有單擊鼠

97、標右鍵才會顯示該菜單，選擇相應的菜單項，點擊出現(xiàn)對應操作。</p><p>　　ToolTip控件：確定當鼠標懸停在控件上時顯示的工具提示。</p><p>　　DataGrid控件：在一系列行和列中顯示數據，最簡單的情況就是當網格綁定到具有單個表（不包含關系）的數據源，在這種情況下，數據顯示在簡單的行和列中，就像在電子表格中。</p><p><b>　

98、　第六章 系統(tǒng)測試</b></p><p>　　程序設計結束之后，為了確保其正確性和運行的健壯性，需要對軟件進行調試和測試。測試是為了在軟件產品投入運用之前，盡可能的發(fā)現(xiàn)軟件中的錯誤，是保證軟件質量的關鍵步驟。但是，發(fā)現(xiàn)錯誤并不是程序設計的最終目標，程序設計的目標是高質量的盡最大可能符合客戶的需求。因此，通過測試步驟發(fā)現(xiàn)的了錯誤之后，不許對錯誤進行診斷和糾正，這就是調試的目的。測試和調試工作也是軟件

99、工程中極其重要的工作，它所花費的工作量占總工作量的40%以上，結合編程中遇到的一些問題，制定了一些方案對程序進行了調試和測試，結果比較理想。</p><p>　　6.1 系統(tǒng)測試概述</p><p>　　系統(tǒng)功能測試是對系統(tǒng)進行試運行，其目的是對新建的系統(tǒng)進行從上到下的全面測試和檢驗，看它是否符合系統(tǒng)總體涉及所規(guī)定的功能要求，發(fā)現(xiàn)系統(tǒng)中的錯誤，保證系統(tǒng)的可靠性。</p>&l

100、t;p>　　系統(tǒng)測試主要分為兩個大的方面來進行測試：功能測試，界面測試。在功能測試中，被測試對象的設計較為充分。設計的決策和分支的種類較多，被測對象的規(guī)模也較大；在界面測試中，不僅進行正常操作方面的測試，也進行許多非常規(guī)操作的測試。</p><p>　　6.2 系統(tǒng)測試方法</p><p>　　軟件的測試一般分為兩種方式:黑盒測試(功能測試)和白盒測試(結構測試)。黑盒測試時把程序看

101、成是一個黑盒子，不考慮程序內部的結構和處理過程，只檢驗各個功能是否都正常的使用。白盒測試時把程序看成一個白盒子，完全了解程序內部的結構和處理過程，按照程序內部的邏輯測試程序。</p><p>　　我在這里主要是以對模塊的功能進行測試為主要目標，當然也兼顧程序結構的合理和好用性進行了測試主要是設置斷點跟蹤和輸出程序執(zhí)行的結果。通過使用斷點跟蹤可以找到程序的出錯位置，縮小查找錯誤的范圍，提高調試的效率。輸出結果是在自

102、己的程序代碼中生成調試輸出。</p><p>　　在調試方面，本設計中調試的基本策略主要有:</p><p><b>　　★ 試探法</b></p><p>　　分析錯誤征兆，猜想故障的大致位置，然后用調試技術，獲取程序中懷疑的地方附近的信息。</p><p><b>　　★ 演繹法</b><

103、/p><p>　　演繹法是從一般原理或前提出發(fā)，經過卸載和凈化出發(fā)，經過卸載和凈化的過程推導出結論。用演繹法調試，開始先烈處副哦有看來可能成立的原因或假設，然后一個一個的排出列舉出的原因，最后，證明剩下的原因確實是錯誤的根源。</p><p>　　演繹法主要有下述二個步驟:</p><p><b>　　★ 想可能的原因</b></p>

104、<p>　　根據已有的數據，設想所有可能的產生錯誤的原因。在著異步并不需要用這些假設解釋各種現(xiàn)象。</p><p>　　★ 已有的數據排除不正確的假設</p><p>　　仔細分析已有的數據，特別要注重尋找主要矛屑，力求排出全部列出的原因。如果所有列出的假設都被排除了，則需要補充數據來證明已提出新的假設。</p><p><b>　　★ 分析假

105、設</b></p><p>　　假設事實，證明假設的合理性是極端重要的，不正當方法根據假設排除故障，往往只能消除錯誤的征兆或只能改正部分錯誤。證明假設時，用它解釋所有原始的測試結果。如果能圓滿的解釋一切現(xiàn)象，假設就得到證實。</p><p><b>　　6.3 測試內容</b></p><p><b>　　1.測試環(huán)境&l

106、t;/b></p><p>　　將程序單位的所有程序以及用到的公共子程序安裝到指定的測試環(huán)境，該環(huán)境應與程序實際運行環(huán)境一致：將系統(tǒng)編譯成可執(zhí)行文件。</p><p><b>　　2.功能測試</b></p><p>　　對于所有菜單、工具欄測試觸發(fā)彈出的界面是否正確，每個功能界面的按鈕、選擇項功能是否正確；檢查數據項的關聯(lián)與限制功能是否

107、正確；測試用戶登錄、連接數據庫、數據管理、數據統(tǒng)計、表單生成等功能是否能順利完成。</p><p><b>　　3.正確性測試</b></p><p>　　有寫/刪除操作的程序，測試寫/刪除操作的結果是否正確。測試時應手工打開數據庫表，以檢查寫/刪除的結果；有查詢、統(tǒng)計、等操作時，檢查在各種選擇項的合理組合下，所產生的結果，對照數據庫中的數據是否正確；對照本系統(tǒng)的要求

108、，測試程序是否正確。</p><p><b>　　4.可靠性測試</b></p><p>　　非常規(guī)操作容錯測試：嘗試一些非常規(guī)操作，例如查詢的起始日期大于終止日期，檢查程序的容錯功能。異常數據容錯測試：嘗試一些非法數據的輸入，例如非法的年、月、日的輸入等，檢查程序是否有容錯能力。</p><p>　　程序負作用檢查：退出測試程序后應恢復到進入

109、前的系統(tǒng)狀態(tài)，不應影響其他程序的正確運行；退出程序后在本地和服務器的有關目錄或TEMP目錄下不應留下任何無作用的文件。</p><p><b>　　5.性能測試</b></p><p>　　性能測試在軟件的質量保證中起著重要的作用，它包括的測試內容豐富多樣。中國軟件評測中心將性能測試概括為三個方面：應用在客戶端性能的測試、應用在網絡上性能的測試和應用在服務器性能的測試

110、。通常情況下，三個方面有效、合理的結合，可以達到對系統(tǒng)性能全面的分析和瓶頸的預測。</p><p>　　由于本系統(tǒng)規(guī)模較小，客戶端數據有限，無需進行多人海量測試，就進行了客戶端添加若干條客戶記錄，添加進貨、維修、倉庫信息生成進貨單、維修單、轉倉單等詳細記錄的測試。通過測試證明：性能，響應速度以及處理能力已經滿足客戶的要求。</p><p><b>　　6.4測試結果</b&

111、gt;</p><p>　　由于系統(tǒng)前期的分析與設計做得比較透徹，按照系統(tǒng)設計完成的編碼后，通過測試已經基本排除邏輯等方面的錯誤。本次測試的前期僅發(fā)現(xiàn)該項目存在較少不完全正確的地方，其功能測試基本合格。同時，界面操作中的個別操作存在一些錯誤，測試后已經修正，問題都得到解決。對汽車維修保養(yǎng)管理系統(tǒng)各項功能測試的結果表明，系統(tǒng)設計合理，各項功能都符合系統(tǒng)設計目標的要求，能夠有效地對公司業(yè)務的相關數據進行有效管理，并為