基于UML的短信計費系統的分析與設計

短消息業務發展迅猛，形成了從手機用戶到服務內容提供商的一整套產業鏈，并逐漸成為各移動通信運營商新的經濟增長點。有數據表明，截至2003年12月31日，中國移動（香港）有限公司，包括廣東、浙江、江蘇、上海、北京等21家子公司，移動用戶數達到14161.6萬戶，短信普及率達到71.1%，短信業務使用量達到935.1億條；中國聯通股份有限公司，在30個省市自治區的GSM和CDMA移動電話用戶已達9151.5萬戶，其中CDMA用戶短信使用量達到62.3億條，GSM用戶短信使用量是250.3億條。隨著短消息及其增值業務的迅速發展，對短消息計費和結算功能的需求更加迫切。

　　本文在描述了短消息業務系統的網絡結構基礎上，總結計費系統的需求要點，進而采用UML語言對短消息計費系統進行分析。

　　一、短消息業務平臺的網絡結構

　　短消息中心系統從物理設備上主要包括移動網內短信中心(SMSC)、互聯網短信網關(ISMG)、匯接網關(GNS)、業務提供商(SP)、數據業務管理平臺(DSMP)及相關的外部配套設備。其網絡結構如圖1所示。

圖1短消息業務平臺的網絡結構

　　手機用戶之間發送和接收短消息直接通過路徑1；業務提供商和手機用戶之間的短信通信則是通過路徑2?；ヂ摼W短信網關(ISMG)——業務提供商(SP)與移動網內短信中心(SMSC)之間的中介實體的轉發來實現?；ヂ摼W短信網關負責接收SP發送給移動用戶的信息和提交給短信中心。同時，移動用戶點播SP業務的信息將由短信中心通過互聯網短信網關發給SP。另外，為了減輕短信中心的信令負荷，互聯網短信網關還應根據路由原則將SP提交的信息轉發到相應的互聯網短信網關，再由它通過向匯接網關（GNS）查詢的方式獲得網關間的轉發路由信息。

　　二、基于UML的短消息計費系統設計

　　UML是一種標準的軟件建模語言，基于UML的面向對象需求分析克服了傳統的需求分析對問題領域受時效上的限制和對系統功能無法把握其精確程度等缺點；同時解決了數據流分析的層次復雜性，對信息模型的映射程度加強了；而且UML作為面向對象的可視化標準建模語言，采用圖形符號表示系統中的對象和關系，從不同的角度描述待開發系統，為更好地理解業務流程提供有效的交流形式。因此，目前許多公司已將UML及RUP（RationalUnifiedProcess）作為一個商業策略而納入他們的開發過程和產品中，涵蓋許多領域，比如商業建模、需求管理、分析和設計、編程和測試等。

　　1.功能需求

　　短消息計費結算平臺的建設初期，主要根據各運營商制定的相關計費規則完成對短消息基本通信費的綜合計費和結算功能，同時完成短消息話單的維護、管理、脫機備份等功能。隨著短消息業務運營模型的推陳出新，關鍵需要完成短消息業務以及增值業務等多種業務模式的綜合計費功能。原先對各業務的計費功能簡單，實時性要求不高，無法適應不同話單格式和數據量龐大等要求。我們針對系統中目前存在的這些不足之處，提出了新的功能需求：

　　(1)多種計費原始數據格式統一；

　　(2)不同業務不同計費關鍵字在同一計費平臺的整合；

　　(3)對預付費用戶實時扣費的支持；

　　(4)對短消息業務的無縫擴展性的支撐。

　　2.用例圖

圖2計費系統用例圖

　　圖2中，系統運維人員、業務管理人員、一般短信用戶和市場拓展人員等是系統中的執行者，執行者還包括系統邊界之外的短信話單來源和GSM計費系統。采集、計費劃價、賬務用例作為系統功能實現的主要承擔者是系統需求分析的結果，用來模擬系統的功能需求，它們之間的關系多為擴展關系。針對采集的多樣性，采集用例被泛化成短信中心話單采集、互聯網短信網關話單采集和短信話單文件采集三個子用例。用例和執行者之間的聯系表示了執行者對用例的責任。如執行者一般短信用戶可以進行查詢短消息的使用情況，這是由用例查詢所描述的功能。以下對圖2中的主要用例簡單描述。

　　(1)數據采集

