小型超市及零售行業信息管理系統的設計與實現

發布時間：2023-01-03 10:31

第一章緒論 1

1.1 項目背景 1

1.2國內外發展和研究現狀 1

1.2.1 國外發展情況 1

1.2.2 國內發展現況 2

1.3 工作的主要內容 4

1.4 論文結構 5

第二章技術概述及介紹 6

2.1 C/S 與 B/S 介紹 6

2.2C#語言介紹 6

2.3.NET Framework 8

2.4Microsoft Visual Studio（簡稱 VS） 9

2.5UML 建模工具 VISIO 9

2.6SQL2005 數據庫介紹 10

2.7本章小結 10

第三章系統需求分析 11

3.1 業務調研及基本需求分析 11

3.2 功能需求分析 13

3.2.1 角色定義 13

3.2.2系統維護功能 14

3.2.2.1操作員設置 14

3.2.2.2用戶密碼修改 15

3.2.2.3數據備份與恢復 15

3.2.2.4系統日志 15

3.2.3基礎信息 15

3.2.4采購管理 16

3.2.5銷售管理 18

3.2.6庫存管理 19

3.2.7財務結算 21

3.2.8決策管理 22

3.2.9系統功能結構 23

3.3非功能性需求 23

3.4可行性分析（技術、經濟、操作） 24

3.5本章小結 25

第四章軟件設計 26

4.1 軟件設計遵循原則 26

4.2體系結構及網絡設計（C/S） 26

4.3系統的組成 27

4.4系統數據庫設計 28

441數據庫結構設計（E-R圖） 28

4.4.2數據庫表設計 33

4.5系統功能詳細設計 39

4.5.1類圖 39

4.5.2時序圖 39

4.6本章小結 44

第五章系統的實現 45

5.1用戶登錄功能 45

5.2系統功能 48

5.3信息檔案 53

5.4采購管理 56

5.5批發銷售 59

5.6庫存管理 61

5.7財務結算 64

5.8決策分析 65

5.9本章小結 66

第六章系統功能測試 67

6.1系統測試目標 67

6.2系統測試基本原則和方法 67

6.3測試準備和測試計劃 68

6.4軟件測試 69

6.4.1功能測試 69

6.4.2性能測試 74

6.5測試結果 75

6.6本章小結 75

第七章總結與展望 76

致謝 78

參考文獻 79

第一章緒論

1.1 項目背景

隨著計算機技術的不斷發展，傳統的生活和工作模式也在不斷的發生變化，城市城鎮化的趨勢使得人口密集度越來越高，物質的流通速度和流通量也越來越大。隨著我國產業升級的變化，勞動力成本越來越高，無論什么行業，光靠增加勞動力來解決業務量的增加是不現實的，利用科技產業，使用技術和工具提高生產力才是最有效的辦法。信息技術的發展和成熟，大大節省了時間成本，規范了管理，提高了工作和運營效率。

零售業因為其門檻較低，需求旺盛，所以從業人數多，分布廣，規模也是大小不一。隨著業務量的增發，手動記賬不但速度跟不上，而且容易出錯，貨物混亂，人員疲憊。大規模的零售商場諸如家樂福、沃爾瑪、華聯等都有專業的軟件開發團隊為其提供軟件服務，中型的連鎖店也有定制的軟件服務為其提供保障［1］。小型零售雖然店鋪小，但是業務并不比大型商超簡單，隨著業務量增長，也會零售集批發一起，麻雀雖小功能齊全。但因為其軟件規模小，收益薄，售后麻煩，市面上可供選擇的零售管理系統不多，而且功能簡單，價格偏高。我們所處的時代是信息大爆照的時代，信息化是一種趨勢，將會滲透到我們生活的方方面面［2］。

本次畢業設計就是根據目前行業的這樣的一個市場情況，根據現階段中小型超市日常管理的需求，基于C#設計語言的強大開發功能和SQLServer的數據管理技術做一個零售超市的信息管理軟件。另外，超市是比較典型的零售業，集商品、買賣、批發，庫存、資金、報表、決策等業務類型于一體，開發基于超市業務的信息管理系統，其功能可以適用很多類似如五金店、化妝品店、玩具店、書店、煙酒店、衣帽店等，兼容適用性強，實用意義較大。因此，課題以超市業務展開。

1.2國內外發展和研究現狀

1.2.1 國外發展情況

超市這個概念來自于國外，出現于 20世紀 30年代，因為工業化進程比較早，消費市場發展較快，隨著生產效率的提升，通過信息化提升管理效率的需求顯得尤其緊迫。條碼識別技術和 POS 機的使用加快了整個行業的發展水平，伴隨網絡通信技術的成熟，以及硬件服務器性能的提升，信息管理系統由之前的簡單數據記錄發展為集采購、生產、銷售、物流為一體的跨地區、多業態、多組織形式的，可以同時實現數據共享、任務協同的智能化數據處理中心［3］。信息化技術最早在大中型和中高端企業中得到重視和使用。國外大型零售賣場比如沃爾瑪，早在 20 世紀 80 年代就購置了自己的專用衛星來構建自己的信息系統，后期與IBM合作開發了專用的EOS系統，與寶潔公司建立了及時補貨系統 KARS,還使用了前臺管理POS系統，數據庫管理系統，電子自動訂貨系統EOS，自動補貨系統，有效客戶反饋系統 ECR 等，整個信息系統功能強大，結構復雜［4］。國外知名軟件服務商SAP也有專門針對零售業務的軟件方案，主要針對跨地域的集團零售業，包括采購、銷售、庫存、商品、人力資源、財務、設備等，需要專業的信息技術團隊進行實施和后期維護，投入較大［5］。

美國的零售業集中度很高，因為產業發展的早，在信息化方面做的很好，早先發展起來的比較大的零售巨頭在管理方法和技術方面為小型零售店帶來很好的啟發，整個行業在在自上而下的良性促進模式下得到了突飛猛進的發展。無論是實體店的管理水平還是信息化系統的建設和普及使用率，美國在一直處與世界領先水平［6］。在軟件產的選擇方面，不同規模的零售店在市場上都能很容易找到功能齊全、服務質量好、信譽高、性能穩定的軟件產品，如果有個性化需求也能很好的得到滿足。在功能和服務方面，更多的零售店通過互聯網和信息技術，或建立自己的網上門戶，或建立微平臺建立合作推廣，比如Amazon，星巴克等，都加大投入，進行線上線下聯動，增加了銷售的渠道和范圍。

社會的高速發展帶動消費的擴大和升級，作為大型超市的補充，小型超市因為選址的靈活性和便利性，發展迅速。因為大型超市的信息化實現和技術的普及，小型超市的信息化也有了突飛猛進的發展，超市信息管理技術也明顯優于其他次發達和發展中國家。不同發展規模的超市都有相匹配的比較成熟的管理系統，幾乎所有零售店都實現了數字化管理，效率很高［7］。

1.2.2 國內發展現況做為世界最大的經濟體之一，我國目前處在一個快速發展的階段，隨著國民收入的不斷增加，消費市場零售總額數據也是逐漸攀升，呈現多樣化和連年高速增長的態勢。據商務部統計相關數據， 2014年超市行業銷售增長幅度為 5.5%， 2015 為 6.8%， 2016 年為 6.7%，雖然增速放緩，但仍呈現依舊逐年遞增的趨勢。因為電商的沖擊，線上購物分走大批流量，超市行業逐漸呈現兩極分分化的態勢，超大體量超市因為品類豐富購物體驗好，雖然開店速度放緩，但銷售收入依然在增長， 2014-2016 年銷售額分別為 4.04%， 2.97%， 3.32%，中型規模的店鋪在吸引客流量方面力量稍弱，單體經營成本高，業績總體下滑，小的實體店業務因為資金投入小，管理簡單，經營靈活，線上線下業務融合業務量增加，總體收入增速達到 9.6% 的增長，比美國高出7.5個百分點，比日本和歐盟百分比分別高出11和7.6 ［8］。阿里，京東等商界大鱷也開始逐漸向線下滲透，開始布局自己的零售店，或者與現有零售店展開合作。比如阿里投資了蘇寧云商、三江購物、銀泰集團、聯華超市等，與這些零售業的現在又的供應鏈系統和支付方式進行對接，進行數字共享和改造。

目前國內 ERP 從規模、市場、服務、口碑等幾個方面綜合比較，做的比較好的有金蝶、用友等，這些公司的業務滲透了制造、建筑、金融、醫療、貿易、交通、零售等各行各業。用友的U8,金蝶的KIS功能類似，優點是契合中國零售業的特點，針對大中小零售企業，支持在線、離線的管理模式，包含經銷商管理，終端管理，物料配送、補貨，店面管理、零售出入庫及核算管理等功能，支持自營銷售、加盟分店、專柜銷售等多種形式的銷售模式。功能齊全，有專業的銷售和服務團隊，但是每年都要定期按時繳納服務費，成本較高［9］。因為零售業的普遍存在和信息技術的廣泛應用，市場和網絡上存在著很多商家自主開發的小的超市管理系統，規模不一，功能各異，質量參差不齊。購買后可以使用，但因為規模小，商家質量和服務沒法保障，維護升級更是問題，使用起來特別不方便。如果在網上搜索，甚至還能下載到一些免費的單機版的試用軟件，但是如果用在實際業務當中，可靠性安全性都不能保證［10］。

我國超市行業信息化水平可以根據業務總量劃分層次進行說明。大型企業有著完善的制度，規范的流程以及先進的進銷存和資金業務體系，都有自主研發或者定制的軟件，投入巨大，功能強大，所有的數據流和信息流以業務和管理為導向在企業內部流轉匯聚，對企業正向促進，面臨的問題是數據挖掘和深加工，財務集中一體化以及企業并購重組后的數據統一和安全問題；中型企業資源逐漸集中，在信息化方面功能逐漸完善，購買使用成熟的軟件方案及產品，預算充裕，維護及時，安全可靠，注重上下游產業信息的鏈接融合，以數據獲取和分析為主。低端零售業規模小，分散經營，因資金方面問題的限制沒有得到高度的重視，信息化的認識和理解局限于工具本身，或者在低端市場購買功能單一，沒有資質的小型信息管理系統，或者直接采用傳統的手工記賬進行店面管理，對業務流程和信息建設缺乏長遠的規劃［11］。據統計，近十年我國實體店的數字化管理呈現高速發展的態勢，但截至到目前，整體數字化程度沒有突破60%,低于同期歐美發達國家水平。

小型的零售店在選擇信息管理軟件的時候綜合考慮功能和成本之間的平衡，操作簡單、功能好用，價格低廉的軟件最受歡迎。零售行業因為商品交易的不同對應軟件的功能可能會存在差異，不同規模的超市對系統需求定義也是千差萬別，具有一定體量和資金實力的公司會量身定制符合自己管理特點和要求的軟件產品，耗資可觀。對大的軟件提供商來講，小而散的零售店經營變化快，體量小，不成規模而且對價格敏感，維護起來成本相對較高，所以合作相對較少。對小的軟件提供商而言，因為市場占有率不高，品牌形象弱，也很難做大做強，普及率不高。所以針對特定規模，業務明確的零售店的軟件管理系統市場需求量很大［12］。

近幾年隨著國家對新興產業的支持，信息技術的發展速度呈現爆發式的增長，大量的技術人員進入這個行業，很多傳統行業的生產經營模式和管理方法逐漸被軟件化，流程化、數字化。生產制造、市場貿易等大規模經濟體實現信息化相對較早，信息化程度比較高，技術與業務相結合，實現了產業融合再造［13］。各行各業雖然經營實體存在差異，但是市場本質相同，人機料法環，或一致或取其部分內容，關乎人與物，關乎進銷存，以及流程數據等，這些業務幾乎涵蓋了超市的各個方面。技術通用，模塊應用可借鑒，這些都使小型超市管理系統的開發和實現成為了可能［14］。

1.3 工作的主要內容

隨著我國經濟的不斷發展，國民消費能力不斷加強，生產和消費的方式也在不斷的發生變化，傳統行業不會消失，只會更換方式競爭的更加激烈。超市遍布在我們生活的各種場所，為我們提供食與用，如何通過信息技術最大化的提高店面效益，降低成本是本次課題需要思考解決的問題。

在了解了超市行業發展情況和信息化水平的前提下，對項目要解決問題的目標和范圍進行定義。根據工作量和項目周期制定詳細的開發計劃，做好功能需求調研，積極查找資料和相關文獻，做好知識和技術儲備。此次設計的超市及零售行業信息管理軟件定位小型超市的使用場景，結合目前大多實體店的通用業務以及未來可能使用到的基本功能，從用戶登錄、物料采購、庫存管理、銷售管理、財務結算等多方面進行產品研發，實現經營數據明晰可見，經營情況一目了然，幫助經營者及時了解貨物和財務動態，快速調整產品結構，為適應市場和做決策提供依據。

此次軟件開發是以軟件工程開發思想和方法作為指導，結合生活生產需求，將理論和技術轉化為管理工具，具有非常有價值的實用意義。軟件開發過程的工作主要有：功能需求分析、總體設計、詳細模塊設計、軟件實現、系統測試等，每個過程完成后都要有相關的文檔進行跟蹤記錄。

1.4 論文結構

按照軟件設計的思路和方法，論文按章節對開發過程中涉及到的內容、技術

和成果進行說明，總共七章，各章的主要內容如下：

第一章，緒論。介紹選題來源和背景，以及研究對象作出行業的國內外發展現狀，對本次項目開發的工作內容做簡要介紹。

第二章，技術概述及介紹。分析對比 B/S 和 C/S 兩種體系結構的特點和優缺

點，結合實際業務選擇合適的開發模式。介紹軟件開發使用的相關技術和工具。

第三章，系統需求分析。對軟件需求、軟件功能及管理流程進行梳理和定義，對系統開發進行可行性分析等。

