郵政儲蓄銀行客戶營銷積分系統的設計與實現目錄郵政儲蓄銀行客戶營銷積分系統的設計與實現 1摘要： 4第1章緒論 51.1研究背景 51.2國內外研究現狀 6第2章郵政儲蓄銀行客戶營銷積分管理系統的相關技術 72.1統一建模語言UML介紹 72.1.1UML的建筑塊 72.1.2類 82.1.3關系 92.1.4通用機制 92.2Struts框架 92.2.1MVC設計模式 102.2.2Struts工作原理 112.2.3應用實例 122.3Hibernate與持久層ORM 122.3.1hibernate 122.3.2hibernate工作原理 13第3章郵政儲蓄銀行客戶營銷積分管理系統的需求分析 133.1系統業務流程 133.1.1概要分析 143.1.2具體分析 153.2系統用例模型 203.2.1參與者描述 203.2.2用例模型 213.3用例的活動圖描述 263.4需求原型系統 323.5性能需求 333.6其他需求 343.6.1安全性需求 343.6.2數據性能需求 34第4章郵政儲蓄銀行客戶營銷積分管理系統的設計 354.1概述 354.2時序分析 354.2.1客戶信息變更管理 364.2.2客戶積分管理 374.2.3查詢記錄（按客戶ABC等級） 384.2.4查詢記錄（按商圈） 394.2.5卡類型管理 404.2.6客戶信息建檔 414.3類分析模型 414.3.1邊界類 424.3.2領域類 434.3.3實體類 434.3.2總體類 474.4數據模型 474.4.1概念模型 484.4.2邏輯模型 484.4.3完整數據模型 50第5章系統設計與優化 505.1系統架構設計 515.1.1系統架構的選擇 515.2.2系統架構的配置 525.2持久化設計 525.3.1ORM（對象——關系映射） 535.3.2數據庫物理設計 535.3系統功能設計 545.4實體類設計 555.5系統流程對象設計 565.6系統界面設計 575.6.1界面顯示設計 575.6.2界面流轉邏輯設計 585.7代碼設計原則 595.8面向對象的優化設計 595.8.1業務邏輯優化 595.8.2靜態類優化 605.8.3程序代碼結構優化 62第6章郵政儲蓄銀行客戶營銷積分管理系統的實現與測試 626.1系統實現 626.1.1系統主界面 626.1.2客戶管理模塊 636.1.3客戶營銷積分模塊 656.1.4查詢記錄模塊 656.1.5系統設立模塊 686.2系統測試 696.2.1系統測試內容 696.2.2系統測試方案 706.3系統用例設計 706.3.1性能測試用例 716.3.2邊界值測試用例 716.4測試結果分析 72第7章總結 73致謝 75參考文獻 76摘要 著商業銀行多元化業務的開展，以及行業內競爭日趨劇烈化，為提高商業銀行綜合競爭力，加快銀行業務整合營銷步伐，引導和鼓勵客戶使用銀行各類金融產品和金融服務，豐富促銷手段，加強客戶關系維護，提高客戶忠誠度，連續增長銀行收益，培養并吸引優質客戶群，按照“以客戶為中心”的經營理念，商業銀行需要根據客戶對本行各類業務的整體奉獻度進行一個全面度量和綜合管理，由此設立了銀行客戶營銷分管理系統關鍵詞：多元化、系統設計、系統實現、商業銀行Abstract Withthediversificationofcommercialbanks,aswellastheincreasinglyfiercecompetitionintheindustry,inordertoimprovethecomprehensivecompetitivenessofcommercialbankstospeedupthepaceofintegratedbankingbusinesstoguideandencouragecustomerstouseallkindsofbankfinancialproductsandfinancialservices,Strengthencustomerrelationshipmaintenance,improvecustomerloyalty,continuetoincreasebankrevenue,trainingandattracthigh-qualitycustomerbase,inaccordancewiththe"customer-centric"businessphilosophy,commercialbanksneedtocustomersbasedontheoverallcontributionofvarioustypesofbusinessforacomprehensiveMeasurementandintegratedmanagement,whichsetupabankcustomermarketingsub-managementsystemKeywords：Diversification,systemdesign,systemimplementation,commercialbank第1章緒論1.1研究背景 內銀行業隨著中國加入WTO，越來越多的機遇和競爭擺在了眼前。一方面是可以更加容易的引進其他國家的先進技術經驗；另一方面，實力雄厚的跨國銀行和財團的涌入，給國內金融市場帶來更多的壓力，國內銀行業面臨著前所未有的壓力。不遠的將來，加入WTO的沖擊將導致國內金融市場一體化，國內銀行業生存空間將進一步被蠶食。隨著商業銀行多元化業務的開展，以及行業內競爭日趨劇烈化，為提高商業銀行綜合競爭力，加快銀行業務整合營銷步伐，引導和鼓勵客戶使用銀行各類金融產品和金融服務，豐富促銷手段，加強客戶關系維護，提高客戶忠誠度，連續增長銀行收益，培養并吸引優質客戶群，按照“以客戶為中心”的經營理念，商業銀行需要根據客戶對本行各類業務的整體奉獻度進行一個全面度量和綜合管理，由此設立了銀行客戶銷銷積分管理系統。郵儲銀行就是在以上背景下完畢了郵政儲蓄銀行客戶營銷積分系統，系統面向銀行客戶積分管理、積分查詢、積分渠道采集、積分抵扣管理以及積分禮品兌換管理，構建了集業務管理、客戶管理和積分管理的工作模式，實現了提高銀行客戶積分管理工作效率，節約了資源成本的目的。1.2國內外研究現狀近幾年來，計算機技術和網絡技術的迅速發展，為銀行公司的信息化建設提供了便利的技術條件，在整個電子銀行世界范圍內大發展的背景下，我國開始根據我國國情實行具有中國特色的銀行信息化系統、客戶積分管理系統。如今客戶積分管理成為國內外眾多銀行信息化發展、市場競爭的重要手段，中國商業銀行要想提高客戶積分管理管理，必須推動技術創新。早在前些年，我國的一些商業銀行就提出，要充足發揮科技力量，依靠雄厚的資金實力，在現代產品銷售管理系統中，一方面引入了信息管理的模式。目前國內國外積分管理系統已經廣泛應用到電子商務領域，如國內外各大商業銀行系統、國內淘寶網，美國的易趣網、日本的chobirich網等等。當用戶使用銀行服務、網站購買商品、參與銀行或網站商戶提供的各種廣告活動、論壇發帖、回答游戲等，均可獲取一定的積分。而用戶使用這些積分，可直接在銀行商城或網站商城上消費，或兌換各大特約商戶的聯名積分、實體禮品、電子貨幣、實體商場的鈔票禮品卷等等。近幾年來，國內外各個行業的客戶積分管理系統發展迅速，通過查閱文獻，對客戶積分管理分以下幾類進行研究。1）國內外典型超市客戶積分管理系統的應用狀況通過查閱相關文獻資料，了解到目前國內外一般超市都投入運用了客戶積分管理系統，如沃爾瑪，家樂福等均建立了完善的客戶積分管理系統，其首要目的實現會員基本信息管理，在此基礎上還完畢了一些業務功能，比如沃爾瑪超市客戶積分管理系統實現了會員積分管理和儲值管理，為方便會員消費交易，會員卡具有小額度儲值功能，會員在消費時，對一些交易的零錢可以從會員卡中扣除，或收銀員無需找零，把其存儲在會員卡上，方便以后交易時使用，這樣減輕了收銀員的工作，方便了客戶消費。家樂福超市會員采集系統通過會員登記信息，借助短信平臺，向會員發送超市近期優惠活動信息，使會員及時了解超市的營銷動態，方便公司的營銷推廣。2）國內外大型連鎖店客戶積分管理系統的應用狀況除零售行業外，國內外大型的連鎖店也實行了客戶積分管理系統，比較典型的是一些連鎖酒店的客戶積分管理系統的普及應用，如七天連鎖酒店、如家連鎖酒店等，這些酒店的客戶積分管理系統是基于全國聯網的會員信息共享模式，國內任何一家分店可以登錄查詢會員基本信息、會員消費、積分兌換、各種記錄信息等，會員可以登錄門戶網站進行酒店預訂、積分禮品兌換等操作，分店操作人員可查看會員的酒店預訂信息、積分信息、消費信息等。3）普通行業客戶積分管理系統的應用狀況除連鎖店客戶積分管理系統外，一些普通行業的客戶積分管理系統也逐漸興起，如餐飲客戶積分管理系統、汽車美容店的客戶積分管理系統、健身會所客戶積分管理系統等，這些客戶積分管理系統一般實現的功能較單一，一般根據業務的需求對會員基本信息進行管理，實現單一的功能需求，如會所客戶積分管理系統用于管理睬員消費次數，判斷會員是否到期等。通過查閱相關參考文獻，從系統架構分析，系統一般采用了基于C/S構架，這是在當時從B/S構架方面安全考慮的，采用的C/S構架需要在客戶端維護相關程序，升級成本較大，并且不容易擴充客戶端，隨著B/S構架技術的不斷完善，特別是隨著.Net、JAVAEE等框架成熟發展起來，B/S在安全面的管理已完善，因此構建銀行客戶積分管理技術上具有了成熟條件。B/S系統規定只要通過聯網瀏覽器可以實現系統的操作，B/S系統在服務器性能規定上較高，可以承受多用戶的并發訪問及解決，實現多部門多用戶的在線并發訪問。第2章郵政儲蓄銀行客戶營銷積分管理系統的相關技術近年來，JAVA技術發展進一步、廣泛，其中，J2EE應用非常普遍，其作為大型公司開發工作常見的集成開發工具，能提供各層面、各領域的復雜技術支撐。J2EE可在表現成、業務層、領域模型等層次逐層開發，且各層之間互不混淆，多層級的架構使開發人員工作大為減輕，使具體編程工作思緒更加清楚，進一步實現了組件化、模塊化。J2EE有多種開發架構可供選擇，比較常見且比較經典的架構是STRUTS+SPRING+HIBERNATE。這種架構能比較容易的減少開發工作中各模塊之間的耦合度，提高靈活度。由于相稱于劃分了多個層級的邏輯架構，它允許開發人員對部分層級進行調整，只要層級對外接口特性不變，不會影響到其他層的程序文獻。所以這種架構不僅將軟件模塊化進一步提高，還將面向對象的思想帶到了架構層面。因此，它能輕松解決容器間的服務，大大減少開發工作中復雜問題的難度[16]。

