【正文】 X 軸 :測試進度（天） Y 軸 :Bug 參考值（個） 圖 52 系統(tǒng)測試 Bug 收斂圖 六、總結(jié) 本文通過對 鐵通 計費系統(tǒng)的設(shè)計與實現(xiàn)整個過程的分析與介紹，通過基于J2EE架構(gòu) EBOS二次開發(fā)平臺完成代碼實現(xiàn)。在測試的初期，發(fā)現(xiàn)的以低級別的 Bug 為主，主要是因為開發(fā)人員某些失誤造成的，很快就能完成 Bug 的改正；隨著測試的不斷深入，發(fā)現(xiàn)的 Bug 都隱藏較深，修改難度也相對復(fù)雜。 根據(jù)圖 52 所示，本系統(tǒng)的測試周期為 30 天，在測試過程中發(fā)現(xiàn)的 Bug 數(shù)量隨著測試進程逐步遞增，但是 Bug 出現(xiàn)的速度逐漸放緩，具有明顯的收斂趨向，在第 26 天以后，再也沒有新的 Bug 被發(fā)現(xiàn)。測試將由手工完成，并且保證系統(tǒng)中所有的基本功能點都被測試到，以保證其功能的正常。 在測試中設(shè)計了若干個單 元測試案例、集成測試案例和系統(tǒng)測試案例，用于最大限度的發(fā)現(xiàn)系統(tǒng)中隱藏的問題與缺陷。 測試計劃、測試用例完成后，測試方案完成后，有客戶與公司組織人員進行評審，評審?fù)ㄟ^后，測試計劃和測試用例納入項目進程管理。 35 （二）測試計劃 本系統(tǒng)測試計劃主要包括兩部分內(nèi)容，主要對測試計劃的安排和測試用例的編寫和評審。 黑盒測試法 系統(tǒng)的每個測試階段都用到了黑盒測試。根據(jù) ER 設(shè)計，最終生成的 PDM，利用數(shù)據(jù)庫設(shè)計工具提供的功能生成該模塊相應(yīng)的 PDM 和對應(yīng)的數(shù)據(jù)庫的建庫腳本，完成數(shù)據(jù)庫的物理設(shè)計。通過傳統(tǒng)的 ER 圖模型構(gòu)建 CDM 模型。數(shù)據(jù)庫對象命名規(guī)則如表 45 所示： 表 45 數(shù)據(jù)庫對象命名規(guī)則表 數(shù)據(jù)庫概念設(shè)計 南京鐵通計費系統(tǒng)的數(shù)據(jù)庫概念設(shè)計是基于需求分析的基礎(chǔ)之 上的，在進行概念設(shè)計時應(yīng)用實體關(guān)系圖進行，在實體關(guān)系圖中主要分為實體、屬性以及實體間的關(guān)系。通過使用Collaboration 靜態(tài)類，大大簡化了調(diào)用遠程 API 的難度。 Filter 的作用是將傳輸?shù)臄?shù)據(jù)以 xml 的形式存儲到數(shù)據(jù)庫中，通過配置文件的方式有利于系統(tǒng)服務(wù)的注入。 } 27 } } return tree。 !() ) { for (int j = 0, h = ()。 (accountId, serviceList)。 // get service by account id. String locale = ()。 (/convergys/awcc/account/26 g)。 ()。 if((())) { (createAccountNode(account))。 if(() == null) { throw new RuntimeException(No Accounts to be loaded!)。 String userName = ()。其中調(diào)用接口使用了系統(tǒng)提供 Collaboration 的數(shù)據(jù)交互方法，該方法需要在配置中定義然后通過映射的方式，前后臺可以進行調(diào)用。通過左側(cè)數(shù)據(jù)樹的連接更新右側(cè)數(shù)據(jù)信息，可以展現(xiàn)某一個賬戶的基本信息等。 23 圖 42 注冊和登錄的數(shù)據(jù)實體圖 業(yè)務(wù)邏輯設(shè)計 根據(jù)需求定義的用例需求，如圖 43 所示，總結(jié)出注冊和登錄模塊的業(yè)務(wù)邏輯類如下： 24 圖 43 注冊和登錄的邏輯類圖 通過類去實現(xiàn)該功能模塊所具有的接口方法，這里 WebHelper 類的方法都是靜態(tài)類，方便在頁面上調(diào)用， WebHelper 類是方法的入口點，所有的帶事務(wù)的方法都寫在 Manager 包里，這里方法都是實現(xiàn)類。在注冊過程中，可以得出手機號和 SMS 參數(shù)是一對一的關(guān)系，這些數(shù)據(jù)組成了發(fā)送驗證碼方法的參數(shù)，這個方法返回值如圖所示，這個返回值是判斷驗證碼的正確與否的依據(jù)。系統(tǒng)管理員可以自定義區(qū)域碼的長度及表示級別的位數(shù)。 根據(jù)實際情況要求，內(nèi)部組織機構(gòu)的劃分最多支持 0N 級。 根據(jù)圖 37 所示，本計費系統(tǒng)的權(quán)限管理圖，從上圖看出，總賬戶一般提供給企業(yè)或者家庭團體使用，客戶可以使用手機號申請，賬戶下的第一個手機用戶申請會成為第一用戶，第二個手機用戶申請將成為第二用戶，兩種用戶權(quán)限不同。根據(jù)項目需求，還可以創(chuàng)建新的用戶角色，根據(jù)業(yè)務(wù)需要進行角色劃分。 RBAC 授權(quán)模型參見圖 36： 20 圖 36 RBAC 授權(quán)模型圖 根據(jù) RBAC 模型的理論，本系統(tǒng)權(quán)限和資源的設(shè)計依據(jù)此理論對系統(tǒng)內(nèi)部根據(jù)賬號、權(quán)限和角色三種實體將用戶于權(quán)限進行管理。責(zé)任分離原則，通過互相調(diào)用互斥的角色進行權(quán)限和 資源的劃分。 系統(tǒng)采用基于 RBAC（ RoleBased Access Control 是 基于角色的訪問控制模型），作為傳統(tǒng)訪問控制的策略。這些驗證條件包含，用戶和權(quán)限類型等。 授權(quán)，通過了認證系統(tǒng)的用戶才能獲取認證信息，這時用戶采用使用系統(tǒng)資源。加密種類分為以下幾種： （ 1）用戶名、用戶密碼、 Session 信息和登陸時的關(guān)鍵信息需要通過系統(tǒng)進行加密處理，防止信息被程序盜用。可以根據(jù)實際業(yè)務(wù)的需要將 Session 信息保存在存儲堆棧中， 為后期認證服務(wù)提供數(shù)據(jù)。系統(tǒng)強制對每次用戶進行 Session 有效性的校驗，如果 Session 不符合要求或者授權(quán)時間已過期，訪問將被禁止，從而保護用戶整體數(shù)據(jù)的安全。在系統(tǒng)整體看來稽查和計費賬務(wù)有數(shù)據(jù)的關(guān)聯(lián)，系統(tǒng)主要的調(diào)度通過數(shù)據(jù)依賴關(guān)系和業(yè)務(wù)規(guī)則進行數(shù)據(jù)支撐，系統(tǒng)任務(wù)的掛起要遵循系統(tǒng)流程的控制。對于新增的業(yè)務(wù)單據(jù)、新增的系統(tǒng)統(tǒng)計數(shù)據(jù) 和業(yè)務(wù)相關(guān)數(shù)據(jù)。根據(jù)話單業(yè)務(wù)的流程進行控制，換單需要經(jīng)過的預(yù)處理包含，批價、話費的累計入庫、信用控制和優(yōu)惠信息等。 16 圖 35 支付模塊的功能結(jié)構(gòu)圖 （三）系統(tǒng)流程設(shè)計 根據(jù)調(diào)度算法的主要規(guī)則我們可以對系統(tǒng)的主流程進行總體的定義，調(diào)度算法規(guī)則主要是為系統(tǒng)提供相關(guān)任務(wù)的創(chuàng)建，這些系統(tǒng)任務(wù)主要包含了執(zhí)行和稽核流程。 圖 34 賬單模塊功能結(jié)構(gòu)圖 支付功能模塊 支付功能，根據(jù)需求分析的設(shè)計支付功能模塊需要具有電子錢包、單次支付、自動支付、交易記錄日志、支付記錄等功能。 15 圖 33 賬號管理模塊功能圖 賬單功能模塊 賬單功能主要是顯示對應(yīng)賬號管理模塊的層次樹上的后付費賬號而產(chǎn)生的賬單，賬單功能有兩種顯示方式。在賬號管理功能模塊中還有一個是賬號管理主頁面顯示功能。通過登錄控制將系統(tǒng)賦值對應(yīng)的角色，獲取該用戶具備的系統(tǒng)資源操作控制。該系統(tǒng)是本文工作的重點。該系統(tǒng)可以針對每個事件或訂閱為基礎(chǔ)來收費，也支持多種支付方式。服務(wù)之間的數(shù)據(jù)交互使用 Collaboration 組件完成。 開放性，系統(tǒng)的接口設(shè)計上必須按照規(guī)范化的設(shè)計要求，保證不同廠商提12 供的硬件和軟件可以實現(xiàn)數(shù)據(jù)共享；在系統(tǒng)后期擴展和硬件設(shè)備的采購方面不受某一個廠商提供的硬件、軟件和系統(tǒng)等相關(guān)產(chǎn)品的控制，可以靈活選擇。 對 于這樣的安全機制系統(tǒng)需要提供權(quán)限管理和級別高的安全機制，時刻記錄對系統(tǒng)中每次操作和非法操作，尤其是要將每次發(fā)生的非法操作通知到管理人員處。通過指標(biāo)可以描述一個衡量系統(tǒng)某種特點的標(biāo)準，本系統(tǒng)在做設(shè)計時針對非功能需求需滿足以下需求特點： 規(guī)范性，在系統(tǒng)的總體設(shè)計上，主要包括設(shè)計、開發(fā)和維護必須按照國家標(biāo)準和相關(guān)通信行業(yè)的標(biāo)準進行。 （二）非功能需求 根據(jù)軟件工程中對于非功能需求的描述，非功能性需求規(guī)定了本系統(tǒng)必須滿足的服務(wù)水平、系統(tǒng)非運行時間及系統(tǒng)必須遵守的約束。該歷史記錄頁面也具有打印功能，用戶可以在打開的支付記錄細節(jié)信息中打印該支付記錄。這是應(yīng)該注意針對兩種不同的賬號，自動付賬日期的設(shè)定是不同的，針對后付費賬號用戶應(yīng)該設(shè)定為賬單到賬日期的第幾天開始付賬，但針對預(yù)付費賬號應(yīng)該是設(shè)定為上次繳費日期的多少天后開始繳帳。銀行卡支付作為另一種支付方式。這種支付方式靈活性更強。除了單次支付功能外，系統(tǒng)還提供自動支付功能。查看賬單列表模塊主要是給用戶一個總體賬單的概要顯示，用戶可以選擇某月的賬單進行打印。賬單功能有兩種顯示方式： 為用戶展示某一月賬單的詳細內(nèi)容； 將 所有的賬單羅列起來。這個主頁的主要功能是顯示后付費賬戶的最新賬單和付款情況。樹結(jié)構(gòu)上有用戶所使用的預(yù)付費賬戶名，也有后付費賬戶名。手機號碼輸入有效時，系統(tǒng)需要繼續(xù)驗證該手機號碼對應(yīng)的賬戶下是否存在另外手機號碼，如果沒有，則顯示注冊協(xié)議，用戶同意后，填寫個人信息，發(fā)送驗證碼，用戶填寫收到的驗證碼無誤后完成注冊并提示用戶的注冊賬戶類型，例如是預(yù)付費賬戶還是后付費的賬戶。我們將通過其注冊和登錄兩個場景的用例進行需求分析。 賬單功能模塊，主要功能包括后付費賬單的單項查詢功能和列表查詢功能。對于人為因素造成影響需求的過程應(yīng)該盡量避免，通過數(shù)據(jù)庫數(shù)據(jù)的保存能力可以結(jié)合網(wǎng)絡(luò)提供的業(yè)務(wù)服務(wù)，對不同服務(wù)的收費標(biāo)準進行明確，并可以通過有效的手段進行費用的分析和統(tǒng)計。話單數(shù)據(jù)需要保證準確性和安全的設(shè)計原則。在話費服務(wù)中需要區(qū)分地區(qū)之間的號碼，如果是不同國家的號碼時，需要針對這些特殊的單據(jù)進行話費的統(tǒng)一處理和統(tǒng)計。本系統(tǒng)針對 鐵通 運營商的不同業(yè)務(wù)服務(wù)都有對應(yīng)的計費方式和相關(guān)規(guī)定并且都有相應(yīng)的計費標(biāo)準。計費 的整個業(yè)務(wù)流程是包含用戶通過使用提供的 鐵通 話費服務(wù)和相應(yīng)的服務(wù)產(chǎn)品時，從開始使用的起始點到最后服務(wù)結(jié)束的整個周期，通過計算這個周期完成話費的計算。計費系統(tǒng)中包含大量的數(shù)據(jù)，其實這些數(shù)據(jù)具有很大的數(shù)據(jù)挖掘?qū)嵱眯?。通過計費系統(tǒng)有效的控制結(jié)算費用及時收回不發(fā)生費用的流逝問題，這是計費系統(tǒng)重要的功能任務(wù)之一。目前計費系統(tǒng)主要的發(fā)展方向有以下幾點： 提高整體服務(wù)質(zhì)量、市場的競爭力，從目前 鐵通 行業(yè)的發(fā)展來看， 南京 鐵通提供的服務(wù)和相關(guān)產(chǎn)品，其中包括服務(wù)質(zhì)量問題都集中在計費系統(tǒng)的領(lǐng)域之中。原有的計費系統(tǒng)對于客戶的信息和相關(guān)業(yè)務(wù)分析報表功能的不足，信息不全不細致，導(dǎo)致了決策的模型并不是以客戶服務(wù)為中心的服務(wù)。但是由于不斷和持續(xù)的推出新的服務(wù)，原有系統(tǒng)很難對于新的服務(wù)進行數(shù)據(jù)支持。隨著近幾年 鐵通 行業(yè)各項業(yè)務(wù)不斷飛速發(fā)展，原有的計費系統(tǒng)已不能滿足快速發(fā)展的需要，同時也不能滿足客戶對于 鐵通 服務(wù)的需求， 鐵通 運營市場也變得競爭激烈。目前常用的系統(tǒng)都不能滿足企業(yè)很多簡單和實際的需求，隨之產(chǎn)生了很多不良的問題導(dǎo)致整體行業(yè)發(fā)展受到影響。在以往的 系統(tǒng)中，由于這方面考慮欠佳，系統(tǒng)一層的安全防范容易攻破，使得企業(yè)數(shù)據(jù)在安全性上沒有充分的保障，會給企業(yè)帶來潛在危機。如何使新老系統(tǒng)很好 的融合在一起，在方便維護的同時保證數(shù)據(jù)的準確性，也是擺在計費系統(tǒng)重新設(shè)計者面前的一項重2 要任務(wù)。 眾所周知， 鐵通 運營商業(yè)務(wù)支撐 系統(tǒng)中，最核心的就是集中計費系統(tǒng)，它是減少話費糾紛、提高服務(wù)質(zhì)量、提高管理經(jīng)營效率的關(guān)鍵性工具，也是為達到市場營銷目標(biāo)、實現(xiàn)先進性服務(wù)理念和開展創(chuàng)新型管理模式的重要載體。為了創(chuàng)收，不得不將傳統(tǒng)的業(yè)務(wù)模式進行改革。本文研究的重點主要為第二個階段，在系統(tǒng)主要設(shè)計方面實時性和準確性非常重要，會直接影響 鐵通 運營商對其客戶的服務(wù)質(zhì)量以及相關(guān)的收入情況。 此論文原 文出自《 基于 J2EE 的滄州電信計費系統(tǒng)的設(shè)計與實現(xiàn) 》 你可以參考原文修改，也可以參考其他資料。 EBOS 平臺采用 J2EE 體系結(jié)構(gòu)，通過不同的系統(tǒng)層次解決不同的業(yè)務(wù)問題。在系統(tǒng)和設(shè)備更新的同時，也將會對計費系統(tǒng)的穩(wěn)定性產(chǎn)生一定的影響。目前，我國已進入鐵通行業(yè)高速發(fā)展時期，大量先進技術(shù)的運用及 4G 牌照的發(fā)放，使得鐵通運營技術(shù)面臨越來越復(fù)雜的局面。 我們的設(shè)計采用 EBOS 平臺作為項目的開發(fā)平臺。 關(guān)鍵詞： 計費系統(tǒng) J2EE EBOS 修改建議： 論文中有些圖表不清楚，請重新畫； 數(shù)據(jù)庫設(shè)計請補充數(shù)據(jù)庫概念結(jié)構(gòu)設(shè)計、邏輯結(jié)構(gòu)設(shè)計和物理結(jié)構(gòu)設(shè)計； 請畫出各個功能模塊的程序流程圖。第二階段是后臺計費財務(wù)處理。為了提高企業(yè)核心競爭力，鐵通 運營商需要在不斷提高業(yè)務(wù)開展能力的同時，相應(yīng)提升行業(yè)服務(wù)水平。在這個改革過渡期間，新計費方式如何被用戶認可成為關(guān)鍵性因素，同時， 鐵通 運營商原有計費體系將面臨著嚴峻的挑戰(zhàn)。再次，隨著 鐵通 業(yè)務(wù)的不斷發(fā)展，相關(guān)業(yè)務(wù)數(shù)據(jù)逐漸龐大，滄州移動現(xiàn)在面臨的問題就是舊的系統(tǒng)仍然在使用，但又要投入運營新的系統(tǒng)?？蛻粜畔⒌认嚓P(guān)重要數(shù)據(jù)， 鐵通 運營商應(yīng)格外關(guān)注其保密性。對于企業(yè)本身來說帶來了業(yè)務(wù)流程處理分散，業(yè)務(wù)水平不高的問題。當(dāng)時的計費系統(tǒng)主要以滿足現(xiàn)有功能業(yè)務(wù)為前提，實現(xiàn)以自動化為主的記賬、計費和收費等基礎(chǔ)功能。目前國內(nèi)外計費系統(tǒng)比較重點的問題如下： 企業(yè)競爭力，目前很多企業(yè)還是通過多種優(yōu)惠的方式進行客戶的吸引，除了提供優(yōu)惠外，還會附加一些組合服務(wù)等。 管理決策準確性，對于市場的占有率來說，主要通過擴充客戶的業(yè)務(wù)量上。 鐵通 都意識到計費系統(tǒng)是其運行和提 高服務(wù)質(zhì)量，增加企業(yè)競爭實力的有效手段，通過不斷的客戶需求，這也使得計費系統(tǒng)需要進行全新的構(gòu)建和具體實現(xiàn)。 保證 鐵通 運營商自身利益和