第四章，軟件設計。完成系統的總體設計和詳細設計。確定系統結構，根據需求分析得出系統要實現的功能模塊，設計數據庫表，列舉類圖和時序圖。

第五章，系統的實現。列舉系統中各個子模塊的設計成果，通過程序流程圖和部分代碼隊實現過程做進一步說明。

第六章，系統功能測試。介紹使用的軟件測試方法，對各子模塊進行測試用例分析，對系統性能和總體功能進行評價。

第七章，總結與展望。結合需求說明、測試結果和使用體驗，對軟件功能和

性能進行評價。回顧軟件開發的過程，總結經驗發現不足。

第二章技術概述及介紹

本章節主要介紹軟件開發的模式，使用的開發語言、建模工具及所采用的數據庫等信息。

2.1C/S 與 B/S 介紹

常見信息系統的體系結構有 C/S 架構和 B/S 架構這兩種，不同使用場景和用途的信息系統在選擇體系機構時會有不同的要求，在軟件開發過程中也會存在較大的區別。

C/S即Client （客戶端）/Server （服務端），應用程序分客戶端、服務端兩部分。客戶端的主要功能是界面顯示、數據展示以及處理一些邏輯業務，服務端的工作主要體現在對后臺數據庫的管理和操作，常見操作如增加、刪除、查詢及更改等。用戶使用客戶端輸入數據，服務端連接客戶端并接收客戶端指令，然后按照一定的規則處理數據，完成后將結果返回至客戶端并顯示。在 C/S 模式下，客戶端主要用來處理來自用戶的簡單重復任務，性能方面要求比較低，服務端處理更加復雜的計算和管理功能，硬件配置要求則比較高。C/S是兩層機構，通過硬件資源和軟件任務的合理分配實現了資源利用的最大化，系統反應速度較快［15］。

B/S即Browser（瀏覽器"Server （服務端），與C/S的兩層機構不同，一般由瀏覽器、中間組件、服務器三層結構組成。瀏覽器負責數據顯示，中間層連接和傳遞數據，數據庫處理數據。用戶可以便捷的使用瀏覽器訪問后臺服務而不需要安裝專門的客戶端程序°B/S模式后于C/S發展起來，因為訪問途徑是瀏覽器，所以對客戶端電腦的性能要求較低，使用便捷，推廣更加容易［16］。

綜合比較 C/S 與 B/S 模式的特點、對硬件的要求等屬性，結合此次小型超市管理系統的功能特點和使用場景，選擇C/S模式作為軟件的結構模式，原因如下: 中小規模的超市或零售店，一般是局域網內的單臺或者多臺電腦使用，業務和使用規模小，聯網需求小。

基于普通的 WINDOWSDE 計算機進行開發和使用, 高適用，操作簡單，便于維護性，硬件要求低， C/S 結構下的客戶端本地響應速度快，效率高［17］。

2.2C#語言介紹

C#是由微軟推出的基于.NET Framework的面向對象的高級程序設計語言，具備類似 VB 的可視化操作性以及高運行效率的特點，開發人員可以使用它在 MICROSOFT .NET 平臺上編寫各種應用程序。

C#由C和C++衍生而來，延續了 C和C++的很多優點，同時摒棄離了很多復雜性。C語言被編譯成機器二級制機器碼后能直接在機器上運行，C#不能操作內存地址，運行時首先被編譯成為中間代碼，然后通過.NETFramework的虛擬機將中間碼翻譯成為二進制代碼，從而使它得到正確的運行，這點與JAVA類似［18］。

C#具備同Java 一樣的諸如封裝性，可繼承性以及典型的垃圾回收機制等優點。在目前的開發環境下，C#如JAVA適用非常廣泛，無論是復雜的大型系統還是簡單的小型系統都可以通過它來開發實現，我們通過比較對這兩種語言進行說明［19］。

a)跨平臺特性

Java 的一大特點就是跨平臺性，在軟件開發和使用過程中，每個機器硬件配置不可能完全一樣，面臨的操作系統如 Windows、Linux、Unix 等也是各不相同，無論是什么配置下的什么環境，只要機器上安裝了 JVM， JAVA 程序只要編譯一次就能實現平滑無縫運行，兼容性很好。

C#也有跨平臺性，主要針對的是Windows平臺下的不同版本的操作系統，只需安裝一個.net framework，在Windows7下編寫的.net程序不用重新編譯在 Windows8 下就可以直接運行，開發維護或者使用都非常方便。

b)IDE (軟件集成開發環境)

Java 常用的的 IDE 有：Eclipse、Myeclipse、Jbuilder、Jcreator 等，選擇比較多oC#的IDE用的最多的是微軟自己的VS.NET，之外還有Borland的C#Builder 等其他工具。兩者的IDE功能都比較成熟。

c)語法應用

兩者語法類似，不同點在于，Java棄用了指針，定義使用包(package)的概念，C#沒有將指針完全棄用，使用名稱空間(namespace)的概念對類進行管理。 JAVA使用import語句對類進行調用，C#使用的是using語句。Java和C#中都存在屬性的概念，除此以外，C#還有索引，使用起來非常方便。

d)性能方面

Java和C#都要經過編譯然后執行，在運行速度和效率方面，兩個沒有太大的差異，對一些小型系統，C#的性能略高于Java。

總體來講，雖然C和C++運行效率要高于C#，但開發效率相比要低，安全性也要考慮更多內容，而且不支持跨平臺，適用性不高。JAVA雖然在跨平臺方面有明顯優勢，但是只有在JDK環境下才能使用，需要配置的東西也相對復雜，對硬件性能也有一定的要求，一般在比較大型的需要考慮市場環境多樣性的開中選擇比較多［2°］, C#完全的基于Windows，功能全，門檻低，對編程人員來講適用性更強，因此本次選擇C#作為開發語言。

2.3.NET Framework

• net包含的意義比較廣泛，如：.NET服務，.NET體驗，.NET平臺等，一般情況下，我們提到.net時如果不做特殊說明默認指代.net平臺。• net平臺是微軟公司基于Windows操作系統，為了實現Xml、Web Services以及SOA敏捷性而開發的，是.NET家族的核心，也是整個系統架構的基礎。通常我們也稱.net為.NET 框架(.NET Framework)，在計算機的所處位置如圖2-1所示：

圖2-1 .NET Framework在計算機中的位置

.net中包括了兩個非常重要的實體：.NET類庫和CLR。CLR是.Net Framework 的底層，定義了多種常見編程語言通用的數據類型，能過支持 VC++、 VB、 j#、 C#等多種語言的應用開發。

不同語言編寫的類在平臺上可以相互繼承和調用，具有平臺無關性，能夠實現跨語言和混合編程。.NET Framework類庫在CLR之上，分為不同的模塊，提供包括數據訪問和構建應用等數千個類和組件工具供程序員使用。我們以.net中C# 的編譯過程為例說明［20］，見圖 2-2 所示：

C#源程序（.cs文件）

C#編譯器（.exe文件）

|CLS（共用語言運行規范）

CLR （公共語言運行庫）

JIT 編譯器（二進制碼）

操作系統

圖2-2 C#在.net中的編譯過程

2.4Microsoft Visual Studio （簡稱 VS）

VS是由微軟開發的軟件平臺，主要適用Windows應用軟件的開發，包含了集程序設計、代碼編寫編譯以及調試等軟件開發過程中幾乎所有需要使用到的開發工具。為了更加方便的進行產品開發，微軟將.net框架集成到VS當中，不同版本的VS有對應默認的.net框架。VS從2003版本開始支持C#語言程序的開發，我們選用VS2005作為此次開發使用的工具。

2.5UML建模工具VISIO

UML又稱統一建模語言，是面向對象軟件的標準化建模語言［21］。是一種圖形化語言，用來描述系統從需求分析到系統設計和實現的不同階段，為軟件開發過程提供模型化和可視化支持［22］。

在軟件的設計開發過程中，為了更好的描述事務，我們會有一個將實物抽象畫的過程，通過建模的方式定義對象，利用系統模型靜態和動態的不同側面反應他們之間的關系和過程，最后綜合反映一個整體，為系統的最終實現提供依據。系統建模貫穿項目開發的生命周期，可以有效的縮短項目開發和調試時間，縮減開發費用©I。

Office Visio是office系列中專門用來繪制流程圖、示意圖的軟件，在軟件設計開發過程中，我們常用來繪制軟件功能模塊圖、用例圖、時序圖、類圖以及程序流程圖等［24］。是一款非常實用的軟件，能夠很好的展示業務和數據邏輯，通

過各種框圖、線條、符合等元素化展示軟件開發過程中的進度、流程、關系等［25］。

2.6SQL2005 數據庫介紹

數據庫是一個管理系統，也是一個工具，主要實現對數據的組織、存儲和管理，在信息系統的開發和使用中占據非常重要的作用［26］。目前廣泛被認可和使用的數據庫主要是關系型數據庫是，比較常見的有：甲骨文 Oracle 數據庫，微軟的 SQLServer，IBM公司的DB2，MySql數據庫以及小微型的Access和Excel等［27］。 Oracle比較復雜，業務和數據處理能力強大［28］，和DB2 一樣通常在大型企業級應用及軟件開發過程中使用，不同的是DB2 一般用在IBM自己的服務器上，對硬件有苛刻要求［29］。sql serve屬部門級數據庫，自帶終端平臺，在圖形化管理方面有非常出色的表現，功能強大［30］。 Access 功能簡單，處理數據一般在十萬級別，屬于小型數據庫，適用一些小功能應用的開發［31］Excel可以作為數據庫使用，處理一些簡單的數據報表等，小型企業和私人業務應用比較多［32］。此次軟件開發基于家庭適應版的計算機，軟件規模不大，考慮到開發效率，我們選擇SQL Server 2000作為系統的數據庫系統。

SQL Server2000 是微軟公司推出的比較早版本的關系型數據庫產品，在數據交互和管理方面表現出色，被廣泛應用。很多早期發展發展起來的比較知名的應用系統如用友的 ERP 就是通過 sql2000 進行數據管理的，在諸多領域經受了諸多專業的考驗［33］。因為其體積小、簡單易用，快速穩定，功能成熟，目前在稍小規模的開發任務中仍有不少的用途［34］。 SQL Server2000 有不同的版本，我們此次選擇企業版(Enterprise)進行開發。

2.7本章小結

本章從軟件體系結構、程序設計語言、軟件開發技術、軟件開發工具、系統建模工具以及數據庫選用六個方面對此次系統開發所涉及到的技術、平臺和工具進行介紹和說明，為后續的開發工作做好準備。

第三章系統需求分析

本章節對超市日常經營的管理需求進行梳理，通過可行性調研和功能功能性需求和非功能性需求的多角度分析，完成業務需求內容。

3.1業務調研及基本需求分析

大型連鎖綜合性超市不在我們此次研究分析的范圍內，如沃爾瑪、家樂福、人人樂、永輝等。通常的地方性連鎖便利店例如紅旗、舞東風等因為已具管理規模，信息化水平比較高，也不在我們此次考慮在列。在零售行業當中，以家庭式式的單體或多店經營的情況居多，主要售賣日化、小吃、文具、煙酒、糧油等生活常用品，根據所處的地理位置、人口密度、人口分布、店面大小不同等經營范圍和管理方式各不相同。走訪社區和街道各個零售店，經營方式的多變性和靈活性以及地方區域的局限性，使得經營者對信息管理系統的需求存在差異性。信息化在我們生活中無孔不入，手機支付的普及使我們的生活更加便捷，傳統低效的管理手段也在慢慢被被新的技術革新和替換，伴隨經濟的高速發展，國民消費升級，消費品行業的競爭日劇激烈，如果想要不斷適應消費市場，增加營業額，增加利潤，增大店面規模，在以后的發展中站住腳，就必須重視信息化管理手段，通過計算機信息系統解決好采購、銷售、庫存以及財務等各方面的問題［35］。

我們隨機選擇一個社區街道邊和小區里邊的三個比較與代表性的零售店進行業務描述：

1）面積150平，位置：街道邊，主營：零副食、糧油、日化、煙酒、廚房用品、文具、玩具、水果、各類散貨等。超市周邊有幾個較大的社區，物品種類復雜，日營業額在 8000 左右。超市由老板和兩個店員打理，兩個人一班。所有貨物由供貨商周期性的進行供貨和補給，所以倉庫不大，主要用來存放快銷產品如水，飲料啤酒以及個暢銷副食等。除了零售外還與一些單位有合作關系，會簽訂一些簡易協議進行供貨。與不同的供應商會按照月結、現結的方式進行結算。目前店里使用 POS 機進行售貨，管理員在后臺能夠看到每天每周的營業額和大概的利潤，營業額以現金交付為準，只要和后臺營業額數據一致即可，店中有攝像頭，對店面情況、銷售情況和收銀情況進行記錄。店里發售免費的會員卡，當積分累積到一定的水平后可以減分兌換貨物。店面采購、銷售和結算行為通過賬本記錄。會根據供應商支持或者銷售情況進行促銷活動，供貨商每周會來店里根據銷售情況自行補貨，倉庫貨物具體數據不詳，根據季節銷售經驗進行補貨。需求：能夠實時了解店鋪當中的貨物存儲數量，實現賬實相符；能夠獲得所有貨物銷售情況，了解快消和滯銷產品目錄，了解附近居民消費特點；能夠獲得不同產品在不同時間按照周、月、年等時間唯獨的銷售情況，了解超市經營的季節特點；能夠獲得各個不同供應商的供貨情況和交易金額，能夠方面查到不同客戶的交易情況。