2.1統一建模語言UML介紹2.1.1UML的建筑塊組成UML有三種基本的建筑塊：1、事物（Things）2、關系（Relationships）3、圖（Diagrams）這三種基本建筑塊是逐級變得宏觀的關系。圖中有多個關系，關系中有多個事物。同一個關系中的事物有明顯的關聯；同一個圖中的多個關系構成了系統的重要邏輯模塊。UML中部分類型的事物：1、結構事物（Structuralthings）2、動作事物（Behavioralthings）3、分組事物（Groupingthings）4、注釋事物（Annotationalthings）上述事物作為UML中常用的邏輯抽象概念，是UML模型中比較基礎的靜態組件，代表了現實中存在的真實物體或現實中的部分抽象名詞。1結構事物。常見的事物有7種。第一種是類。類最初從面向過程開發語言引入。在面向過程開發語言中，類是一個具有復雜多種屬性和方法的特殊集合。在面向過程開發語言中，類的概念更加豐富，它還包含了特定的從屬關系、接口。在UML圖中，常用矩形代表類，并標注其名字、屬性和方法等。第2中是接口。一個類中常有多個方法，而大部分方法可以留空不予實現。這時就需要接口描述某個類的相關方法。在接口中，可以對這些方法予以實現，也可以不予實現。在UML圖中，用圓形代表它，且在圓形附近標注接口的名稱。第3種是協作。在約定部分事物和元素的基礎上，定義這些事物和元素之間的操作，并對這些操作進行明確，就構成了協作。因此，協作比它所包含的事物和元素的集合還要大。由于構成協作的事物和元素自身就是結構化，因此協作一般具有結構化特點。在某些類中，也許包含幾個協作，而這些協作基本構成了系統重要功能。在UML圖中，常用虛橢圓代表協作，并在其附近標注名稱。第4種是用例。用例基本上代表了一個應用系統中的核心業務流程和操作。它由針對部分角色的一系列操作組成，在過程中、結果中得到重要的輸出。在UML中，一般采用用例表達事物及其之間的動作。事實上，用例是由多個協作實現的。在UML圖中，常用實橢圓代表用例，并在其附近標注名稱。第5種是活動類。活動類一般可以實現具有多進程、多線程的對象。活動類具有了類的基本屬性特點，但活動類實現的對象和操作方法是真實存在的，且具有多路并發特點。在UML圖中，常用矩形代表活動類，但其邊框使用粗線條。第6種是組件。組件在系統中并不是必不可少的，它可被替換，且種類多樣。常見的組件很多，比如COM+組件，JAVABEANS組件等等。上述7大元素構成了UML圖中常用的各種事物。上述7大元素尚有其各自的衍生形態：進程、線程、文獻、表等。2動作事物作為UML圖中的非靜止元素，動態事物擁有相關動作和操作。它有集中常見的動作。其中一種是交互。由一組對象構成，且能通過一連串的信息交互構成的動作能實現某種希望的結果，這就是交互。在交互中，需明確描述附屬在其上的動作、信息、操作順序、連接關系等。在UML圖中，一般用帶方向的直線代表交互，并在其附近標注其名字。2.1.2類類是具有相同屬性、操作、關系的對象集合的總稱。通常在UML中類被畫成矩形。名稱為便于區分，必須給類命名。類名用一串字符代替，成為普通的類名；而在普通類名前添加途徑名稱，作為相關包的前綴，也是可以的。比如：CTT,J3T::SPR:MYTYPT等均可。在屬性名稱最后加上其類型也可構成類名。組織屬性和方法有時候并不需要把所有圖形屬性和操作都描述。事實上，在大多數時候，很難將所有累的屬性和操作都描述出來，并且也沒有必要。在制作UML圖時，僅需要將與業務關系緊密的屬性和操作描述清楚就可以了。為區分部分屬性、方法，可以在其名稱前加上描述性字符串。類具有的任務功能稱為其職責。一個類，可擁有一至多個職責。在實際開發工作中，需要將類的職責劃分細化成各個屬性和方法。通常在UML中在類圖的最下方用單獨的部分列出類的職責。2.1.3關系依賴關系（Dependency）作為一種特殊關系，依賴意味著：某種屬性的變化也許影響到與其相關的事物和屬性，但是反過來不一定。這種特殊關系的顯示，一般可用依賴關系表達。一般而言，依賴關系意味著一個類的具體方法調用另一個類的對象或屬性作為實參。在UML圖中，可在多個事物之間展示依賴關系。一般化，事實上是繼承，在UML語言里，該關系可存在于多個包之間。關聯（Association）作為兩種對象間的結構化的聯系，關聯關系是指某兩個類可從一個類的對象獲取另一個類的對象。一般情況下，二元關系指兩個對象間的關系，多元關系，指多個對象間的關聯。一般情況下，可使用實線連接多個類，來表達關聯關系。2.1.4通用機制有多重方案，可使UML更便于運用，在使用UML描述模型時，可隨時采用這些方案和機制：specificationsadornmentscommondivisionsextensibility 2.2Struts框架Struts框架的特點計劃構件應用程序（無論是否基于Web），需要至少一種框架包，假如使用基于Web的框架包，Struts就是最佳的選擇。2.2.1MVC設計模式MVC（模型-視圖-控制器）模型可以稱為模型-視圖-控制器模型。模型（模型）是一個解決邏輯問題、獨立外部顯示、內部內容和形式的軟件、計算核心數據、邏輯和功能的軟件，它獨立于具體表達式和I/O操作接口。視圖（視圖）向用戶顯示模型數據和邏輯關系和狀態信息，以及特定形式的表達。該模型實現了顯示信息相同的信息可以有不同的顯示形式。控制器（Controller）是解決用戶交互的軟件，負責控制模式變化的傳播，保證用戶界面和模型之間的關系。它接受用戶的輸入和反饋模型，實現模型的控制，是該模型的觀點，協調一個視圖相應一個視圖和控制器的分離，使得一個模型的多個顯示用戶通過一個視圖控制器模式的改變，和所有其他的依賴于這些數據的考慮，體現在這些的時候，發生了何種數據變化，控制器將改變告知所有的視圖，使得更新顯示。這事實上是一種模型的變化-傳播機制[17]。圖2-1MVC架構VIEW涉及：用戶登錄界面；系統首頁；查詢顯示信息界面；修改信息界面；添加信息界面等。Control涉及：對具體類的查詢功能，添加功能，修改功能，以及相相應的刪除功能。Model層涉及：超市客戶管理系統數據庫的創建，其中涉及實體類，尚有相應的動作結果表等。2.2.2Struts工作原理Struts框架總控制器（ActionServlet）Struts框架總控制器（ActionServlet）視圖JSPStruts-config.xml模型（ActionForm）業務功能類（JavaBean）1、初始化3、填充FormBean4、將請求轉移到具體Action解決2、Http請求5、調用后臺業務功能類完畢商務邏輯6、返回目的相應對象7、轉換Http請求到目的相應對象8、Http相應業務功能控制器（Action）圖2-2struts工作原理圖（1）初始化：Servlet在web.xml中可被定義為自啟動，ActionServlet也是servlet，它是struts的總控制器。Struts-config.xml的內容，可作為struts各模塊初始化相關對象使用。（2）發送請求：請求的傳遞，一般可用提交webframe，或通過網址向服務器后臺提出規定，這些數據一般采用標準HTTP協議。（3）表單填充：在user傳遞請求時，將information存入struts的controller相應的表單屬性中。（4）Assign請求：controller依據配置數據subject動作配置項內容，將請求Assign到各個動作項，同時把相關表單Bean一起提交給這個動作的執行方法中。（5）Handle業務：東走一般情況下，擁有執行方法，具體貫徹有關功能實現（采用相關功能模塊），完畢之后，返回一個動作傳遞對象，后臺服務器通過動作傳遞對象將提交操作完畢。（6）Feedback響應：動作將功能解決的各個數據提交給最終的類和控制組件。（7）Check響應：控制組件依據動作解決功能提交的響應目的，查詢到最終的對象，事實上一般這個結果就是一個HTML頁面。（8）響應User：targect反饋的結果提交給最終目的，并把最終目的以HTML形式發給User查閱。2.2.3應用實例為展示struts使用，這里列出相關代碼。在xml配置文獻中添加相關代碼：<actionpath=/testname=”loginForm”scope=”request”type=”LoginAction”input=”/login.jsp”><forwardname=”success”path=”/success.jsp”><forwardname=”failure”path=”/error.jsp”></action>這里配置了兩個元素：（1）<form-bean>用來配置前臺發過來的Form傳給ActionForm用的，傳到后臺com.baidu.form.LoginForm這個方法會把所有的前臺輸入的東西拿到。（2）<action>里面要填寫的是你希望將這個表單提交到什么途徑。(比如此外一個頁面)request的意思是提交的時候不在地址欄顯示你的提交信息(比如賬號密碼之類的)，為了用戶的信息安全。成功時轉發到“success.jsp”，“failure”表達失敗時轉發到“error.jsp”。2.3Hibernate與持久層ORM2.3.1hibernatehibernate是一個框架，是用來操作數據庫的。它把數據庫中的表，轉換成java類，通過xml文獻來實現類和表之間的映射。這樣的好處在于，可以面向對象的思想來操作數據庫。JDBC的升級版，專用連接數據庫。