　　當短信發送并接收成功后，由相關聯的硬件設備就短信發送的“場景”信息，包括發送時間、來源與目的號碼、短信內容等形成短信原始話單。短信話單一部分來自于短信中心，另外一部分來自互聯網短信網關?？梢允菍崟r在線采集，或者以較小時間段為單位的文件網絡傳輸方式的準實時采集，或者以較長時間段為單位的文件送交方式的離線脫機采集。由于短信設備提供商的不同，采集得到的短信話單的格式是多種多樣的，因此需要按統一的短信計費規范格式進行數據整理與篩選。另外由于所有的短信最終都有短消息中心轉發，而業務提供商話單有一部分可以由互聯網短信網關提供，可能存在重復話單，在格式化階段還需要進行查重處理。

　　(2)計費劃價

　　計費平臺是使來自網絡基礎設施的實時請求能夠起到主動的雙向控制作用的主要實施平臺。根據客戶是否具有足夠的余額（預付費）或足夠的信用額度（后付費），它被用于激活或者取消客戶對數據服務、增值內容和商務交易的訪問。計費劃價模塊以實時方式運行，按照相關費率以及短信具體發生狀況，計算用戶的短信費用，并形成詳細賬單。

　　(3)賬務

　　該用例為所有的需要詳細賬單者提供送達服務。對計費劃價后產生的費用信息按照電子賬單的形式發送到GSM計費系統和省短信中心。采用電子賬單形式：一借以實現實時的預付費扣費，二避免生成交換文件的導入導出。

　　(4)管理配置

　　該用例負責網絡監控、智能巡檢、告警管理、系統自身管理、用戶權限和安全管理、日志管理和運行維護管理。

　　(5)計費策略

　　該用例負責自定義報表、數據管理、配置費率，如更加靈活地調整資費策略、實施多層次優惠方案，及時配合面向客戶的經營戰略調整，提高服務質量。

　　(6)業務拓展

　　該用例的功能包括為業務提供商提供分析資費套餐運營的依據，用戶定制的具體資費套餐，各類套餐費用發生情況的數據抽取、清洗，并形成格式化的輸出文件；依據用戶定制的套餐，并根據分析及分解后得到的若干賬務處理規則，按照預定的執行順序依次進行賬務處理。

3.業務流程描述

　　描述對象間的動態交互關系時，包括序列圖和協作圖。其中序列圖按時間順序描述一組對象以及由這些對象發送和接收的消息，強調消息發送的時間順序。圖3是短消息計費系統中計費劃價用例正常處理駐留程序的序列圖。

圖3計費劃價序列圖

　　當用戶成功發送短消息后，由話單生成設備產生原始待計費信息，并發送到短信計費系統的采集模塊，完成格式化處理后，形成原始短信話單記錄，存儲在話單對象中。當操作員啟動計費劃價處理，首先從原始話單對象中循環獲取待計費的原始短信話單，校驗客戶資料，檢查客戶對應賬戶的余額情況，然后根據短信的費用類型、客戶類型等基準條件查詢獲得基本費率，通過計算得到該條短信發生的費用，存儲到話單費用對象。最后逐級返回成功處理標識。經過計費劃價處理，可以得到用戶短信消費的詳細話單和對應每條短信的費用金額。計費劃價處理形成的詳單信息可以提供給賬務處理、查詢等模塊繼續處理，得到不同用途的分析處理報告。

　　4.類圖

　　類圖描述系統中類的靜態結構，在系統的整個生命周期中有效。類圖定義了系統的類，表示一組類、界面、合作以及它們之間的關系，如關聯、依賴、繼承等，也包括類的內部結構（類的屬性和操作）。

圖4主要實體類類圖

　　圖4是計費系統實現中主要實體類，話單類記載了待計費的原始短信話單的屬性以及對其格式化操作的方法。并且通過繼承關系實現對短信中心、互聯網短信網關、短信文件的話單導入。根據不同產品模型制定適應的費率，用來計算短信的發生費用，并存儲在話單的費用屬性話單費用中，最終結合對應客戶的賬戶信息形成明細賬單，并生成報表。

　　三、一個短消息計費系統實例的模塊結構

　　在上述分析的基礎上，我們實現了一個具體的短消息計費系統。我們將該系統分為采集、格式化、計費劃價、電子賬單等基本模塊，如圖5所示，其功能詳述可見前用例分析。

圖5短消息計費結算系統模塊關系圖

　　四、結論

　　短消息及其增值業務正在快速發展，它的商業潛力是巨大的。為了對這種潛力進行充分的投資，運營商必須認真評估結算、采集預處理和計費平臺，以提高競爭力和最大化收益。對短消息計費系統的研究，可以使得運營商通過向最大的可能用戶群提供創新業務來獲取最大化收入，因此，計費系統的開發設計還有待于進一步的研究。

原文轉自：http://www.anti-gravitydesign.com