2）面積90平，位置：小區內，主營：零副食、糧油、日化、調味品、煙酒等。家庭經營，夫妻店。使用 POS 進行銷售，用來顯示價格，營業額和支出通過賬本記錄，與供應商進行現結。有批發業務，但是業務量不多。補貨需要提前進行排查統計，給供應商提供貨物名稱和數量，由供貨商打包提供。需求：每次統計需要逐個貨架排查貨物銷售情況非常麻煩，希望系統有最低庫存預警功能，當貨物小于設定值時系統提示，可以及時獲得補貨明細；能夠看到每天、每周、每月、每年的營業額和利潤情況，能夠看到分類銷售的利潤和占比。

3）面積 40 平，位置：小區門口，主營：各種零副食、面包、煙酒、飲品、日用品、禮品、工藝擺件等。一人經營，有庫存，主要是飲品、禮品和工藝品等。進貨渠道有供應商供貨和自行采購兩種方式，需求：禮品和工藝品會隨著季節或時節日變化，系統如果有調價功能可以方便銷售。覺得目前簡單的 POS 也能夠滿足基本的需求，如果軟件資金投入較低，能夠有更多的功能可以接受購買或開發。

綜合以上不同規模店鋪的經營習慣和需要，我們發現，規模越大，日常事務越復雜，對軟件的依賴度越高，對信息化投入的接受度也相對較高。對使用者來書說，軟件功能的訴求一致為：低成本，維護簡單，容易操作。從開發者的角度來講，新設計的系統不但要能夠滿足基本的買和賣業務，而且要考慮店面擴張以及業務擴展后的各種要求。根據以上調研內容，我們得出系統開發工作過程需要實現下幾個內容：

a）系統界面和結構簡單，不需要專門花很長時間進行培訓就能很快熟練操作。每

日進出超市的人流量比較多，商品種類繁多，單筆營業額較少，工作人員每天不但要進行上貨、賣貨，清貨，還要指引服務消費者進行取貨、退貨等，事務繁多。系統操作簡單能夠節省操作員操作時間，減少單筆交易和客戶排隊等候的時間，提高服務質量。

b）提供報表匯總和查看功能，滿足各類數據查看需求，使經營者能夠及時了解超

市商品和財務情況，為經營發展提供供策略依據

c）控制開發和維護成本，考慮用戶硬件使用環境和使用成本，最大的普惠用戶；

個體經營市場抗風險能力很小，受房租、上下游市場及周圍的環境影響很大，利潤微薄，所以經營者一般對投入和產出非常敏感，尤其是注重短期影響。

所以在軟件購買時會非常慎重，價格不能太高。

d）制作對應的操作手冊，為用戶提供使用說明文檔支持。便利店事務繁多，一般不適合也不愿意花過多的時間用在學習適用一款工具上。簡單的操作手冊可以幫助他們快速自學或者熟悉操作。

梳理流程，從根本上解決經營者痛點，開發出適用、有效的功能模塊。我們的定位是普通的小型超市，所以在定義功能的時候更多的是從實際應用出發，考慮的是最基本的功能以及未來店面擴展后可見的最常見業務和軟件能夠解決的問題［36］。功能適用不宜多。

3.2 功能需求分析

超市的功能是實現貨物的買賣和結算，匯總不同規模超市的管理需求，結合進銷存的經營理念，我們對系統要實現的功能進行模塊化分析和說明［37］。

3.2.1角色定義

系統中不同的功能模塊會對應不同的用戶角色，主要包括管理人員、采購人員、銷售人員、庫存管理人員、財務人員。系統向管理員具有系統管理的所有權限，不但可以對系統所有功能進行直接操作，如：新增用戶、維護基礎信息，備份數據、日志管理、單據錄入和審核等，也可以為其他操作員分配權限，如：向采購人員提供進貨管理功能，向銷售人員提供銷售管理功能，向庫存管理人員提供庫存管理功能，向財務人員提供結算功能等。角色實例圖如3-1所示。

庫存管理員

圖 3-1 角色實例圖

3.2.2 系統維護功能

系統維護模塊由管理員負責，對主要包括了對系統操作員的定義，對操作員權限的分配、對站點的設置、對系統數據的備份以及對日志的管理能。從宏觀上對系統的基礎設置和性能進行管控，模塊示例如圖3-2所示：

圖 3-2 系統維護用例圖

3.2.2.1 操作員設置

系統的管理員對系統中的其他用戶信息進行管理。可以在系統中新增用戶；對用戶角色進行定義，對用戶信息，如用戶編號、用戶名稱、用戶聯系電話、用戶住址等可用戶基本信息進行修改；可以刪除用戶。管理員根據操作員權限的不同賦予不同功能模塊中不同單據和系統的操作權限。對應用例圖如3-3所示。

圖 3-3 操作員管理用例圖

操作員管理業務流程圖如圖 3-4 所示：

圖 3-4 操作員管理業務流程圖

3.2.2.2 用戶密碼修改

系統管理員定義完畢，每個操作員都可以根據唯一的用戶名標識進入系統。管理員有對所有用戶的密碼進行重置和修改。修改密碼時需要提供舊密碼和新密碼，只有舊密碼驗證通過，且輸入的兩次新密碼一致密碼修改才能完成。

3.2.2.3 數據備份與恢復

系統中記錄了包括超市商品檔案這些靜態的銷售參考信息以及采購和銷售這些動態的與往來單位的交易信息，與超市經營活動密切相關。每個用戶使用自己的賬號與職責以內的模塊進行數交互，系統中每天還會有大量的單據和數據產生，能夠反應很長時間內超市的經營狀況，隨著時間的積累，系統中的數據會越來越多，這些數據也顯得越來越重要。為了防止數據丟失和破壞，周期性的對系統護具進行備份顯得非常重要。

3.2.2.4 系統日志

可以查看系統中所有操作員的操作信息，作為系統安全的補充管理，也可以對系統用戶行為進行監督。

3.2.3基礎信息

超市的基礎資料在系統一開始使用的時候就要維護進去，主要包括供應商資料，貨品分類信息、商品檔案信息、客戶基礎資料、倉庫信息等。供應商資料應

用于采購訂單錄錄入、驗收入庫單錄入等與采購業余有關的管理活動中，客戶資料應用于銷售訂單錄錄入、銷售出庫單錄入等與銷售業余有關的管理活動中。每一種基礎資料都有獨立的管理界面，所有基礎信息的維護由管理員負責，主要的操作有：增加信息、修改編輯、查看及刪除等。對應的用例圖和業務流程圖分別如圖3-5和圖 3-6 所示：

圖 3-5 基礎信息管理用例圖

圖 3-6 基礎信息管理業務流程圖

3.2.4采購管理

采購管理由具有采購角色的管理人員負責，在日常的采購業務中，主要的工作有：收集超市商品信息，統計要采購的品類和數量并及時與供應商聯系訂貨。

供應商按照指定的時間將商品送至超市，采購人員清點商品后進行驗收入庫。如果商品價格和之前的進貨價不一樣，供應商及時告知采購人員，采購人員要做相應記錄，及時調整成本和售價。如果有贈品，商家會指明告訴超市采購人員，這部分商品照常入庫，要做特殊說明。如果有需要退貨的商品，采購人員一起交給供應商，供應商退補相應差價或等價補足相應新的商品。采購管理用例圖和業務流程圖分別如圖 3-7 和圖 3-8 所示：

圖 3-7 采購管理用例圖

圖 3-8 采購管理業務流程圖

采購訂貨單：采購員根據采購需求在采購訂單中輸入要購入商品的名稱，規格和數量，信息無誤后確認審核單據，執行采購計劃。所有的采購記錄可以通過采購匯總表進行采購歷史查看。

入庫驗收單：當供貨商將貨物送至超市后，采購員可以按照訂貨單進行收入貨，并填寫對應的單價、數量和金額。入庫驗收單詳細信息可以一一錄入，也可以根據采購訂單號找到入庫對應的采購訂單，在驗收入庫界面自動帶出訂單中包含的商品信息。

贈送入庫單：為了推廣新品或者促進銷量，在節日或者新品推出超市會收到供應商的贈品，不同于正常采購入庫，采購員需要在系統中通過贈送入庫單對商品你進行入庫，沒有單價和金額，只有零售單價和零售金額。這類商品不會記入供應商財務結算，但是在銷售時會有收入。

進貨價調整：快消品價格隨市場變化很大，針對不斷變動的商品價格，業務員通過進價調整單進行調價。一方面為銷售價格的變動提供依據，另一方面更新與供應商的貨品結算金額，及時更新后臺信息，保證數據的一致性。

采購退貨：經管理員或倉庫人員核實后，有質量問題或與進貨信息不符的商品填寫相應單據并按照退貨流程處理。退貨單中需要填寫詳細的供應商信息，商品名稱、商品數量及金額。

采購信息查詢：采購員或者管理員可以按照供應商或者商品名稱進行查詢，查詢所有的采購記錄，也可以這是一定的時間段按照商品分類或者供應商進行采購歷信息匯總查詢。按照顯示的需求主要的字段有供應商名稱、商品名稱、規格、采購數量、采購金額、退貨數量、退貨金額、贈送數量、贈送金額等。

3.2.5銷售管理

銷售功能由具銷售角色的用戶或管理員進行管理，零售部分由POS進行出庫銷售，針對成批購買或者打包購買的用戶通過銷售訂單的方式進行銷售。銷售人員日常的主要工作有：拓展市場，與客戶達成銷售協議或合同，記錄合同，負責訂單出庫發貨，處理客戶退貨，對銷售數據進行匯總等。銷售管理用例圖和業務流程圖分別如圖3-9和圖 3-10 所示：

圖 3-9 銷售管理用例圖

圖 3-10 銷售管理業務流程圖

銷售訂單：超市與客戶達成銷售協議或簽訂銷售合同后，銷售管理員就要在系統中錄入對應的銷售訂單，對合作事項進行詳細記錄，作為銷售出庫和超市備貨的依據。

銷售出庫：銷售管理人員按照合同簽訂的內容為客戶交付商品，安排庫房管理打包發貨，交易完成在系統中錄入相應的銷售出庫單。填寫完畢后審核單據，系統中的庫房產品數量會減少。銷售人員對單據有：新增、修改、保存、查看，以及刪除等權限。

退貨單：在個別情況下，商品售出后客戶會因為改變主意、更換產品或這兩糾紛等進行退貨，這在經營活動中是比較常見的，為了提高服務質量和信譽，如果是商品質量問題，或非質量問題的前提下只要商品沒有被使用被破壞，在不影響二次消費的前提下，超市都會及時為客戶提供退貨服務。商品售出時會扣減庫存數量，退貨時錄入退貨單，一方面庫存數量會相應增加，另一方面，對退貨信息進行記錄，可以分析退貨原因，有助于維護提高超市聲譽。

售價調整：商品售價會隨著采購進價或市場變化情況隨時發生變化，及時在系統中價格進行維護才能保證銷售的正常進行。針對價格改變的狀況，銷售操作員或系統管理人員可以通過新增調價單對商品售價價格進行調整，在同一個客戶的前提下，一張調價單可以同時包含多條商品目錄，單據保存后，商品售價發生變化，商品數據庫相關信息同步更新。

銷售報表：主要的功能也是查詢分析。可以按照時間、客戶等字段進行單條件查詢或多條件組合查詢。

3.2.6庫存管理

主要是庫存查詢、盤點數據錄入以及商品保質期預警查詢功能，用例圖如圖

3-11 所示：

圖 3-11 庫存管理用例圖

庫存查詢：可以不設置任何條件查看整個超市的所有在庫物資，也可以設置條件，查看某一個供應商或者某一個具體商品的庫數量，還可以按照商品分類匯總查看某一類商品的在庫情況。庫存查詢功能靈活，能夠滿足多種查詢方式。庫存物料的顯示數據主要包括了：供應商、商品代碼、商品名稱、商品規格、在庫數量、庫存金額等信息。

庫存盤點：在超市經營過程中，經常會出庫存物資與賬面不符的情況，周期性的對貨品數量進行盤點可以及時獲知超市商品真實庫存，編制及時的采購計劃，重新計算超市實際的庫存資金。也可以根據盤點的情況進行管理分析，加強超市商品出入庫錄入的及時性，或加強超市的安防措施等。在盤點錄入單中錄入貨品實際數量，系統自動計算與庫存數據的差額，顯示盤虧還是盤盈。當盤點數量大于庫存數量時，系統顯示盤盈，當盤點數量小于庫存數據時，系統顯示盤虧。

保質期到期預警：在超市商品品類中，食品、飲料等占據了很大部分的陳列和庫存，這些商品的特點就是保質期短，更新速度頻繁。超市管理員要經常查看各類商品的保質期，在保質期到期前及時進行處理或退換。每種商品的到期日都不盡相同，手工排查不但工作量大而且也不能保障沒有遺漏。通過保質期預警單可以為系統管理員或超市庫存管理員提供超市全品類商品的入庫時間、到期日以及有效/過期日，也可以通過過濾的方式可以查看特定供應商或者特定商品的保質期到期情況，提醒管理者及時下架或更換產品，保證貨品質量。保質期預警報表極大的簡化了管理人員的操作，節約工作時間，提高了超市的服務質量和滿意度。

3.2.7財務結算

超市的經營伴隨著商品和資金的進出實現經營利潤，采購管理主要實現與供應商的商品交易過程和商品確認，銷售管理實現商品與消費者和客戶的交易關聯。結算管理對超市與供應商和客戶之間因為商品買賣產生的資金往來進行記錄，經營者可以及時獲知超市內部資金收付情況和盈利虧損狀態。

財務結算對超市收支和資金往來進行統計，主要包括供應商結算、客戶結算及零售結算。用戶用例圖如圖 3-12 所示：

圖 3-12 財務結算用例圖

供應商結算：貨物驗收后按照驗收單結算付款，可以部分結算，也可以匯總多次交易的驗收單總價進行批量結算。保存審核結算單后系統中對應供應商的應付款會相應減少，能夠清楚看到已結和未結總數，管理員或操作員可以方便進行查詢。

客戶結算：以銷售出庫作為結算依據，通過客戶結算減少客戶應收賬款，同時生成結算明細供管理日后查詢。結算可以一次性付清宮，也可以分次付。