此東東比JDBC簡樸使用，不需要輸入很多的連接數據庫代碼。提取數據庫數據也不用循環提取。使用時的方法為：

1.新建一個Java普通項目

2.創建userlibrary加入三個地方的jar包：兩個hibernate一個MYSQL驅動

3.創建hibernate配置文獻，hibernate.cfg.xml

4.建立實體類user

5.在hibernate文獻中尋找eg至底部找出user.hbm.xml映射文獻，copy到映射文獻所在文獻中

6.將映射文獻user.hbm.xml部分加入到hibernate.cfg.xml中

7.創建數據庫，再運用hibernate將實體映射導入到數據庫中

8.創建客戶端[19]。2.3.2hibernate工作原理Hibernate是采用ORM模式實現數據持久層的java組件。它提供了高效的、強大的將java對象進行數據持久化操作的服務。運用hibernate，開發人員可以按照java對象的結果進行持久層的開發，并可以完畢java對象和關系型數據庫之間的轉換和操作[20]。hibernate的工作原理：（1）創建Configeration實例：根據它的構造方法將指定的配置信息(默認hibernate.cfg.xml)讀到內存。一個Configeration實例代表Hibernate所有Java類到SQL數據庫映射的集合。（2）創建SessionFactory實例：當使用Configeration實例創建了SessionFactory實例后，把Configeration對象中的所有配置信息拷貝到SessionFactory的緩存中。SessionFactory的實例代表一個數據庫存儲源，創建后不在與Configeration對象關聯。SessionFactory是線程安全的，通常情況下，一個應用程序只有一個SessionFactory的實例。（3）創建Session實例：通過SessionFactory創建Session實例，session不是線程安全的，每個使用者應當用SessionFactory實例獲得自己的session實例。獲得session實例后就可以運用session的各種方法對對象進行持久化操作了。（4）創建Transaction事務：通過Session的beginTransaction()方法可以得到一個對象的實例。重要用于管理實務。一個事務對象也許會涉及多個對數據庫進行的操作。第3章郵政儲蓄銀行客戶營銷積分管理系統的需求分析3.1系統業務流程基于零售公司對客戶卡的管理構建了一個客戶信息管理系統。客戶卡管理的一般流程：超市計劃部一方面設計并制作不同類型的客戶卡，交給超市服務臺，顧客填寫客戶卡申請表后交給服務員，由服務員為其建立客戶檔案，再進行卡作業解決，將辦好的客戶卡交給顧客，顧客便可以持卡營銷積分[6]。超市記錄部定期根據顧客的營銷積分記錄進行記錄分析，分析結果提交給計劃部，為制定銷售計劃提供依據。系統部根據實際情況，定義返利規則和具體積分返利商品，并結合平常客戶管理信息，為顧客定制特色促銷返利活動。為解決目前客戶卡存在的功能單一、信息不準確、客戶信息資源的浪費等弊端，基于客戶的持卡信息，通過數據挖掘，一是基于顧客信息對顧客進行細分，提供重點服務，提高大多顧客的滿意度、忠誠度。二是對顧客的購買模式進行細分，當客戶再次光顧公司時，判斷他們的價值類型，對他們實行產品組合和交叉銷售。三是對客戶的愛好愛好進行細分，提供各價值類型顧客感愛好的產品及服務。系統重要針對日前零售業客戶卡管理的重要功能，運用現代化的計算機解決技術來實現其核心功能[7]。只有把為客戶提供更優質的服務放在零售業競爭的核心地位，處處考慮到客戶的需求和利益，時常站在客戶的角度來思考問題，最終才干獲得客戶的青睞和忠誠，客戶制的作用才會得到更大的發揮，公司的收益才干更有保證。客戶卡信息管理系統的功能涉及前臺管理和后臺管理兩個大塊。客戶卡信息管理系統重要為了實現基于客戶信息（后臺）和營銷積分信息（前臺）的數據挖掘，通過客戶卡信息管理系統的使用，在對市場行為、購買行為、用戶心理等各方面進行分析后，制定出一套有關產品的特色營銷方案，以增強商家和顧客之間的互動性，從而提高顧客的忠誠度。實現顧客平常營銷積分數據收集、記錄、分析的自動化、查詢的實時化，規避信息孤島，暢通公司的信息流，支持活動決策。HYPERLINK/> <mappingresource="com/membershipcard/model/Product.hbm.xml"/> <mappingresource="com/membershipcard/model/Scores.hbm.xml"/> <mappingresource="com/membershipcard/model/Purchase.hbm.xml"/><mappingresource="com/membershipcard/model/Membertable.hbm.xml"/>5.3.2數據庫物理設計一個完備的數據庫可認為系統的開發帶來很多便利，同時也為實現系統功能鋪平道路。超市客戶卡管理信息系統的數據庫是基于用戶需求開發的，共使用多張數據表。數據庫命名：usercard；數據庫類型：Mysql；連接方式：hibernate。圖5-4重要數據表5.3系統功能設計客戶營銷客戶營銷管理系統客戶管理積分管理查詢記錄客戶消費圖5-5系統功能模塊信息系統功能設計是整個系統設計的核心部分。按照系統架構和I/O設計規定來進行信息系統的功能設計。它通常涉及系統實體對象設計、系統流程對象設計和系統交互設計。本應用的核心功能有：大客戶模塊、客戶營銷積分管理模塊、查詢記錄模塊、活動管理模塊。活動管理模塊涉及積分管理和積分返利，它們所要實現的功能是為客戶卡商品類別定義基本積分率，并可查詢超市不同類別商品的積分率信息。積分計算，再結合基本積分率計算出相應積分，并把積分信息與客戶卡持卡信息建立依賴關系。定義客戶卡返利活動，用于之后客戶卡返利兌換活動的定義。定義客戶卡返利商品，結合超市促銷活動，定義某些商品作為返利商品，在返利活動中定義相應的規則后即可在實際操作過程中按規則進行積分兌換相應的商品。客戶卡升降級，根據客戶積分情況，手動將卡升級為更高級類型的客戶卡。查詢記錄模塊通過數據提取、轉換等過程，并加入基于超市的業務模型和數據挖掘算法，以便能精確的對客戶進行營銷積分愛好分析、價值分類，從而提高公司的服務水平，并提出專項定制化的營銷策略、品牌活動等，從主線上提高公司的客戶忠誠度和市場競爭能力。該模塊重要涉及按客戶等級ABC進行分析，用于查詢、記錄某一促銷活動期間，門店客戶分類別(ABC)的營銷積分及增長變化情況。客戶等級銷售對比分析，用于查詢、記錄某一促銷期間，門店客戶分級別的營銷積分及增長變化情況。客戶年齡結構分析記錄，按客戶的年齡段進行記錄(各年齡段客戶人數及占比；營銷積分額及占比)，以便各門店準確把握本店的客戶年齡結構特性，用于商品組織和促銷。同城店積分查詢，系統可以記錄客戶某個時間段內在同城店的營銷積分積分情況，支持積分累計、查詢、導出功能，用于同城店聯動促銷。記錄分析表支持按積分降序排列。發卡門店客戶商圈分析，發卡門店系統的記錄分析功能，重要用于記錄、分析在本店入會的客戶所處商圈分布情況及銷售額情況[24]。5.4實體類設計結合系統分析過程中得到的實體類以及系統的數據模型，得到如下相應關系：表名重要關鍵字實體類Useridvarchar(20)usernamevarchar(20)passwordvarchar(20)usertypeint(8)idStringusernameStringpasswordStringusertypeintMembertablecardtypevarchar(50)cardnovarchar(50)namevarchar(50)gendervarchar(2)birthdaydatejoindaydatecityvarchar(50)postcodevarchar(10)addressvarchar(50)bussinesscirclevarchar(50)telvarchar(20)mobilevarchar(20)cardtypeStringcardnoStringnameStringgenderStringbirthdaydatejoindaydatecityStringpostcodeStringaddressStringbussinesscircleStringtelStringmobileStringscorescardnovarchar(50)namevarchar(50)validatedateshopnoint(20)scorefloat(20)expendscorefloat(20)lossdatedatecardtypeint(20)cardnoStringnameStringvalidatedateshopnointscorefloatexpendscorefloatlossdatedatecardtypeintproductproducttypevarchar(20)productnovarchar(20)productnamevarchar(10)numeberint(10)pricedouble(20)discountdouble(20)producttypeStringproductnoStringproductnameStringnumeberintpricedoublediscountdoublepurchasePurchasenovarchar(20)cardnovarchar(20)Totalpricedouble(20)Totalscoreint(20)Discountvarchar(20)Bargainpricevarchar(20)PurchasenoStringcardnoStringTotalpricedoubleTotalscoreintDiscountStringBargainpriceString表5-1數據庫表字段與實體對象屬性映射表實體類圖：類是具有相同屬性、操作、關系的對象集合的總稱。每個類必須有一個名字，用來區分其它的類。屬性是指類的命名的特性，經常代表一類取值，類可以有任意多個屬性，也可以沒有屬性，在類圖中屬性只需要寫上名字。操作是類的任意一個實例對象都可以調用，并也許影響該對象行為的實現。一個系統可以看作是由一些不同類型的對象組成的，對象類之間的各種關系反映了系統內部各種成分之間的靜態結構。通過需求分析階段的用例描述和功能分析，客戶卡管理信息系統包含的重要類以及類之間的關系如下圖所示：圖5-6總體類圖5.5系統流程對象設計系統流程設計是對系統分析階段成果的進一步完善和補充，從物理實現的角度對系統設計進行新的分解和擴展。系統流程對象設計按照以下兩個環節進行：1、換名。系統分析階段產生的類和類的方法都是中文，這是為了方便分析人員和用戶的交流，但大多數程序設計語言和開發工具都不能很好地支持中文的類名和方法名，因此把文檔中的類和方法改為英文是很重要的設計環節。2、對類中的方法進行解決。這類解決涉及的內容很多，重要有以下幾種：1）去除不可實現的方法。2）增長功能實現必須的方法。3）改變方法作用域。4）為方法增長參數。5）改名[25]。系統流程對象設計是對分析階段產生的所有流程對象完畢上面兩個環節，但這里篇幅有限，選取系統中客戶管理功能模塊的流程對象進行具體描述，如圖5-7所示。圖5-7“客戶卡管理”流程對象設計5.6系統界面設計人機交互體驗感決定了用戶對系統的印象。設計良好的界面可以引導用戶自己完畢相應操作，起到向導作用。界面設計重要是為了達成以下目的，應按照下表中的規則進行設計。（1）．以用戶為中心設計。由用戶控制的界面，而不是界面控制用戶。（2）．清楚一致的設計所有界面。其風格保持一致，所有具有相同含義的術語保持一致，且易于理解和使用。（3）．擁有良好的直覺特性。以用戶所熟悉的現實世界事務的抽象來給用戶暗示和隱喻，來幫助用戶能迅速學會軟件的使用。（4）．較快的響應速度（5）．簡潔、美觀5.6.1一級界面：二級界面：三級界面：5.6.2界面流轉邏輯設計login.jsplogin.jspindex.jsplogon_user(session)Dispatcher(Servlet)MembershipManagementConsumptionManagementQueryStatisticManagementActivitiesManagement圖5-8頁面流轉邏輯設計圖如圖5-8所示，一方面，用戶打開login.jsp，輸入用戶名和密碼進行登錄。用戶進入系統后，logon_user對象生成，該對象的有效時間將跨越整個會話，同時頁面轉到系統主菜單頁面（index.jsp）。用戶在系統主菜單頁面選擇希望執行的功能后，若權限滿足則轉向用戶所選擇的功能頁面，如MembershipManagement.jsp（客戶管理），隨后用戶開始進行相應的操作。5.7代碼設計原則"開放－封閉"原則(OCP)Open-ClosedPrinciple原則講的是：一個軟件實體應當對擴展開放，對修改關閉。優點：通過擴展已有軟件系統，可以提供新的行為，以滿足對軟件的新的需求，使變化中的軟件有一定的適應性和靈活性。已有軟件模塊，特別是最重要的抽象層模塊不能再修改，這使變化中的軟件系統有一定的穩定性和延續性。里氏代換原則（LSP）LiskovSubstitutionPrinciple（里氏代換原則）：子類型(subtype)必須可以替換它們的基類型。依賴倒置原則(DIP)依賴倒置（DependenceInversionPrinciple）原則講的是：要依賴于抽象，不要依賴于具體。簡樸的說，依賴倒置原則規定客戶端依賴于抽象耦合。原則表述：抽象不應當依賴于細節；細節應當依賴于抽象；要針對接口編程，不針對實現編程。接口隔離原則（ISP）接口隔離原則（InterfaceSegregationPrinciple）講的是：使用多個專門的接口比使用單一的總接口要好。換而言之，從一個客戶類的角度來講：一個類對此外一個類的依賴性應當是建立在最小接口上的。過于臃腫的接口是對接口的污染。不應當逼迫客戶依賴于它們不用的方法。合成/聚合復用原則（CARP）合成/聚合復用原則（Composite/AggregateReusePrinciple或CARP）經常又叫做合成復用原則（CompositeReusePrinciple或CRP），就是在一個新的對象里面使用一些已有的對象，使之成為新對象的一部分；新對象通過向這些對象委派達成復用已有功能的目的。簡而言之，要盡量使用合成/聚合，盡量不要使用繼承[26]。迪米特法則（LoD）迪米特法則（LawofDemeter或簡寫LoD）又叫最少知識原則（LeastKnowledgePrinciple或簡寫為LKP），也就是說，一個對象應當對其它對象有盡也許少的了解。其它表述：只與你直接的朋友們通信，不要跟"陌生人"說話。5.8面向對象的優化設計5.8.1業務邏輯優化業務邏輯優化需要考慮兩件事情：(1)如何將所有業務邏輯中的子事務盡也許均勻地分派到在建系統中去，讓系統中各個部分充足發揮各自特有的功能，不要出現“越俎代庖”現象；(2)如何找到被分解業務的共同部分。業務邏輯在計算機系統中的分解也許使得原本兩個貌似沒有太多共同之處的業務出現了共同點，找到這些共同點，就找到了系統優化的關鍵。對于第一個問題，基本方法就是參照選定的系統架構層次進行分層分派，將業務邏輯中的每個事務分別在所適合的層中實現；第二個問題，一方面可以通過度析時序圖找到邏輯上相同的部分，另一方面可以將該任務向后推，留待靜態類優化時再加以解決。5.8.2靜態類優化靜態類的優化是指拋開業務邏輯，單純從編程語言自身對系統進行的優化。面向對象的程序是不斷迭代的過程，隨著迭代的進一步，系統逐漸變得更加豐富和完善。當開發工作從系統分析轉入系統設計后，會出現和業務邏輯無關的代碼優化問題，這就是靜態類優化。它的基本方法和程序設計語言有一定的聯系，和面向對象程序原則高度相關。而靜態優化完畢后，也許會對業務邏輯優化產生新的提醒，從而導致更進一步的業務邏輯優化。這樣的迭代連續進行，直到業務邏輯在實現層面完全清楚，所有類的設計符合或基本符合面向對象的設計原則。初始類圖User類和Admin類作為系統一般使用者和系統管理者，在使用系統的過程中，例如登錄、退出等操作。將兩者之間出現的相同操作的程序代碼合并在一起，并推送到共同的父類中，生成EntityBean、PersistObject、BaseAction這3個父類。接下來將方法從本來的實體類轉移到抽象類中去，在此過程中將能設定為私有的類一定要私有化，如圖5-8,、5-9、5-10、5-11所示。圖5-8初始類圖（2）靜態類初步優化：將兩者之間的反復代碼合并并推送到父類圖5-9靜態類的初步優化設計結果（3）將共同方法轉移到抽象類：將本來類中的共同方法轉移到抽象類中圖5-10將共同方法轉移到抽象類的結果（4）靜態類最終優化結果圖5-11靜態類優化設計最終結果5.8.3程序代碼結構優化程序代碼結構定義了程序代碼應當如何被組織成文獻、目錄如何分組為庫，這種組織的優劣對于計算機系統而言沒有什么意義，由于無論程序代碼組織的多么雜亂無章，只要它是對的的，編譯程序就一定可以對的且高效地找到所需的文獻并完畢工作；但對于人而言，組織結構混亂的程序代碼難以理解，有時為了讀懂這些代碼所花費的時間和精力更甚，因此程序代碼結構的優化是以方便人特別是非程序設計者閱讀而做的工作。程序代碼組織的基本形式是樹狀結構，其組織層次從大到小依次為：工作環境—項目—包—文獻—類—方法—程序代碼行。第6章郵政儲蓄銀行客戶營銷積分管理系統的實現與測試系統實現是設計工作的最后一步，在此階段中，一方面要根據系統設計方案對系統進行配置，設定相關參數，從而搭建系統運營的軟硬件平臺，然后將測試完的系統程序及相關文獻部署到平臺上。6.1系統實現6.1.1系統登錄界面用戶輸入用戶名、密碼和系統角色后進入客戶卡信息管理系統主界面。在該界面左側部分列該系統的重要功能模塊，中間界面提供平經常規操作的快捷解決方式，如圖6-1、6-2所示。圖6-1系統登錄界面6.1.2客戶管理模塊顧客到門店提出客戶卡申請，并填寫客戶資本資料。客戶服務中信人員審核客戶顧客是否滿足客戶卡申辦條什。為顧客辦理客戶卡，客戶基本信息必須填寫完整。系統應自動控制：必填信息空項，則無法進行下以步操作。直至客戶資料填寫完整后，才干激活客戶卡，使客戶卡得以投入使用，如圖6-3所示。圖6-3客戶管理界面單擊客戶卡開通按鈕，進入客戶卡單據明細頁面。此表中的發卡門店為系統自動填寫，除此之外表中的客戶卡生效日期根據實際情況選擇(假如不選擇，則系統默認生效日期為當天)，其他必填欄位如：顧客姓名、性別、客戶生日、所在城市、電話、地址等，可根據實際情況來進行填寫。客戶領取客戶卡后，在購物時可以刷卡營銷積分，系統自動記錄和更新客戶的營銷積分信息。當客戶信息需要修改時，登錄客戶卡資料維護界面進行信息修改。要修改表中內容可以單擊客戶修改按鈕，輸入查詢條件，單擊查詢按鈕，切換到待修改客戶信息列表頁面，修改完完畢后需要執行保存操作，如圖6-4所示。圖6-4開通客戶卡界面6.1.3客戶營銷積分模塊圖6-5客戶營銷積分管理頁面6.1.4查詢記錄模塊根據現代營銷法則，公司的80％的利潤來自于那20％的忠誠客戶，因此市場營銷的關鍵問題在于在大量客戶的前提下，擬定出誰是20％的高價值客戶，如何發現甚至是如何隨時地發現客戶的價值，準確地定義出超市的優質顧客，這正是數據挖掘作用所在。數據挖掘一般是指從大量的數據中自動搜索隱藏于其中的有著特殊關系性（屬于Associationrulelearning）的信息的過程。數據挖掘本質上就是建模，即發現客觀事物的規律。針對零售公司中已經獲取的顧客數據進行分析，運用數據挖掘算法，建立客戶價值預測模型，發掘不同客戶群體的不同價值，針對新的客戶數據資料進行預測，發掘潛在賺錢客戶，使其可以成為公司發明利潤的價值客戶，通過提供符合客戶需求的服務使其成為公司的忠實客戶，以期大大減少平常促銷活動的盲目性，從而減少銷售成本，提高效率，增強公司核心競爭力。客戶卡信息管理系統的查詢記錄模塊重要針對客戶持卡基本信息和客戶持卡營銷積分信息進行數據挖掘[27]。數據挖掘在本系統的查詢記錄模塊應涉及：（1）銷售、顧客、產品、時間和地區的多維分析；（2）對促銷活動的有效分析；（3）對顧客忠誠度的分析；（4）挖掘關聯信息，以形成購買推薦和商品參照，以幫助顧客選擇商品。1、基于數據挖掘的多維分析（1）數據挖掘的過程原始數據原始數據挖掘抽樣、清理原始數據轉換數據倉庫樣本集圖6-6數據挖掘過程數據挖掘的環節會隨不同領域的應用而有所變化，每一種數據挖掘技術也會有各自的特性和使用環節，針對不同問題和需求所制定的數據挖掘過程也會存在差異。數據挖掘的一般環節如下：①理解數據和數據的來源（understanding）。②獲取相關知識與技術（acquisition）。③整合與檢查數據（integrationandchecking）。④去除錯誤或不一致的數據（datacleaning）。⑤建立模型和假設（modelandhypothesisdevelopment）。⑥實際數據挖掘工作（datamining）。⑦測試和驗證挖掘結果（testingandverification）。⑧解釋和應用（interpretationanduse）。（2）數據挖掘算法數據挖掘技術常見和應用最廣泛的算法和模型涉及：決策樹、神經網絡、基因算法、貝葉斯分類、盼望值最大化方法等。本系統采用決策樹細分客戶資源。運用樣本數據庫，通過對客戶的所在商圈、購買頻度、購買數量、購買時間等因素的分析，建立客戶分類模型，從中提取分類規則，發現某群客戶的重要特性，然后運用這個模型對收集到的新客戶數據進行分析。決策樹算法是一種逼近離散函數值的方法。它是一種典型的分類方法，以自頂向下的遞歸方式構造，對數據進行解決。抱負的決策樹分為3種：葉節點數最少、葉子節點深度最小、葉節點數最少并且葉子節點深度最小。決策樹的好壞，不僅影響了分類的效率，并且影響了分類的準確率。ID3算法的核心是：在決策樹各級結點上選擇屬性時，用信息增益（informationgain）作為屬性的選擇標準，以使得在每一個非葉結點進行測試時，能獲得關于被測試記錄最大的類別信息[28]。由該屬性的不同取值建立分支，再對各分支的子集遞歸調用該方法建立決策樹結點的分支，直到所有子集僅包含同一類別的數據為止。最后得到一棵決策樹，它可以用來對新的樣本進行分類。(3)記錄分析的數據本系統的基礎數據為超市的購物營銷積分記錄，其中涉及客戶顧客和非客戶顧客。顧客的基本資料和營銷積分記錄是進行記錄分析的基礎。在Mysq數據庫中，建立一張數據表，用于存放顧客的購物營銷積分記錄，表名為purchase，通過前臺POS機可以獲得此數據。purchase表中涉及字段：客戶卡號：沒有客戶卡的顧客，客戶卡號為0；交易小票號：顧客一次購物記錄即產生交易票號（顧客購物的交易代碼是唯一的），購物金額：這次購物所花費的費用。商品折扣：根據客戶卡類型可以享受折扣或是依舊超市促銷活動的具體折扣情況設立折扣。假如沒有折扣銷售，記錄為0，假如進行了折扣銷售，則記錄為相應的折扣值。purchase表的主鍵為小票號和客戶卡號。根據客戶分析目的，需要從基本的購物數據表中選出所有的“客戶卡號”字段不為零的交易記錄，即持卡客戶的購物營銷積分記錄。在分析客戶顧客購物記錄時，需要定義可以描述該客戶在這段時間購物特性的變量，不僅需要知道客戶在何時購物以及所購買的商品，并且需要了解客戶的光顧頻率和購物的平均營銷積分額等信息。在對數據進行預解決的時候，需要進行對缺失值的解決、對數據的一致性進行檢查。但在缺失值的解決中，缺失值所占的比例都比較小，可以根據表中的字段來推導具體的缺失值。將數據預解決后的數據轉化成數據挖掘算法可以接受的形式，并產生衍生變量。根據每個客戶的購物記錄，產生表6-1所示的變量：記錄變量備注總購物次數記錄該客戶光顧的商城的總次數總購物數量記錄該客戶購買商品的總數總營銷積分金額記錄該客戶購物營銷積分的總金額數衍生變量備注購物頻率用總購物次數來表達，數值越大，表白購物頻率越高單次購物數量記錄該客戶每次的平均購物數量，等于總購物數量除以總購物次數，以此來衡量客戶購物籃的大小購物平均價格記錄該客戶每次所購商品的平均價格，等于總營銷積分金額除以總購物數量表6-1數據挖掘過程設計的變量根據客戶顧客營銷積分額、購物頻率、單次購物數量和購物平均價格，這三個綜合指標進行排序，并劃分為三個區段，區間一占客戶總數的20％，區間二占客戶總數的40％，區間三占客戶總數的40％，從而把客戶分為三類：區間一的為高價值客戶、區間二的為高潛力客戶和區間三的為低價值客戶。（4）構建決策樹運用IBMDB2IntelligentMiner的決策樹方法對數據進行挖掘分析。根據客戶對超市銷售額的奉獻把客戶分為高價值客戶和低價值客戶。不同類別的客戶相應有不同的特性規則，根據不同客戶類型得出相應的特性規則，高價值客戶的特性規則如下圖所示，設定概率大于72％的特性規則為有效規則。規則編號一二三四五六七八九十購物頻率2/3333222123單次購物數量4333131321購物平均價格-112/332/322/332支持數43693381453864545121表6-2數據挖掘結果根據表6-2的記錄分析，可以認為公司的高價值客戶就是那些頻繁光顧、平均購物數量多以及購買商品平均價格高的客戶，但是假如僅根據區分不同類別客戶，將顯得非常粗糙，并且會漏掉很多高價值客戶。對其進行細分，高價值客戶重要涉及以下幾類，如表6-3所示：類別光顧頻率單次購物數量購買商品的平均價格13-515-4010-2026-3440-9010-2036-3440-9010-20表6-3數據挖掘結果2、超市不同門店客戶商圈分析超市不同門店客戶商圈分析重要用于記錄、分析在本店入會的客戶所處商圈分布情況及銷售額情況，如圖6-7所示。圖6-7查詢記錄頁面6.1.5系統設立模塊該模塊功能涉及系統員對商品折扣，客戶卡積分進行設立，以及該系統的使用者對自己的登陸名和密碼進行修改的操作，如圖6-8所示。圖6-8系統設立頁面6.2系統測試 廣義的系統測試涵蓋在系統分析、系統設計和程序設計3個階段，在系統分析階段，測試的重要工作是確認，即確認評估即將開發的應用系統是否對的無誤、是否可行和有價值；系統設計階段，測試的重要工作是驗證，即驗證系統開發的每個階段、每個環節的結構是否對的無誤、是否與各階段的規定或盼望一致；最后的程序設計階段是對代碼的測試，可以廣泛運用已有的結構化測試技術進行測試[29]。6.2.1系統測試內容常用的軟件測試方法有白盒和黑盒測試。黑盒測試也稱功能測試，它是通過測試用例來檢測每個功能是否能正常使用。本系統采用黑盒的測試方法。在測試過程中重要是為了測試以下幾個方面：(1)是否有數據結構錯誤或外部信息例如數據文獻訪問錯誤(2)復雜運算的時間是否可以接受；正常運營的最大并發用戶數量(3)在接口上輸入數據是否能對的的接受，并且能否輸出對的的數據結果(4)檢查系統實現的功能是否全面、是否有不對的或漏掉的功能(5)是否有初始化功能或終止性錯誤。本系統重要測試的功能模塊如下表6-4所示：序號模塊功能測試結果1登錄模塊登錄系統2退出系統3客戶管理模塊客戶積分信息4客戶卡開通5客戶退卡6客戶修改7系統設立模塊折扣設立8積分設立9密碼設立10查詢記錄查詢記錄（按客戶等級ABC）11查詢記錄（按商圈）12客戶營銷積分客戶營銷積分信息錄入13客戶營銷積分信息查詢表6-4系統測試模塊6.2.2系統測試方案由于客戶卡管理信息系統實現模式為C／S結構模式，基于此基礎上，在測試時對測試環境準備則分為C端(客戶端)和S端(服務端)環境的準備，具體的規定如下表6-5所示：型號配置操作系統、應用軟件服務器端IBM解決器：3.2GHz/800MHz硬盤:最大148G光驅：48X網卡:集成10/100/1000以太網Windows7Tomcat6.0Mysql客戶端PC機CPU：3.2GHz/4.8GHz內存：512M/1G硬盤：80G/30G光驅：52X網卡：10/100以太網Windows7360安全瀏覽器表6-5系統客戶端和服務端測試方案本系統的測試工作采用了自動化測試工具LoadRunner。系統測試重要進行了性能測試和配置測試，性能測試借助于工具完畢，各功能的測試由人工來完畢。測試工具簡樸描述如下：LoadRunner屬于Mercury公司的產品，腳本生成器：錄制調試腳本用的。場景控制器：用腳本生成場景、執行場景，并在場景執行時進行監控。結果分析器：場景結束后將監控的指標整理成圖表展現給用戶。6.3系統用例設計設計測試用例需要有清楚的設計思緒，對要測試什么，按照什么順序測試，覆蓋哪些需求做到心中有數。測試用例設計規定測試用例編寫者對被測試軟件的設計、功能規格說明、用戶試用場景以及程序/模塊結構有比較透徹的理解。6.3.1性能測試用例性能測試是通過自動化的測試工具模擬多種正常、峰值以及異常負載條件來對系統的各項性能指標進行測試。根據客戶卡信息管理系統，設計了以下測試用例：并發測試并發測試的過程是逐漸增長負載，在同一時間點，支持多個不同的操作。LoadRunner中提供IP偽裝，集合點，配合虛擬用戶的設計，以及在多臺電腦上設立，可以比較好的模擬真實的并發。如表6-6所示。用例名稱用例描述一秒內并發XX用戶登錄系統前提條件終端滿足系統最低規定輸入數據無環節一秒內并發10、20、50、100…用戶登錄系統，并連續加壓到最大允許并發用戶數；查看頁面響應速度；查看Tomcatserver和客戶端CPU負載、內存使用希望結果用戶能正常登錄系統，且響應速度不超過規定的3秒；Tomcatserver和客戶端CPU負載、內存使用沒有查過限制表6-6用戶登錄并發測試的用例設計配置測試配置測試是系統使用不同的配置（硬件資源、網絡、應用服務器和數據庫）執行相同的操作來獲得性能數據，其目的是性能調優，用例設計如表6-7所示。用例名稱用例描述用戶在不同網速下登錄系統前提條件無輸入數據無環節限制用戶網絡速度為8KB/s—16MB/s；用戶登錄系統；查看頁面響應速度；查看Tomcatserver和客戶端CPU負載、內存使用希望結果所有網絡速度滿足最低配置規定的用戶都可以正常登錄，且響應時間滿足；Tomcatserver和客戶端CPU負載、內存使用沒有查過限制表6-7用戶登錄配置測試的用例設計6.3.2邊界值測試用例有很多字段都可以使用邊界值法進行測試，設計的測試用例如下表6-8所示：輸入內容規格說明測試案例卡類型值只能是1、2、3當中之一為空1,、2、3當中之一除了1、2、3之外的數值卡號最大為20個字符，不能為空為空1個字符20個字符22個字符名字最大為20個字符，不能為空為空1個字符20個字符22個字符郵編只能是6位數字，可認為空為空1個數字5個數字6個數字7個數字地址最大為50個字符，不能為空為空1個字符49個字符50個字符51個字符商圈最大為50個字符，不能為空為空1個字符49個字符50個字符51個字符固定電話只能輸入數字，區號中間可用“-”分隔，不能少于7位為空1個數字8個數字移動電話只能輸入數字，只能是11位數字，不能為空為空1個數字10個數字11個數字13個數字表6-8邊界值測試的用例設計6.4測試結果分析通過設計的各種測試用例對系統進行測試，生成相應的錯誤報告，記錄錯誤發現的時間和錯誤的具體描述，便于開發人員進行錯誤重現，以縮短錯誤解決的時間。開發人員對于錯誤的解決簡樸記錄以及測試人員重測的結果都會記錄在錯誤報告中，以便進行測試分析。客戶卡管理信息系統測試周期為兩周，期間一共測出問題數220為個，修改成功210個，拒絕6個，延期4個。延期的4個中為操作方面方面的問題。性能測試結果分析見下如表6-9所示：并發測試報告功能用戶登錄客戶卡信息管理系統目的最大登錄數量的并發方法虛擬最大數量的用戶且同時進行登錄操作并發用戶數與事務執行情況用戶并發數事務平均響應時間事務最大響應時間平均每秒解決的事務數事務成功率每秒點擊率平均流量（字節/秒）200.3243.6539.887100%98.871435250.000400.8656.52313.213100%132.132593652.000602.1218.43512.563100%125.634568456.536并發用戶數與數據庫主機用戶并發數CPU運用率磁盤I/O情況DB參數其他參數2028%756.2124036%769.6536042%788.456表6-9系能測試結果從上表中可以看出，當用戶數達成60人時，事件響應的時間為8秒內，而少于10秒，cpu占用率39％，內存使用占到43％，所以系統性能達成規定。測試結果評價本系統的開發旨在提高顧客購買商品的效率，以及方便客戶和商家。提高人們的生活水平，也使商家能對超市有更好的管理。系統已經基本運營實現了設計的各項功能，可以投入使用。但由于開發者能力有限，致使系統還存在諸多局限性與缺陷，因此本系統還可以從以下幾個方面進行改善。（1）豐富和完善用戶功能；（2）添加在線交流模塊；（3）系統功能并非完全實現，在后期逐步完善；（4）界面上還不夠完美；此外，本系統仍存在安全性問題的隱患。第7章總結MVC思想的運用為郵政儲蓄銀行的客戶卡管理系統的開發提供了一種松散耦合的、互操作性強、并且具有良好可擴展性的架構思想。借助于這種系統架構設計思想，系統設計變得更加簡樸。本文通過對零售公司客戶制營銷現狀的分析，以提高客戶的滿意度、忠誠度為目的，通過建立客戶顧客的信息庫，以期更好地了解顧客的營銷積分需求，與之建立長期的和諧