一、短消息业务平台的网络结构
短消息中心系统从物理设备上主要包括移动网内短信中心(SMSC)、互联网短信网关(ISMG)、汇接网关(GNS)、业务提供商(SP)、数据业务管理平台(DSMP)及相关的外部配套设备。其网络结构如图1所示。
手机用户之间发送和接收短消息直接通过路径1;业务提供商和手机用户之间的短信通信则是通过路径2。互联网短信网关(ISMG)——业务提供商(SP)与移动网内短信中心(SMSC)之间的中介实体的转发来实现。互联网短信网关负责接收SP发送给移动用户的信息和提交给短信中心。同时,移动用户点播SP业务的信息将由短信中心通过互联网短信网关发给SP。另外,为了减轻短信中心的信令负荷,互联网短信网关还应根据路由原则将SP提交的信息转发到相应的互联网短信网关,再由它通过向汇接网关(GNS)查询的方式获得网关间的转发路由信息。
二、基于UML的短消息计费系统设计
UML是一种标准的软件建模语言,基于UML的面向对象需求分析克服了传统的需求分析对问题领域受时效上的限制和对系统功能无法把握其精确程度等缺点;同时解决了数据流分析的层次复杂性,对信息模型的映射程度加强了;而且UML作为面向对象的可视化标准建模语言,采用图形符号表示系统中的对象和关系,从不同的角度描述待开发系统,为更好地理解业务流程提供有效的交流形式。因此,目前许多公司已将UML及RUP(RationalUnifiedProcess)作为一个商业策略而纳入他们的开发过程和产品中,涵盖许多领域,比如商业建模、需求管理、分析和设计、编程和测试等。
1.功能需求
短消息计费结算平台的建设初期,主要根据各运营商制定的相关计费规则完成对短消息基本通信费的综合计费和结算功能,同时完成短消息话单的维护、管理、脱机备份等功能。随着短消息业务运营模型的推陈出新,关键需要完成短消息业务以及增值业务等多种业务模式的综合计费功能。原先对各业务的计费功能简单,实时性要求不高,无法适应不同话单格式和数据量庞大等要求。我们针对系统中目前存在的这些不足之处,提出了新的功能需求:
(1)多种计费原始数据格式统一;
(2)不同业务不同计费关键字在同一计费平台的整合;
(3)对预付费用户实时扣费的支持;
(4)对短消息业务的无缝扩展性的支撑。
2.用例图
系统运维人员、业务管理人员、一般短信用户和市场拓展人员等是系统中的执行者,执行者还包括系统边界之外的短信话单来源和GSM计费系统。采集、计费划价、账务用例作为系统功能实现的主要承担者是系统需求分析的结果,用来模拟系统的功能需求,它们之间的关系多为扩展关系。针对采集的多样性,采集用例被泛化成短信中心话单采集、互联网短信网关话单采集和短信话单文件采集三个子用例。用例和执行者之间的联系表示了执行者对用例的责任。如执行者一般短信用户可以进行查询短消息的使用情况,这是由用例查询所描述的功能。以下对图2中的主要用例简单描述。
(1)数据采集
当短信发送并接收成功后,由相关联的硬件设备就短信发送的“场景”信息,包括发送时间、来源与目的号码、短信内容等形成短信原始话单。短信话单一部分来自于短信中心,另外一部分来自互联网短信网关。可以是实时在线采集,或者以较小时间段为单位的文件网络传输方式的准实时采集,或者以较长时间段为单位的文件送交方式的离线脱机采集。由于短信设备提供商的不同,采集得到的短信话单的格式是多种多样的,因此需要按统一的短信计费规范格式进行数据整理与筛选。另外由于所有的短信最终都有短消息中心转发,而业务提供商话单有一部分可以由互联网短信网关提供,可能存在重复话单,在格式化阶段还需要进行查重处理。
(2)计费划价
计费平台是使来自网络基础设施的实时请求能够起到主动的双向控制作用的主要实施平台。根据客户是否具有足够的余额(预付费)或足够的信用额度(后付费),它被用于激活或者取消客户对数据服务、增值内容和商务交易的访问。计费划价模块以实时方式运行,按照相关费率以及短信具体发生状况,计算用户的短信费用,并形成详细账单。
文章来源于领测软件测试网 https://www.ltesting.net/