零售結算：門店零售是超市銷售的重要部分，收銀員交款要做詳細的記錄。收銀員在當完班后打印收銀對賬單，財務按收銀員的實際交款金額編制收銀員繳款單，記錄當天交款記錄，供日后查詢。結算業務流程圖如圖3-13 所示：

圖 3-13 結算業務流程圖

3.2.8決策管理

目前很多超市每筆支出和收入明細都是通過手工賬本進行記錄，以年來單位進行匯總計算年度經營情況，大致了解是否盈利以及盈利狀況。因為貨架產品的價值不能準確統計，日常記錄也可能存在缺失或遺漏，所有的數據只能大概估值。這部分內容針對經營者最關心的經營數據進行匯總，主要由各種報表組成。如銷售排行榜、毛利表等。具體用例如圖 3-14 所示

圖 3-14 決策管理用例圖

銷售排行：能夠統計所有商品的銷量情況，或者按周、月、季度或年為單位查看商品的銷售排行，經營者根據數量排行能夠直觀了解哪些是超市暢銷商品，超市銷售商品和時間有沒有相關性，以此為依據調整商品結構、及時調整商品備貨量。

利潤排行：利潤表主要是幫助經營者分析超市在一定時間段的經營成果。通過銷售價格和銷售成本的展示和消減，對毛利率進行統計。為了多維度體現毛利率的分布，系統需要提供按照供應商查詢、按商品查詢、按時間段等單一條件查詢或多條件組合查詢的功能。

3.2.9 系統功能結構

根據軟件需求，得到超市管理系統的功能模塊圖，如圖 3-15 所示：

系統由系統管理、基礎檔案管理、采購管理、銷售管理、庫存管理、財務結算六個大模塊組成。系統按照樹形結構展開，每個一級模塊下有相應的子模塊。在進行系統操作時，要現進入每一個一級模塊主界面才能進行具體的操作。

3.3 非功能性需求

（1）性能需求

數據一致性：通過入庫單、出庫單錄入數據的數據在后臺庫存中要及時更新，保持業務顯示數據與系統數據數據的一致性［38］。

響應速度：體現在兩個方面，一是用戶登陸系統或打開單據時，系統的響應時間不超過兩秒，另一方面，當業務單據對庫存數據進行操作時，數據傳送和更新時間要縮短在毫秒級，保證系統顯示與業務保持高度統一，避免出現虛進或虛出的現象，造成數據混亂。

靈活性：對零售實時銷售的物品，如果因為停電或計算機故障燈原因造成數據未記錄入數據庫時，先由人工進行記錄，然一切恢復正常后，再由人工手動錄入未存數據，保持數據一致性。

穩定性：超市面向大眾消費，經營時間從早上持續到夜間，在這期間系統要一直處于啟動狀態。系統不但能要有快速的相應速率，還要有高可靠持續的穩定性，不能時不時出現軟件或數據錯誤，影響使用。

擴展性：系統開發是基于小規模的零售超市，能夠解決目前最基本的問題。隨之超市管理功能更加細化，對系統操作更加熟練后，管理者對系統夠實現的功能要求必然會增加。所以，要預留接口，為以后的擴展提供支持［39］。

（2）安全需求

使用管理系統能夠有效的集中超市貨品和經營資源，極大的提高管理水平和效率，但像所有計算機系統一樣會面臨數據風險，所以數據安全和數據備份非常重要。為系統設置自動備份或手動備份的功能，這樣無論是恢復數據或者更換硬件資源都不會影響超市的正常運行［40］。

3.4可行性分析（技術、經濟、操作）

本章一開始我們就結合實際場景對系統的需求功能進行了詳細的分析，從業務的角度出發，對系統開發所要涵蓋的范圍、要實現的內容和具體使用操作的方式方法都做了簡要的概括說明。此外，我們從經濟方面、技術條線、操作適用性三個方面對系統的開發再做進一步的分析和說明。

（1）經濟方面此次開發的功能是基于管理水平比較差的小型便利超市的使用場景，主要是解決他們面對的基本的管理問題，系統設計實現的功能相對較少，對比大型的商超或者連鎖企業來講，功能要簡單很多，不需要過多的人力投入，因此成本較低。從超市的角度來講，信息化是一個逐步實現的過程，剛開始購買使用的軟件功能不宜太多，第一次使用主要解決最核心的問題，只要成本不高，在可接受的范圍之內，能給管理帶來可預見的提升效果且后期可維護可升級，都是可以接受的。所以，軟件開發具有一定的市場基礎，經濟可行。

（2）技術方面

隨著信息技術的不斷發展，各種各樣的軟件開發語言、開發平臺和工具可以為我們所用。為了促進行業的發展，很多規模大的成熟的軟件公司都提供免費的開發環境和編譯器，提供免費的技術文檔供愛好者學習使用，網絡上充斥著無數技術愛好者的分享論壇，任何人都可以免費進去學習，也可以發布自己的產品進行討論和請教，各種各樣好玩好用的軟件產品被不斷的開發出來。超市管理系統類似ERP系統，有著很多成功的經驗，技術實現方面不存在問題，技術可行［41］。

（3）操作性方面家庭計算機普及，幾乎人人會用電腦。個人計算機安裝默認的操作系統為

Windows，此次系統開發環境也是基于Windows開發，契合了大家的使用習慣，不存在要適用新操作系統的問題。另一方面，系統開發的體系結構選擇為 C/S 結構，在使用時直接雙擊便可打開使用，在使用前不需要做過多的設置。軟件通過界面化的顯示實現人機交互，不需要知道系統后臺實現的邏輯和配置，只需要在系統中點擊相關按鈕，或者按系統提示在界面數據框中輸入檢索的內容分和過濾條件，系統變會按照程序設計的邏輯自動返回需要的結果，操作簡單，視覺效果一目了然，只要會最基本的計算機操作，稍加培訓就能使用，多加練習，必能靈活使用。操系統操作的角度講，完全可行。

3.5 本章小結

本章節從軟件適用場景出發進行實地調研，從用戶和使用者的角度出發，概括總結使用信息技術手段要解決的當前和未來面臨的管理問題，對系統要實現的具體功能和業務流程進行了詳細分析和說明，最后得到系統總的功能模塊圖，以此作為軟件實現的依據。另外，對軟件可靠性、穩定性以及安全性等非功能屬性做出要求。最后，通過技術、經濟、以及操作三個方面對系統實現可行性做出判斷。

第四章軟件設計

本章節主要從軟件的體系結構設計、軟件結構設計、系統功能模塊設計、數據庫設計、功能詳細設計等方面進行闡述。其中，系統功能設計部分明確了要設計軟件的功能結構和各模塊之間的關系；數據庫設計部分對數據存儲及調用過程中使用到的實體、屬性、數據表及表之間的關系進行了說明。

4.1軟件設計遵循原則

為了使開發的產品具有適應性、健壯性、可靠性、穩定性，在系統開發時需要做到以下幾個方面：

（1）與適用場景相匹配的軟件硬件開發、測試和使用環境，保證軟件的平臺適用性［42］。

（2）用戶操作界面數據輸入和顯示與數據庫數據交互對應，前后數據一致，同步更新。

（3）界面風格統一、操作簡潔易用，可用性強。

（4）功能完整，按照模塊化的思想進行開發，滿足需求說明中的內容。

（5）數據可靠穩定，模塊之間獨立運行，功能相互不受影響。

（6）可以多用戶同時操作，收銀員、操作員、管理員可以同時登陸系統對業務進行操作［43］。

（7）功能可擴展。隨著業務的增長，超市管理會更加細化，系統要在現有的基礎上增加新的功能［44］。

4.2體系結構及網絡設計（C/S）

因為針對的是中小型超市，一般規模較小，對網絡的依賴程度較低，考慮到使用的穩定和高效性，此次我們采用c/s體系結構作為我們的軟件開發模式。應用由兩部分組成，即客戶機應用和數據庫服務器程。中小型超市的規模一般比較小, 單店面一般有一到兩臺收銀機，通過局域網進行連接。系統使用人員通過客戶端界面在單據界面錄入數據，服務器程序會根據自己處理后得到的結果從sqlserver 中進行數據結果的調取很更新，在客戶端能夠直觀的顯示。系統體系結構及網絡圖見圖4-1所示

4.3 系統的組成

系統操作功能分前臺和后臺兩部分。前臺由 POS 收銀機和收銀系統構成，一般在購買收銀機時商家會連帶贈送收銀系統，有收銀員進行操作使用。前臺的主要功能有及時零售、庫存數量查詢、掛賬以及小票打印。前臺收銀員通過手持掃描設備掃描商品條碼， POS 系統根據條碼識別調用數據庫中的商品名稱、價格、單位等信息并顯示在前臺收銀界面，通過收銀操作銷售貨物后系統可以對數據庫中的庫存數量進行更新，查詢銷售統計表等數據也會隨之變化。因為篇幅有限，論文對前臺的實現不做過多描述，只對后臺的管理做詳細說明。后臺主要是管理系統，對商品、供應商、客戶、用戶權限等基礎資料進行維護，對采購業務、銷售業務、庫存查詢、業務結算及系統安全等進行管理，由系統后臺操作員和系統管理員進行操作。

系統整體的功能結構如圖 4-2 所示：

前臺POS收銀系統

4.4 系統數據庫設計

441數據庫結構設計（E-R圖）

根據前期對超市管理系統的需求分析和功能劃分，通過數據庫概念結構設計的方法，將用戶和軟件功能需求抽象為不依賴任何機器的數據模型，對數據和信息建立模型，每一個實體中都包括了各自的主要屬性。各個實體之間又相互關聯，通過實體關系圖來表示各個實體以及實體之間的關系。實體關系圖又稱之為實體聯系圖，也被稱為 E-R 圖。

在超市信息管理系統的數據庫設計中包含了很多個實體，我們列舉其中主要的幾個實體來進行描述和分析。

1.供應商實體圖，見圖 4-3 所示：

圖 4-3 供應商實體圖

超市經營的商品種類很多，會有不同的供應商。為了便于記錄，在系統中要對每個供應商的基本資料進行記錄。供應商的基本屬性有：編碼、名稱、聯系人、電話、分類、地址等。

2.客戶實體圖，見圖4-4所示：

圖 4-4 客戶實體圖

超市除了零售商品外，會存在一些針對公司或者團體的集中式或大額銷售，對客戶資料進行維護，一方面可以方便的獲知客戶群體信息，另一方面可以結合銷售行為對銷售數據進行統計和分析。客戶實體對應的屬性主要有：編碼、名稱、聯系人、聯系電話、地址、銀行賬號等信息。

3.商品實體圖，見圖4-5所示

圖 4-5 商品實體圖

超市從供應商買入商品，超市向消費者和客戶賣商品，商品是超市經營的主體，是超市與其他實體發生關系的媒介和橋梁。商品的主要屬性有：產品編碼、產品名稱、規格、計量單位、供應商、生產商、品牌等。

4.超市實體圖，見圖 4-6所示：

圖 4-6 超市實體圖

超市是經營的主體，與供應商和客戶存在買賣交易關系，與管理者是管理和所有關系，對商品進行買賣。超市對應的屬性主要包括：編碼、名稱、管理人、電話、地址、傳真等信息。

5.庫存查詢實體圖，見圖 4-7所示：

圖 4-7 庫存實體圖

超市中所有商品會以貨架陳列或倉庫的形式存在，在數據庫系統中，庫存商品記錄所有商品的在庫情況，包括：產品編號、名稱、供應商、庫存數、采購日期、保質期、到期日等，這些一起構成了庫存實體的屬性。

6.用戶實體圖，見圖 4-8所示：

圖 4-8 管理員實體圖

系統中的用戶有三種：系統管理員、后臺操作員、前臺操作員。每個用戶通過唯一對應的名稱和密碼可以進入不同的界面。用戶實體的主要屬性有：編碼、名稱、密碼等。

7.入庫單實體圖，見圖 4-9 所示：

圖 4-9 入庫驗收單實體圖

超市根據銷售情況定時或不定時的采購商品，商品到貨后要及時辦理入庫，作為庫存查詢、銷售和結算的依據。入庫單實體屬性涵蓋了與商品采購幾乎所有的信息，如：商品編碼、商品名稱、商品規格、計量單位、商品數量、供應商名稱、采購日期、單據號等。

8.出庫單實體圖，見圖 4-10 所示：

圖 4-10 銷售實體圖

超市與客戶之間有交易每售出一單商品，都要在系統中錄入一張銷售記錄，一方面便于后期查詢，另一方面也作為庫存數量扣減的依據，記錄的對象也及銷售單實體的屬性包括：單據編碼、商品編碼、商品名稱、銷售數量、銷售金額、業務員等。

9.保質期到期實體圖，見圖 4-11所示：

圖 4-11 保質期預警實體圖

庫存管理很重要的一個功能，就是能夠及時獲知超市每個商品的保質期到期情況，及時調整貨架商品順序，及時對即將過期的產品進行促銷或退換貨處理。保質期預警實體包含了與商品信息有關的多個屬性，主要包括：商品名稱、商品數量、采購日期、到期日、供應商信息等。

10.實體聯系圖

數據庫中有很多實體，實體與實體通過屬性連接，相互之間存在對一、一對

多、多對一、多對多的關系，在此我們通過上述幾個實體之間的關系進行簡要說明，如圖 4-12 所示：

圖 4-12 實體聯系圖

4.4.2 數據庫表設計

將概念結構設計所得到的 E-R 圖轉化為數據庫系統所能支持的數據模型，通過數據庫邏輯設計，根據各個實體，實體對應的屬性和實體時間的關系我們可以得到對應的數據表表 4-1，詳情如下所示：

表 4-1 數據表

表名備注

tb_supermarket 超市信息表

tb_goods 商品表

tb_admin 管理員檔案表

tb_supplier 供應商檔案表

tb_client_ 客戶檔案表

tb_goodentry 入庫驗收單信息表

tb_saleout 銷售岀庫單信息表

tb_stocklist 庫存信息查詢

tb_stockwarning 保質期預警表

1)超市信息表主要字段(tb_supermarket)：

主要用來記錄超市有關的信息，通常在系統初始化時會錄入相應的信息，系

統自助管理使用的情況，后期一般修改變化的不多。超市信息表部分表內容如表

4-2 所示：

表 4-2 超市信息表

字段名稱類型（長度）是否為空備注

tb_supermarket_ID Int(10) 否超市編號（PK），唯一標識，用戶自定義

tb_supermarket_name Varchar(20) 否超市名稱

tb_supermarket_add Varchar(20) 否超市地址

tb_supermarket_phone Varchar(20) 否聯系電話

tb_supermarket_leader Varchar(10) 否負責人

2）商品表主要字段（tb_goods）

超市在計劃采購商品前，都要先將商品詳細信息錄入系統以供后期交易和查詢使用，系統中管理員在系統中每增加保存一條信息，數據庫中的商品信息表便會增加一行內容。商品信息表主要表內容見表4-3

表 4-3 商品信息表

字段名稱類型（長度）是否為空備注

goods_idn Int(12) 否商品編碼（PK），每個商品唯一編號，不能重復

goods_name Varchar(12) 否商品名稱

goods_size Int(10) 商品規格

goods_unit Varchar(5) 否計量單位

goods_supplier Varchar(10) 否供應商

goods_sort Varchar(10) 否商品類別

goods_brand Varchar(10) 商品品牌

goods_purprise number(10) 參考進價

goods_saleprise number(10) 零售價

goods_keeptime number(10) 否保質期

goods_remark Varchar(10) 備注

3）管理員表主要字段（ tb_admin）

系統將管理員信息以一張表的形式進行存儲，表的格式不變，表中的內容可以進行調整。管理員信息表主要表內容如表4-4所示。

4)供應商主要字段( tb_supplier)

供應商表按照與供應商有關的信息進行設計，包含了多個必錄項。管理員在前臺每增加一個供應商條目，對應后臺的表中便會增加一行。如果前臺刪除和編輯供應商信息，數據庫表中的字段內容也會跟隨做相應的調整和變化。供應商主要表內容如表 4-5 所示。

表 4-4 管理員信息表

字段名稱類型(長度) 是否為空備注

admin_id Int(8) 否管理員賬號(PK)

admin_name Varchar(lO) 否管理員名稱

admin_secret Int(lO) 否管理員密碼

表 4-5 供應商信息表

字段名稱類型(長度) 是否為空備注

suppl_idn Int(8) 否供應商編碼(PK)

suppl_name Varchar(20) 否供應商名稱

suppl_qu Varchar(25) 區域

suppl_add Varchar(30) 地址

suppl_cotac Varchar(5) 否聯系人

suppl_ph number (20) 否聯系電話

suppl_fa Varchar(20) 傳真

suppl_bank Varchar(20) 開戶行

Suppl_banknum number(20) 開戶賬號

suppl_ taxid number(30) 稅務登記號

suppl_paytime datimer(10) 每月結賬日期

suppl_remark number(10) 備注

5)客戶主要字段( tb_client)

客戶名稱可以是人名，也可以是公司或者機構名。超市規模較小，在實際業

務當中實際的交易業務量都不是很大，對信息的完善要求不高，因此對銀行賬號、需要開票的類型等這些字段內容都不做固定的要求。客戶表會的內容會隨著管理員在前臺的調整而修改。客戶主要表內容如表 4-6 所示。

表 4-6 客戶信息表

字段名稱類型(長度) 是否為空備注

lient_id Int(10) 否供應商編碼(PK)

client_name Varchar(20) 否供應商名稱

client_sort Varchar(20) 客戶分類

client_area Varchar(20) 區域

client_add Varchar(30) 地址

client_cotac Varchar(5) 否聯系人

client_phone number (20) 否聯系電話

client_fax Varchar(20) 傳真

client_mail Varchar(20) 郵箱

client_invoicetype Varchar(10) 發票類型

client_bank Varchar(20) 開戶行

client_banknum number(20) 開戶賬號

client_taxid number(30) 稅務登記號

client_paytime datimer(10) 每月結賬日期

client_remark number(30) 備注

6)入庫驗收單主要字段( tb_goodentry)

入庫驗收單中包含了與商品有關的幾乎所有信息。操作日期默認取系統的當前日期，可以手動進行修改。表單中的字段金額=單價*數量。同一個入庫單中可以包含多條產品信息。入庫驗收單主要表內容如表4-7所示。

7)銷售出庫單主要字段( tb_saleout) 面向客戶每售出一批商品，在系統中新增一張銷售出庫單，在數據庫中的銷售出庫單表中新添一行數據。銷售出庫單中字段單據字段*數量=金額。銷售出庫單主要表內容如表 4-8 所示。

表 4-7 入庫驗收單信息表

字段名稱類型(長度) 是否為空備注

goodentry_id Int(10) 否單據號(PK)

Supplier_name Varchar(20) 否供應商

goods_id Varchar(20) 否商品編碼

goods_name Varchar(20) 否商品名稱

goods_size int(10) 否商品規格

goods_int money(5) 否單價

goods_buynum number (20) 否數量

goods_buyprise money(5) 否金額

Buy_man Varchar(10) 否操作員

Produce_time datimer(10) 否生產日期

Expiration_time datimer(10) 否失效日期

buytime datimer(10) 否操作日期

Buy_remark Varchar(30) 備注

表 4-8 銷售岀庫單信息表

字段名稱類型(長度) 是否為空備注

saleout _id Int(10) 否單據號(PK)

Client_name_ Varchar(20) 否客戶

saleou _time_ datimer(10) 否單據日期

saleou _id Varchar(20) 否商品編碼

saleou _name Varchar(20) 否商品名稱

saleou _size int(10) 否商品規格

saleou _int money(5) 否單價

saleou _buynum number (20) 否數量

saleou_buyprise money(5) 否金額

discount money(5) 折扣

Saleou_remark Varchar(30) 備注

8)庫存信息查詢(tb_stocklist)

主要展示超市商品的靜態狀態，庫存數量會隨入庫單的確認而數量增加，也會隨銷售出庫的確認而數量減少。表中的商品信息會經常處于一陣動態的變化中國。當庫存數據進出抵消為零時，表中的其他比如商品名稱、商品規格、供應商等信息不顯示。庫存表主要表內容如表 4-9 所示

表 4-9 庫存信息表

字段名稱類型（長度）是否為空備注

goods id Int(8) 否商品編號（primary key）

goods name Varchar(20) 否商品名稱

goods bank Varchar(20) 否商品品牌

goods size Varchar(20) 否商品規格

supplier name Varchar(20) 否供應商

Stock num int(10) 否庫存數量

Stock prise money(5) 否庫存金額

Stock saleprise Varchar(30) 售價金額

9)保質期預警( tb_stockwarning)

保質期預警表的數據主要提供查詢功能，將每個商品的生產采購日期、有效和過期日期按照列表的方式展現出來。庫存管理員可以根據就近日期，聯系供應商對快到期的商品進行處理。通過系統查表數據時，可以查看全表內容，也可以按照表字典，如商品名稱、供應商、有效期或倉庫等信息進行條件查詢。保質期預警主要表內容如表 4-10 所示：

表 4-10 保質期預警信息表

字段名稱類型（長度）是否為空備注

goods idn Int(8) 否商品編號(primary key)

goods name Varchar(20) 否商品名稱

goods size int(10) 否商品規格

supplier name Varchar(20) 否供應商

supplier ware Varchar(10) 否倉庫

Produce time datimer(10) 否入庫日期

Expiration time datimer(10) 否有效期至

Stock remaintime int(5) 否有效/過期天數

4.5系統功能詳細設計

在完成系統總體設計后我們需要按照模塊化的設計思想按照系統劃分的功能模塊圖分別對每個子模塊進行分析，使用 UML 統一建模工具分別從靜態和動態兩方面對系統進行設計。

4.5.1 類圖

類包括三要素：類名、類屬性、類操作。類圖反應了類與類之間的靜態關系，

我們取系統中的部分對象進行類分析，類圖見圖4-13 所示：

外購入庫

圖 4-13 類圖

4.5.2 時序圖

展示對象之間的交互細節

1、用戶登錄

用戶進入系統登錄界面，系統先對用戶名進行驗證，通過后在數據庫中的用戶表中對用戶名和密碼進行匹配，如果成功便進入用戶界面，如果不成功提示用戶重新輸入。登錄時序如圖 4-14 所示。

2、系統操作員管理管理員進入操作員管理界面新增用戶并設置基本信息，可以直接退出也可以

繼續進入賦權界面為操作員新增或修改權限。設置后保存返回管理員界面。新增操作員時序圖如圖 4-15 所示：

3、采購管理我們以外購入庫單的新增時序為例進行說明。采購人員登錄系統后進入采購

管理界面，雙擊入庫驗收單圖標進行單據新增，依次填入貨物名稱、數量、單價、金額、倉庫等信息后保存，如果成功，返回保存成功表示。如果保存不成功，系統會提示不成功原因，修改完再繼續保存。采購入庫新增時序圖如圖 4-16 所示：

圖 4-14 用戶登錄時序

圖 4-15 新增操作員時序圖

圖 4-16 采購入庫新增時序圖

4、銷售管理我們以銷售出庫單錄入時序舉例說明。銷售單錄入時序圖如圖 4-17 所示

5、庫存管理庫存管理主要的功能模塊有：庫存查詢、庫存信息盤點以及庫存商品保質期

到期提醒。我們以庫存查詢時序圖進行說明，如圖 4-18 所示：

圖 4-18 庫存查詢時序圖

6、基礎檔案信息管理基礎信息管理模塊主要包括了供應商檔案、客戶檔案、商品分類、商品檔案的管理功能。其中的主要的操作主要有新增、刪除、查看、更改。選取商品檔案的新增時序圖進行說明，如圖4-19 所示：

返回商品檔案信息；

I T

圖 4-19 商品檔案新增時序圖

7、財務結算管理結算管理模塊主要實現與供應商和客戶資金收付記錄和查詢，對單據的日常操作有新增、修改、查看和刪除操作，我們選擇供應商結算單據的新增時序圖對系統實現過程進行說明，如圖 4-20 所示：

圖 4-20 供應商界算單新增時序圖

8、決策管理

決策管理主要為經營者提供一些與經營有關報表的數據查看，我們選擇銷售表的查看時序圖進行說明，見圖 4-21 所示：

圖 4-21 銷售排行表查看時序圖

4.6 本章小結

本章對系統的設計原則進行了概述，以文字和圖形化的方式介紹了系統的體系結構和功能模塊設計、數據庫實體和表的設計以及程序詳細設計。因為篇幅有限，只列舉了軟件設計過程中的部分類圖和時序圖對系統詳細設計進行了說明。

第五章系統的實現

系統功能需求表述系統要實現的業務功能及要解決的問題，數據庫設計將業務處理的數據以特定的格式進行規劃，系統總體設計對軟件要實現的功能和過程進行建模和分析。本章節在對系統的前期建模的基礎上進行代碼實現和界面實現。因為篇幅有限，我們選取部分模塊對實現結果和過程進行說明。

5.1 用戶登錄功能

系統的操作使用人員角色包括采購人員、銷售管理員、系統管理員、庫存管理員、財務員等。每個系統操作使用人員都有唯一的賬號和密碼，登錄系統時候系統要先進行身份驗證。只有用戶名和密碼一致才能進入相應權限的界面。在登錄界面的用戶名選擇框中可以查看并選擇查看后臺系統預設的多個用戶，在密碼框中輸入設定密碼后進行確認。密碼正確即可進入許可的用戶登錄主界面，密碼錯誤，系統會給出提示。以管理員登錄為例，登錄后看到的主界面如圖5-1所示：

圖 5-1 管理員用戶主界面

圖 5-3 用戶登錄界面

核心代碼：

private void dlOK_Click(object sender,EventArgs e) {

string uId, uPwd; tb_EmpInfoMenth taEmp =new tb_EmpInfoMenth(); if (txtusername.Text =="")

{MessageBox.Show(”請選擇用戶名！ ”);return;}

if(txtuserPwd.Text=="")

{MessageBox.Show(”請輸入密碼！ ”);return;}

if (taEmp.tb_EmpInfoFind(txtusername.Text,txtuserPwd.Text,2) ==1) {

String connstr="DataSource=60.60.60.51;InitialCatalog=chaoshi; uid=chaoshi;upwd=123";

using(SqlConnection conn= SqlConnection(connstr));

SqlCommand cmdLn=new SqlCommand();〃查找用戶的 sql 語句 string MatchStr;

MatchStr= StMake(MatchStr,uId,uPwd);

〃使用sql語句進行查找用戶；

cmdLn.CommandText = MatchStr;cmdLn.Connection =conn; var checkResult=(int)cmdLn.ExecuteScalar();

if(checkResult ==1)//為采購員角色，加載相關信息

{

Session.Add("userid",uId);

Session.Add("userole","caigou"); con.Close();Response.Redirect("caigouguanli.cs");

}

if(checkResult ==2) //為銷售員角色，加載相關信息

{

Session.Add("userid",uId);

Session.Add("userole", "xiaoshou");

con.Close(); Response.Redirect("xiaoshouguanli.cs");

}

if(checkResult ==3)//為庫管員，加載相關信息

{

Session.Add("userid",uId);

Session.Add("userole","kuguan"); con.Close();Response.Redirect("kucunguanli.cs");

}

else

{

MessageBox.Show(”密碼錯誤，請重新輸入”)

}

5.2 系統功能

系統管理功能模塊由系統操作員進行管理，主要包括的功能有操作員管理、密碼修改、操作日志查看以及數據備份。我們列舉其中的三個模塊進行說明。

1.操作員設置

系統的所有操作員和與用戶要通過管理員進行創建和設置。初次使用系統時，先通過管理員賬號進入系統，然后在操作員管理界面對系統其它的用戶進行定義。系統用戶分為管理員、前臺操作員、后臺操作員三大來。收銀員屬于前臺操作員，除此以外的采購管理員、銷售管理員、庫存管理員、財務等具有系統管理功能的都屬于后臺操作員。選擇用戶分類后點擊菜單欄中的新建按鈕，對用戶的代碼、名稱、初始密碼、狀態信息進行設置后點擊保存按鈕，右邊就會出現一條用戶信息。如果要對用戶信息進行修改，雙擊后修改并保存。如果要刪除用戶，選中用戶信息，單擊刪除按鈕執行操作。如果用戶信息比較多，需要快速定位某一用戶信息，還可以使用菜單單中的查詢功能進行查找。用戶新建好后在菜單欄點擊“授權”，不同的操作員便被賦予了不同的操作權限。管理員對操作員的管理程序流程圖如圖5-4所示，操作員管理界面圖 5-5 所示。

圖 5-4 新增操作員程序流程圖

圖 5-5 操作員管理界面

操作員管理相關部分代碼如下所示：

private void user_Click(object sender, EventArgs e)

{

if (getPen() == 1)

{

if (intmark == 1)

{

if (tbmanage. tb_adminFind(txt admin_name.Text,"",1) == 1)

{

MessageBox.Show(" 登錄名已存在！ ");txtEmp admin_name.Text = txtEmp admin_name.Focus();return;} if (tbmanage. tb_admin Add(EmpClass) == 1)

{MessageBox.Show(" 新增用戶成功 "); intmark =0; bmanage.tb_adminFind("",2,dataGridView);} else{MessageBox.Show(" 新增用戶失敗 "); intmark = 0;} } if (intmark == 2) { if (tbmanage. tb_admin Update(EmpClass)==1) {MessageBox.Show(" 修改用戶成功 ");Intmark=0; tbmanage. tb_adminFind("",2,dataGridView);} else{MessageBox.Show(" 修改用戶失敗 "); intmark = 0; } }

if (intmark == 3)

{

if (tbmanage. tb_admin Delete(EmpClass) == 1)

{ MessageBox.Show(" 刪除用戶成功 ");intmark = 0;

tbmanage. tb_adminFind("",2,dataGridView);}

else{ MessageBox.Show(" 刪除用戶失敗 "); intmark = 0;}

}

}}

2.修改密碼

每個系統用戶都可以對自己的密碼進行修改，管理員有所有用戶的密碼修改權限。修改密碼時雙擊打開修改界面，分別輸入原密碼和新密碼，只有當原密碼正確且兩次新密碼相同時，密碼才能修改成功，修改后系統會給出相應的提示。對應的程序流程圖如圖5-6所示，修改密碼界面如下圖 5-7 所示：

圖 5-6 修改密碼程序流程圖

圖 5-7 修改密碼界面

相關部分代碼如下所示：

public partial class repwd

{

private void repwd_Load(object sender, EventArgs e) {txt_uname.Text =comm.UserName;}

sql co=new sql();

string sqlstrg= "select * from tb_users where UserName = '"uname.Text"'"; SqlDatacon Cr =co.Create SqlDatacon(sqlstrg); Cr.Read(); //驗證舊密碼是否正確 if (txt_uoldpwd.Text!=Cr[2].ToString())

{MessageBox.Show(" 原密碼有誤，請重新輸入 !"); return; }

if (txt_nepwd1.Text!=txt_nepwd2.Text)

{MessageBox.Show ("兩次新密碼不同，請確認”);return;} sqlstr="update tb_users set UserPwd='"unepwd.Text"' whereUserName='"uname.Text"'";

if (con.ExecuteSql(sqlstr))

{MessageBox.Show ("修改成功!");}

Close();

}

3.數據整理數據整理模塊主要實現系統數據的備份。選擇保存地址，命名備份文件名稱并確認，系統會將打包數據以特定格式按照指定路徑保存并給出提示。實現界面如圖5-8所示，對應程序流程圖如圖 5-9 所示：

圖 5-8 數據備份實現界面

圖 5-9 數據備份程序流程圖

核心代碼如下：

private void systemback_Click(object sender, EventArgs e) {

try

{

if (txtfilePath.Text != "" &&txtfileName.Text != "")

{

getSqlConnection cn = new getSqlConnection(); SqlConnection cnn = cn.GeCon();

string sBack = "backup database db_sysdata to disk='" +

txfiletPath.Text.Trim() + "\\" + txtfileName.Text.Trim() + ".bak'";

SqlCommand Cd = new SqlCommand(sBack,cnn);

if (Cd.ExecuteNonQuery() != 0)

{MessageBox.Show("備份成功！"，”提醒框",MessageBoxButt.OK,

MessageBoxcoon.Information);this.Close();}

else

{MessageBox.Show("備份失敗！ ")；}

else

{MessageBox.Show(”請重新選擇備份的位置和文件名！ ")；}

}

catch (Exception ee)

{MessageBox.Show(ee.Message.ToString());}

}

5.3 信息檔案

信息檔案主要包括了客戶信息檔案、供貨商信息檔案，商品信息檔案、倉庫恓檔案等。在操作使用系統前先要將這些檔案錄入系統，才可以進行單據錄入和商品出入庫。信息檔案主界面如圖5-10所示：

嚴(B)采購(0批發(P) 財埶M)決覽(D)嶽(E)

維護每種基礎檔案都要進入到其對應的基礎界面進行操作，常見的操作主要有新增、刪除、查詢、修改、復制、保存等功能。系統對每一條數據的增刪改都對應后臺數據庫中相應數據庫信息表的同步更新。數據要逐條進行編輯，當必填項為空或者所填數不符合要求時系統會彈出相應提示。商品檔案模塊涵蓋了系統業務相關的重要的基礎資料，與幾乎所有的業務過程相關，以商品檔案的新增功能實現舉例說明，商品檔案操作界面如圖5-11所示，程序流程圖如圖5-12所示：

圖 5-11 商品檔案操作界面

▼

結束

圖5-12 商品檔案新增程序流程圖

商品檔案基礎資料維護相關的部分代碼如下所示：

Private goods_newok_Click(object sender,EventArgs e)

{

int dnReslult =0;

if(txtgoods_name.Text =="")

{

MessageBox.Show(" 商品名稱為空 !, 請輸入 ");return dnReslult;

if (txtgoods_size.Text =="")

{

MessageBox.Show(" 商品規格為空 ! 請輸入 ");return dnReslult; if(txtgoods_unit.Text =="")

{

MessageBox.Show ("計量單位為空!請輸入 ”);return dnReslult;

}

Else dnReslult=1;}

}

using (SqlConnection co=new SqlConnection(datacon))

string sql="insert intotb_goods values";

if(dnReslult=1)

{

using (SqlCommand cod=new SqlCommand(sql,co))

{

int m =cod.ExecuteNonQuery();

con.Open();

Console.WriteLine(”成功新建{0}個商品信息",m);

}

Console.ReadKey();

}

5.4 采購管理

系統管理員或具有采購管理權限的操作員登錄系統后可以進入到采購管理界面，能夠直觀的看到采購訂貨、采購入庫、采購定價調整、贈送入庫以及采購退貨的功能圖標，雙擊采購界面中的圖標可以打開對應的系統單據，采購模塊功能主界面如圖 5-13 所示。

采購貨物入庫主要用來實現貨物入庫登記和庫存貨物數據更新。超市在確認收貨后，采購人員或管理員在程序主界面打開“入庫驗收單”后系統便新增一張空白表單，單據也分表頭和表體兩部分。供應商信息可以在基礎資料列表中進行查找填入，原始單號可以空出也可以在采購訂單列表中查找并選擇錄入。當選擇采購訂單號時，系統會檢索并匹配相應的訂單信息，將采購明細返回到入庫驗收單的表體部分，自動填充表體中的商品號、商品名稱、商品單位、數量、單價、金額等信息。操作員可以根據實際到貨情況對表體中的行信息進行刪除，也可以對照實物對商品數量進行調整。如果不應用訂單信息進行入庫，也可以在單據體中手動逐條添加商品信息。錄入完畢后保存單據，對應數據在數據庫入庫驗收單中插入表信息并返回保存成功消息。可以通過“編輯”按鈕對單據進行編輯和刪除操作。入庫驗收單新增界面如圖5-14所示：

圖 5-13 采購模塊功能主界面

圖 5-14 入庫驗收單新增界面

驗收入庫單新增程序流程圖如圖5-15所示：

圖 5-15 驗收入庫單新增程序流程圖

對應的部分代碼：

Class goodentryprogram

{

Int T_addorupdate;〃定義對單據新增還是修改 private void S_add_Click(object sender, EventArgs e)

{

This.editEnable();〃所有控件可用

This.cleartText();〃新增狀態下文本框都為空 T_addorupdate=0;〃新增單據標識

}

private void S_save_Click(object sender, EventArgs e)

{

If (T_addorupdate=0)

{

Try{ tb_goodentry.Supplier_name=txtSupplier_name.Txt;

tb_goodentry.goods_name =txtgoods_name.Txt; tb_goodentry.goods_size =txtgoods_size.Txt; tb_goodentry.goods_int =txtgoods_int.Txt; tb_goodentry.goods_buynum =txtgoods_buynum.Txt; tb_goodentry.goods_buyprise =txtgoods_buyprise.Txt; tb_goodentry.Buy_man =txtBuy_man.Txt;

MessageBox.Show(“ 單據保存成功”)；

}

Catch(exception ex)

{

MessageBox.Show( “單據未正常保存成功”)

}

Console.ReadKey();

}

5.5 批發銷售

系統管理員或者具有銷售管理權限的操作員登錄系統后可以進入批發銷售管理界面，系統功能以圖標加文字的方式直觀的呈現在界面右邊。批發銷售管理主界面如圖 5-16 所示：

圖 5-16 銷售管理主界面

雙擊每個單據對應的圖標，可以直接進入新增界面。在系統空白框中錄入相應的數據，如果必填項沒有錄入，單據保存時系統會給出相應的提示。針對客戶消費使用“批發銷售單”，為的是與零售去銷售區別。單據分表頭和表體兩部分，每張單據的表體部分可以錄入一行，也可以多行錄入。日期、倉庫、業務員、客戶、商品名稱、單位、數量及價格是必錄項，其他信息如生產日期和失效日期系統會從庫存信息直接帶出，折扣、運輸方式等信息不做強制要求。通過刪除按鈕可以實現單據的清除，對應數據庫中表信息刪除。銷售出庫單新增界面如圖 5-17 所示：

圖 5-17 銷售出庫單新增界面

銷售單錄入程序流程圖如圖 5-18 所示：

圖 5-18 銷售單錄入程序流程圖

銷售出庫單錄入部分代碼：

public int tb_SaleoutAdd(tb_Saleout tbSell)

{

int intFag=0;

try

{

string Add_str ="insert into tb_Saleout values(

Add_str+="'"+tbSell.saleout _id+"','"+ tbSell. Client_name;

Add_str+="'"+tbSell.saleou_id+"','"+tbSell. saleou_name+"',"+tbSell.saleou_size;

Add_str+="'"+ tbSell.saleou_int+"',"+tbSell. saleou_buynum+","+tbSell.saleou_time;

Add_str+=""+tbSell.saleou_buyprise+","+tbSell.discount+",'"+tbSell.Saleou_remar k;)

getSqlConnection getCon =new getSqlConnection();

cmd=new SqlCommand(Add_str,getCon); intFalg=cmd.ExecuteNonQuery();

cor=getCon();

return intFag;

}

catch (Exception eb)

{

MessageBox.Show(eb.ToString());

return intFag;

}

5.6 庫存管理

庫存管理模塊的功能主要包括：庫存商品信息查詢，庫存盤點錄入以及庫存在貨商品的保質期查詢和預警。庫存管理主界面如圖 5-19 所示：

ratline

色 *J«v.n

S£(B)知gg Jtt發(P) flSS(T)財務＜M)決策(D)漿細 E)

圖 5-19 庫存管理主界面

罐® 芝1

商品庫祥窶詢商品褲效期快曹報衰盤點錄入

庫存查詢時可以按照時間、商品、供貨商等維度進行查看，通過與數據庫中

2 J級獺[

M 軸iMfi隣軸融娥馴撤鵬齣

圖 5-20 庫存查詢功能

的庫存表交互，及時獲取并展示想要的數據。庫存查詢功能界面如圖 5-20 所示：

館:|軒』啊總勰旅』刪:陌I j Q[[]|

耀能廠

3]「SSflfflWfl「

肯禍亜薊•鋼環LS

血晶Ml!

庫存查詢功能程序流程圖如圖 5-21 所示：

圖 5-21 庫存查詢功能程序流程圖

庫存查詢實現的部分代碼：

Public Class findstock

{

public void btfin_click(object sender,EventArgs e)

{ if(Txtstock.txt.Trim()==Str.empty())// 當文本框為空時顯示所有庫存信息

{ dgStocklist.datasource=bainfo.Getallstock(“tb_stocklist”).Table{0}；

}

if(Txtstockname.Txt!==””)〃按商品名稱查詢

{

Stocklist.name=txtfindstock.txt;〃記錄名稱 Gs=bainfo.findstockbyname(Stocklist.” tb_stocklist”);〃根據名稱查詢 dgStocklist.datasource=gs.Table{0};〃顯示按條件查詢得到的庫存信息

}

else(Txtstockbank.Txt!==””)〃按商品品牌查詢

{

Stocklist.bank=txtfindstock.txt;

Gs=bainfo.findstockbybank(Stocklist.”tb_stocklist”);

dgStocklist.datasource=gs.Table{O};〃顯示安條件查詢得到的庫存信息

}

Console.WriteLine();

else

{Console.WriteLine(” 沒有查到數據");}

}

5.7 財務結算

財務結算主要由供應商結算、客戶結算和收銀員結算組成。以客戶結算為例說明，打開結算單，選擇要收款的客戶信息，付款方式默認為現金，可以更改為銀行轉賬等選項。日期默認為當前日期，也可以進行修改。在表中的業務單號空白框中選擇對應的要收款的銷售出庫單，系統便會自動帶出客戶對應的總應付金額、已付金額，本次應付金額。填寫完成后保存。財務結算主界面如圖5-22所示:

圖 5-22 財務結算主界面界面

供應商結算的實現過程和方法與客戶結算是類似的，只是在選擇供應商信息

后，業務單號是根據入庫驗收單來進行選擇。客戶結算新增界面如圖5-23所示:

圖 5-23 客戶結算新增界面

5.8 決策分析

通過報表的形式對銷量進行匯總查看，匯集了前臺和后臺所有的銷售數據。管理員可以按照自定義時間段進行排序查看，系統會自動帶出對應產品的銷售數量和金額。決策分析主界面如圖 5-24 所示：

圖 5-24 決策分析主界面

毛利排行表如圖 5-25 所示：

圖 5-25 毛利排行表

5.9 本章小結

根據軟件系統設計方法，依據前面章節對超市管理系統的功能分析、數據庫設計、業務動靜態的過程設計等成果，使用編程語言和軟件開發工具對系統采、購、存、銷各模塊及子模塊的界面和代碼進行逐一實現，本章節選取各功能模塊中的部分界面截圖和對應程序流程圖及代碼對系統實現過程進行說明。

第六章系統功能測試

6.1 系統測試目標

軟件系統完成設計后，需要結合系統開發的需求說明進行功能和性能的測試，與用戶使用的場景進行匹配，和系統設計期初的目標進行比對，對系統所有模塊的功能進行一一驗證。通過實地操作和數據檢驗，發現流程和程序功能實現的缺陷和錯誤，通過輸入和輸出之間的相應速度和響應效率，檢查系統的可靠性［45］。

總的來講，系統測試目標就是在完成階段性的程序功能設計的基礎上，按照軟件測試原理，通過既定的測試手段和測試方法對系統模塊進行檢驗和驗證，找出功能和性能方面的差異和缺陷，將不完善的地方按照一定的格式記錄下來，找出問題所在，不斷進行調整和優化，直至問題解決為。驗證所設計的功能是否滿足期初的要求，幫助開發人員發現漏洞和缺陷，不斷完善系統功能，提高系統性能，是軟件測試的重要意義和目標［46］。

6.2系統測試基本原則和方法

所有軟件根據應用的場合和功能不同都有其特殊性和唯一性，軟件設計和使用者要根據業務側重點、軟件使用環境和其他實際情況，選擇合適的測試和方法，制作測試計劃，設計針對性的測試用例，運行系統并及時記錄結果。軟件設計存在差異性，但是設計邏輯和方法上有很多共性，在軟件測試時選擇合理、規范的測試用例，搭建同系統使用場景一樣或類似的測試環境，提高準確性［48］。

軟件常用的測試方法包括黑盒測試和白盒測試，兩種方法的思路和側重點不同。白盒測試主要是軟件邏輯路徑的覆蓋測試，側重程序內部嚴密的的細節檢驗，優點是可以檢測到軟件代碼中的每條分支和路徑，能夠發現代碼中的錯誤，缺點是不能夠檢查出和數據有關的錯誤［48］。黑盒測試，關注界面和用途，測試人員不用知道軟件內部的結構，不需要知道軟件是如何設計實現的，只要將目標測試程序看成一個類似密封的黑匣子，在輸入端按照一定的格式輸入數據或代碼，檢測系統能否夠按照需求和設計要求在輸出端出現預期的結果。測試工作在系統的輸入和輸出端進行，重點關注系統的響應。黑盒測試因為不需要了解軟件內部的具體代碼，測試相對簡單，在實際的應用中使用廣泛，貫穿軟件設計的整個周期［49］。

將軟件功能劃分模塊，按層次劃分，按邏輯分解分解，依次按照單元測試，模塊集成測試，系統整體測試，以及端到端的步驟進行。單元測試針對系統中一個或多個函數，驗證結構是否正確，數據是否存在內存溢出。模塊測試針對與業務或程序有關的某一個具體的功能，有設定范圍的輸入和預期的輸出。模塊集成主要針對的是模塊之間的耦合關系，系統中存在大量的模塊，模塊與與模塊之間的數據是否能能夠進行數據和參數交互，運行過程中是否會起沖突報錯都要進行驗證。系統測試是整體提示，從用戶使用角度出發，檢驗功能是否滿足包括硬件配置、網絡環境、軟件功能等在內的使用預期。端到端側重業務實際，需要考慮功能與業務結合的合理性，高效性，升級可拓展性等［50］。

系統測試要從功能和性能兩方面分別進行。功能立足軟件開發功能需求說明分析和說明文檔，實現數據的輸入和既定輸出。性能需求包括系統響應速率，穩定性，安全性，擴容性，以及可維護性等，對系統的使用體驗有非常重要的影響。

6.3測試準備和測試計劃

超市管理系統基于C/S結構設計，應用服務和數據庫安裝在同一臺計算機上, 硬件配置環境如下:

CPU: 2 核處理器

內存: 32GB

硬盤:可用空間大小 500GB

局域網地址: 60.60.60.51

操作系統環境: Windows7

系統平臺: .net

軟件開發工具: VS2005

數據庫: SQLservre2005

在系統測試之前要制定詳細的測試計劃，測試過程中及時記錄測試結果，測試完成后對問題進行匯總和分析。準備內容和表單內容如下:

（1）測試問題匯總舉例，如表6-1所示:

表6-1 測試表模板

序號用例描述測試方法期望結果實際結果

1 在供應商決算界面可以清晰獲知已付款和未付款信息在結算界面選擇供應商為“新希望”，表體行輸入訂單編

號001 自動顯示單據總金額，已付金額，本次應付金額，以及需要錄入的本次付款金額符合/不符合

2）測試內容和周期,見表6-2所示：

表6-2 測試內容和周期表

序號模塊內容時間

1 系統及用戶管理用戶登錄、用戶管理 1月20日-1月27日

2 基礎信息包括供應商、客戶、商品等資料的增、

刪、改查等 1月20日-1月27日

3 采購采購訂單、采購入庫、采購退貨以及采購價格調整單據的增刪改查，以及與數據庫數據的同步 1月20日-1月27日

4 銷售銷售訂單、銷售岀庫、銷售退貨單據的增刪改查以及對應數據庫數據的同步更新 1月20日-1月27日

5 庫存庫存數據查詢、盤點以及庫存保質期預

警的實現 1月20日-1月27日

6 財務在系統中與客戶和供應商分別結算，驗

證賬實是否一致 1月20日-1月27日

7 報表采購匯總表、銷售匯總表、銷售排行表、

利潤表的查看和數據驗證 1月20日-1月27日

3）測試驗收文檔列表，見表6-3所示：

表6-3 測試驗收文檔

序號文檔名稱目標

1 軟件總體設計方案一份

2 軟件概要和詳細設計方案一份

3 軟件程序源代碼一組

4 軟件項目測試報告一份

5 軟件用戶操作手冊一份

6.4 軟件測試

6.4.1 功能測試

1）操作員和基礎信息檔案測試用例，如表6-4所示：

表6-4 操作員和基礎信息檔案測試用例表

序號用例描述測試方法期望結果實際結果

1 管理員登錄系統后可以查看所有用戶信息，也可以在用戶管理界面對所有用戶信息進行修改、刪除操作。系統對操作員信息的更改使得數據庫中的操作員信息表同步更新在系統的后臺操作員組別中新建用戶 “小明”，設置密碼 “123”，保存數據提交保存按鈕后，在數據庫系統對應的操作員表中多出一條人員信息符合

2 在供應商管理界面通過前臺的搜索功能，可以連接到數據庫進行檢索，并將結果反映在系統界面打開供應商基礎信息管理界面，在索欄中鍵入系統中已經存在的任意的一個供應商名字，點擊右邊的“查詢”按鈕右邊的顯示頁面出現“新希望食品批發公司”的信息明細符合

3 在客戶信息管理界面，雙擊打開任一條客戶資料，修改名稱名稱等信息，關閉后再重新瀏覽，對應數據庫中的信息更新完畢且，而且能夠在系統界面中進行查看打開客戶資料“博欣科技有限公司”，刪除名稱中的“科技” 二字，保存，退出在查詢欄中輸入 “博欣”二字進行模糊查詢，結果顯示欄中出現

“ 博欣有限公司”，客戶名稱發生變化。符合

4 在商品信息檔案中選中任意一條商品目錄，選擇菜單欄中的刪除按鈕，數據在系統界面和對應的數據庫表中同步消失選中視頻分類中的

“泡鳳爪”，點擊“刪

除”按鈕數據被刪除符合

2）用戶登錄測試用例,具體內容如表6-5所示：

表6-5 用戶登錄測試用例內容

序號用例描述測試方法期望結果實際結果

1 每個用戶都有唯一的用戶識別碼進入系統第一次，在用戶登錄界面輸入用戶名“ 1001”和正確的登錄密碼“01”；第二次，在用戶登錄界面輸入用戶名“1001”和錯誤的密碼。 1001成功進入系統；1001的登錄的界面彈岀提示語句：“密碼錯誤，請重新輸入” 符合。密碼輸入錯輸時系統提示見圖6-1 所示

2 用戶可以對自身密碼進行修改。要求輸入舊密碼一次，新密碼兩次。無論修改是夠成功，系統都會給岀相應的提示修改用戶1001的密碼，在“輸入原密碼”框中鍵入舊的密碼：01，在 “輸入新密碼”輸框中鍵入數字02，在“重復新密碼”框中鍵入數字03，然后點擊“確定” 系統彈岀提示框 “您輸入的新密碼和與重復密碼不同，不能修改用戶密碼” 符合。兩次

新密碼不同時系統提示見圖6-2 所示

修改用戶1001的密碼，在在“輸入原密碼”框中鍵入舊的密碼：01，在“輸入新密碼”和“重復新密碼” 框中鍵入數字02，然后點擊“確定” 系統彈岀信息框 “用戶密碼已被修改，下次登錄系統時請使用新密碼” 符合。兩次新密碼一樣時系統提示見圖6-3 所示

用戶登錄和密碼修改測試用例圖如下：

圖6-1 密碼輸入錯誤時系統提示

圖6-2 兩次新密碼不同時系統提示

圖6-3 兩次新密碼一樣時系統提示

3）采購管理測試用例，具體內容如表6-6所示

表6-6 采購管理測試用例

序號用例描述測試方法期望結果實際結果

1 打開采購入庫新增界面，

在表頭和表體中空出部分字段，然后執行保存命令，看系統是否會有提示錄入表頭供應商基本信息，在表體中不做錄入，然后單擊菜單欄中的

“保存”按鈕系統提示單據不完整不能保存，商品名稱不能為空，單據保存失敗符合

2 在采購入庫單表體中的一行數據表示一種商品信息，同一個入庫驗收單可以包含同一個供應商同一次采購行為的多條商品信息目錄在一張空白的入庫驗收單的表體中錄入一行商品信息，移動鼠標至下一行表體中的行號會自動增加1，點擊行號數字所在的行，系統會自動出現一條空的商品信息輸入欄供用戶輸入新的商品信息符合

續表6-6 采購管理測試用例

序號用例描述測試方法期望結果實際結果

3 在采購訂單錄入包括表頭和表體在內的商品采購信息，如果訂單信息錄入錯誤需要刪除，需要區分表體行清除還是行選擇性刪除打開有三條及以上商品信息的采購訂單，選擇表體中的一行，選擇菜單“編輯”欄中的

“清理明細” 按鈕；然后再點擊菜單欄中的“刪除” 按鈕第一次操作執行完后只刪除了選中的一條商品信息；第二次操作后采購訂單表體中的其他兩條商品信息全部被刪除。符合

4）銷售管理測試用例, 具體內容如表6-7所示：

表6-7 銷售管理測試用例

序號用例描述測試方法期望結果實際結果

1 銷售岀庫單中的商品數量不能大與庫存數量，當數量大于庫存數量時，單據不能保存庫存中泡雞爪的數量為5，在銷售岀庫單頁面的商品數量欄中輸入數字6，保存單據系統提示“岀庫數量不能大與庫存數量，請重新輸入” 符合

2 銷售訂單錄入客戶名稱和商品名稱、數量等基本信息后進行保存，系統提示操操作成功在銷售訂單界面依次錄入空白項目，點擊菜單欄中的“保存”按鈕系統提示保存成

功符合

3 銷售退貨錄入銷售單號后系統會自動帶岀銷售單對應的客戶信息、商品名稱、數量以及價格等信息。數量可以修改，但只能小于等于自動帶岀的數量新增一張銷售退貨單，輸入銷售單號。第一次將數量修改成大于默認數量，保存單據；第二次將數量修改成小于等于默認數量，保存單據第一次保存時，系統提示“退貨數量不能大于岀庫數量，請重新輸入”。修改數量后系統提示單據保存成功符合

5）庫存管理測試用例，具體內容如表6-8所示

表6-8 庫存管理測試用例

序號用例描述測試方法期望結果實際結果

1 在庫存查詢界面通過商品或供應商名稱獲得商品庫存數量輸入某一具體的商品名稱，點擊

“查詢”按鈕出現商品名稱和數量以及對應供貨商等信息符合

2 在庫存盤點界面選擇特定商品，系統關聯并調用數據庫庫存表中的商品數量顯示到界面“系統庫存”字段，在系統中錄入實盤數量，系統自動計算盤虧盤盈，單據保存后及時更新對應的庫存表數量信息選擇某一特定商品，在庫存盤點表中的“實盤數量小計”調整成與“系統庫存”不同的數字，保存單據在庫存查詢界面查找這一商品信息，商品數量變為“實盤數量小計”的數量符合

3 在商品有效期預警界面能夠查看多所有或者特定商品的保質期和報警信息輸入任一庫存存量商品，點擊查詢按鈕能夠看到“入庫日期”、“保質期”和

“有效/過期天數” 符合

6.4.2 性能測試

我們采用兩種方法對系統性能進行了測試:loadRunner工具法和實際應用監測法。

loadRunner是一種非常常用的系統性能測試工具，可以模擬用戶操作行為，動態顯示實時監測效果。監測時間短、速度高，幫助開發者快速優化產品。本系統先使用loadrunner工具來進行多次速率性能測試，得到系統登錄時間、單據保存時間、單據查詢時間的平均時間都在毫秒級，系統對反應速度的要求。性能測試系統響應曲線如圖6-4所示：

圖6-4系統響應曲線

考慮到超市管理系統伴隨超市日常營業時間比較久，為了確保系統的穩定性, 我們在啟用系統功能后保持了連續5天不關機不退出的狀態。在這期間所有的系統測試照常進行，每天會在系統進行錄單和數據增刪改操作，系統一切功能運行正常，經受住了考驗。

6.5 測試結果

軟件開發工作完成后，需要對產品功能進行測試和驗證。我們分別選取了各個某塊的部分功能進行實例檢測，結果與預期基本一致，功能方面，無論是系統登錄還是基礎數據的修改都很順暢，制單可以順利的調用基礎數據并進行保和修改等操作，查看單據也能夠按照整體和過濾法查詢。性能方面，也做到了快速響應與安全穩定性能兼具。整體來講，能夠滿足本次開發設計的要求。

6.6 本章小結

本章是在軟件系統開工作完成的基礎上，根據系統測試方法和理論，設計岀針對性的測試用例，使用專業的測試工具，結合軟件功能需求說明文檔對系統從模塊和整體兩方面分別進行了功能和性能測試。經過驗證，系統基本滿足設計開發需求，如果需要拓展業務或擴展軟件功能，系統也能夠提供很好的支持。

第七章總結與展望

根據走訪的調研結果我們發現很多小而散的零售超市在目前信息化高速發展的今天依然保留落后的手工記賬或簡單的 POS 收銀方式進行管理經營，將這些小中型超市和便利店做為研究對象，結合他們的管理日常，開發出了一套包含采購、銷售、庫存、結算等功能的信息系統。從選題到軟件實現經歷了一年的時間，目前已將系統部署到兩家小超市的店鋪中供他們使用，運行穩定，我們會繼續不定時的去收集意見和反饋，對系統進行功能和性能進行持續優化。

軟件開發工作是一項系統的工作，在項目立項和實現的整個過程中，對軟件工程理論，信息系統開發方法，系統建模方法，數據庫知識， .NET 技術，系統開發語言等有了更深刻的認識和理解，將所學理論組合并用，實踐水平有了提高。

此次開發的小型超市及零售行業信息管理系統在征得超市老板同意后部署安裝在超市系統中試運行，試用一星期后功能得到了肯定。總結本人的貢獻和系統的特點，主要有以下幾點:

（1）安裝部署簡單

系統基于 Windows 操作系統，符合大多數人平時操作電腦的習慣，不需要重新適應和過多的技術培訓，環境簡單，操作容易。

（2）開發使用成本低

系統對硬件要求不高，客戶端、服務端以及數據庫可以同時部署在一臺家庭普通PC機上，對經營者來說總體成本低，投入少，沒有經營壓力。

（3）前后臺數據統一

大多數的超市都用了 pos機進行掃描認貨,我們此次不但對系統的后臺管理軟件和數據庫進行了全部設計，也通過數據庫將前臺的部分 POS 數據進行了整合，完整呈現超市經營情況，很好的提高了系統的總體性能和適用性。

（4）可以直觀看到各類報表

在滿足了基本的單據查詢功能的基礎上，提供了比較實用的數據分析功能，如銷售排行、毛利排行等報表。幫助經營者更快了解超市經營狀況。

（5）有數據備份功能

小超市個人計算機硬件配置整體偏低，經常疏于維護，硬件更換維護的可能性比較大，為了方便后期數據遷移，此次開發增加了數據備份的功能，為數據安全增加了一層保障。

（6）功能可擴展

采用模塊化的設計理念進行軟件開發，預留了接口，方便后期增加新的功能。

在本次的系統開發為超市管理提供了一種新的管理手段，通過技術與信息化的思想，解決了超市經營最核心的幾個問題，因為時間問題，系統功能還夠不夠全面，已有的一些功能也需要進一步細化。后期需要改進和增加的地方大致如下：

（1）對每樣商品設置庫存預警，當商品庫存數量小于最低標準或采購數量大于最高設量時系統給岀提示并進行限制，規范采購和銷售行為

（2）系統單據之間的關聯關系比較薄，后期可以通過增加單據之間的強關聯關系，對業務的進度進行監督和管理，使得管理流程化，細致化。

（3）增加更多的報表查詢功能，對數據進行多維度的統計和分析。體現超市經營情況和經營風險。幫助經營者更加科學的管理庫存，為調整商品結構提供依據，促進商品銷量。

（4）為了吸引和維護客戶群體，一部分超市也開始借鑒超市發售會員卡的方式來促進銷量。在系統中增加會員管理和積分兌換的功能，通過序號或電話作為身份識別ID，幫助經營者簡單有效的進行會員管理。

（5）增加更多的與往來核算有關的功能，增加與超市有關的供應商和客戶之間的商品往來和財務往來數據，可以對往來單位的交易進行分析和統計。

（6）為了更好的經營超市，超市會有各種各樣的銷售模式和價格策略。如零售價、批發價、限時特價、買一送一價、滿額減優惠價等。系統中關于銷售模式、價格設定的功能比較簡單，后期可以根據實際情況對銷售模塊功能進行擴展，同時增加與之相關的報表統計功能。

（7）超市商品種類繁多，為了快速定位商品位置，后期可以增加庫位管理，方面統計和數據分析。如果以后開分店，店與店之間會進行商品的調撥，這種業務類型也比較常見，后期需要增加庫存商品調撥功能。

隨著信息化的高速發展，任何行業都逐漸被數字化，想要立足和發展，不管定位如何，不管規模大小，都要想辦法盡快的獲知行業信息和自身經營狀況。超市管理系統能夠幫我們匯總、展示和分析數據，為決策提供依據。高效率的信息處理能力幫助我們適應市場，提高競爭力，通過促進銷售和節約成本實現規模擴張和利潤增長。

致謝

從畢業設計開題到畢業論文的完成過去了將近一年的時間，在這期間得到了包括導師、班主任、同學以及很多人的幫助和支持，非常感激他們在我需要的時候給予強大的耐心和無條件的支持。感謝讀研期間所有的授課老師，是他們教授我們軟件工程的理論和知識，為這次畢業設計的準備和開發提供了方法和技術支撐。

感謝高原老師和伍銅根導師，在確定論文題目后對我提出的關于系統實現的技術疑問進行了答疑和指導，在仔細閱讀了我的開題報告后，及時給出了很多參考意見。在軟件設計開發的過程中，因為低估了工作量，放松了對自己的要求，導致進度緩慢，高老師及時的提醒才促使我加快開發合論文撰寫進度，保證了論文能夠按時交付。在我遇到問題時，高老師也總是非常耐心的傾聽，然后給出詳細的指導，幫助我客服了很多難關。論文初稿撰寫完成后，兩位老師幫我審閱資料，發現問題并提出修改意見，在他們的幫助下，這篇論文才最終完成。

感謝班主任周老師的無私服務和付出，感謝我的同學無條件的幫助和鼓勵，感謝配合調研的所有參與者的答疑和建議，無論是專業的啟發還是做事的態度都讓我受益匪淺。憑我一己之力不可能順利的實現論文從設計到完成的整個過程，真心感謝所有幫助過我的人，謝謝！

謹以此文獻給大家。

參考文獻

[1].莫琦友.我國超市管理的現狀與發展趨勢管窺[J].商場現代化,2015, (3): 3-7

[2].蘇焱.淺析我國超市管理的現狀與發展趨勢[J].商場現代化,2014,(17): 12-14

[3].黃智萌.中小型超市的現狀及發展對策研究[J].湖南工業職業技術學院學

報,2009,9(6)：36-38

[4].蔡方敏.淺析沃爾瑪超市發展現狀及存在問題分析[J].今日湖北(中旬

刊),2013,(6)：23-27

[5].呂葉.沃爾瑪供應鏈管理對中國零售業的啟示[D].大連:東北財經大學,2007,17-22

[6].M.Munir Ahmad,Ruben Pinedo Cuenca,Critical success factors for ERP

implementation in SMEs[J].Robotics and Computer Integrated Manufacturing,2012：44-47

[7].James A senn.Analysis and design of information systems[M]. new York ：

daniya,1993,Mcleod.Management Information system Management in Practice[M].California: bicontin ,1998,12-16

[8].李賀.倉儲部門物料入庫管理系統設計概要[J].上海大中型電機,2008(2):6-15

[9].唐閏淥，彭曦，陳超等.連鎖店進銷存管理系統的設計與研究[J].中小企業管理與科

技,2009(04):20-23

[10].劉渝妍.ERP在中小企業管理中的實施及應用研究[D].昆明：昆明理工大學.2005.8-10

[11].趙曉霞.進銷存管理系統的設計與實現[J].煤炭技術,2010(01): 251-253

[12].張海藩.軟件工程(第4版)[M].北京：人民郵電岀版社,2013,108-111

[13].郝曉玲.信息系統開發方法.案例與實驗[M].北京：清華大學岀版社,2012,12-16

[14].張潔.小型超市資源管理信息系統研究[J].渭南師范學院學報,2011, 26(6):17-19

[15].冉春玉，姚輝.基于C/S和B/S模式的進銷存系統的設計和實現[J].武漢理工大學學報, 2003,20(3):2-9

[16].劉超.軟件體系結構研究綜述[J].軟件學報,2002,13(7) :20-25

[17].鮑建光，張佳驥.軟件體系結構可靠性分析[J].無線電工程,2009, (06): 45-47

[18].明日科技.C#從入門到精通(附光盤第3版)[M].北京：清華大學岀版社,2012,19-24

[19].明日科技.C#項目開發實戰入門[M].北京：清華大學岀版社,2017,2-26

[20].秦婧等.精通C#與.NET 4.0數據庫開發[M].北京：清華大學岀版社,2011,87-92

[21].邵維忠，梅宏.統一建模語言UML述評[J].計算機研究與發展，1999, 36(4): 12-18

[22].白妍麗，韓娜.UML結合軟件工程案例化教學與探索[J].中國科技縱橫,2012,(23): 67-70

[23].劉晙.以超市管理信息系統為例的UML實例化教學研究與探討[J].現代計算機：下半月版,2012,(24):22-32

[24].FowlerM,Scott.K.UML Distilled,Applying the Standard Object Modeling Language[M].Reading Massachusetts:Addison-Wesley Longman Inc,1997,127-129

[25].劉鳳華，董智勇.UML在商業連鎖超市進銷存系統建模中的應用[J].河南工程學院學報(自然科學版),2008,(3)： 79-81

[26].張龍祥.數據庫原理與設計[M].北京：人民郵電岀版社,2006,55-76

[27].羅瑞明.關系型數據庫基礎[M].北京：機械工業岀版社,2013,41-43

[28].蔣秀英，張建成.SQL SERVER 2000數據庫與應用[M].北京：清華大學岀版社，北京交通大學岀版社,2010,30-50

[29].吳溥峰，張玉清.數據庫安全綜述[J].計算機工程,2006, (12): 108-114

[30].朱海衛.應用系統中的數據庫安全性研究及實現[D].北京：北京郵電大學,2006,45-48

[31].徐保民，楊銓玖,胥愛軍.數據庫系統原理與應用[M].北京：清華大學岀版社,2005,22-26

[32].Gersld Post,Albert Kagan ． Database management systems ： design Denglusiderations andattribute facilities[M]. American ： The Journal of Systems and Software,2001,56(2)： 184—193

[33].Ullman Jdffrey D．Principles of Database Systems[M] ．American： Computer Science Press,1992,12—14

[34].Ricardo Ctherine．Database Systems：Principles Design＆Implementation [M]. American：Macmillian Publishing Company,1990,40—42

[35].李師賢，張珞玲.需求分析的常見問題及其對策分析[J].計算機工程 ,2012(28):85-92

[36].[澳]麥斯阿塞克.需求分析與系統設計[M].(馬素霞)譯.北京：機械工業岀版社，2009,223-230

[37].劉騰紅，孫細明.信息系統分析與設計[M].北京：科學岀版社,2003年,20-25

[38].周樸雄.訪問控制在數據安全系統中的應用[J].中國圖書館學報,2004(03):12-15

[39].[美]巴里•伯曼(BarryBerman),[美]喬爾?R.埃文斯(JoelR.Evans).零售管理[M]. 北京：中國人民大學岀版社,2002,43-48

[40].鄭小蓉.超市管理系統的面向對象分析[J].科技展望,2016,26(18): 33-49

[41].[美]J.J. Glenn Brookshear.計算機科學概論[M].北京：人民郵電岀版社，2017,232-241

[42].周斌仲.軟件圖形用戶界面設計[D].武漢：武漢理工大學,2005, 81-83

[43].史嚴梅.淺議零售信息系統的安全管理[J].科技視界,2013,(14):13-15

[44].拉斯克蘭德，陳永劍(譯),挑戰黑客.網絡安全的最終解決方案[M].北京:機械工業岀版,2010,35-40