电信运营计费数据采集与整合子系统的设.docx
《电信运营计费数据采集与整合子系统的设.docx》由会员分享，可在线阅读，更多相关《电信运营计费数据采集与整合子系统的设.docx（36页珍藏版）》请在冰豆网上搜索。
电信运营计费数据采集与整合子系统的设
学士学位论文
论文题目:
电信运营计费——数据采集与整合子系统的设
计与开发
院（部）名称:
学生姓名:
专业:
软件工程学号:
指导教师姓名:
论文提交时间:
2010年月日
论文答辩时间:
学位授予时间:
XXXX大学教务处制
电信运营计费——数据采集与整合子系统的设计与开发
摘要
随着计算机技术的迅猛发展，通过Internet实现资源共享，为科研人员提供自由交流平台，测试仪器、仪表的远程操作和控制显得尤为重要。
国外高校从不同程度上购买或开发了自己的数据实验室，国内部分软件公司和单位也就此进行开发、合作。
数据实验室可以提供计算机基本管理的功能，如实验数据库的建立、维护、查询、统计等功能，为加速企业的信息化管理提供了有力保障。
但此数据实验室的成本费用昂贵，一般公司或单位难以接受。
基于市场调查，电信运营商新增一项数据实验室的，即电信运营商提供基于Unix操作系统的实验环境，运营商通过计费系统对用户进行管理和收费。
在电信运营系统中，电信计费系统是主要的支撑系统，占有重要地位。
计费系统有效、安全地运行，在很大程度上影响着电信运营系统本身的运行效率和信誉。
本系统是一个计费的系统，要想对用户进行准确的收费，首先必须能够获得用户使用开放实验室的准确的使用记录，采集子系统正是为了获取这些记录而提供的。
然后通过整合子系统将采集的数据整理并持久化。
再通过前台运营管理系统对持久化的数据进行操作、管理。
主子系统主要负责采集模块和整合模块，基本实现了系统的主要功能。
关键词：
电信计费，采集，整合，系统设计
TelecomBilling—Dataacquisitionandintegrationofsubsystemsdesignanddevelopment
Abstract
Withtherapiddevelopmentofcomputertechnology,sharingofresourcesthroughtheInternet,toprovidethefreeexchangeofscientificresearchplatform,testinstruments,meters,remoteoperationandcontrolisparticularlyimportant.Tovaryingdegreesfromforeignuniversitiestopurchaseordeveloptheirownlaboratorydata,somedomesticsoftwarecompaniesandunitshavedevelopedthiscooperation.Laboratorydatamanagementcanprovidebasiccomputerfunctions,suchastheexperimentaldatabaseestablishment,maintenance,query,statisticsandotherfunctions,toacceleratethecompany'sinformationmanagementprovidesastrongguarantee.However,laboratorydata,thecostofthisexpensive,difficulttoacceptthegeneralcorporateorunit.Basedonmarketresearch,telecomoperatorsaddedadatalaboratory,whichprovidestelecomoperatorsUnixoperatingsystembasedontheexperimentalenvironment,operatorbillingsystemthroughtheusermanagementandbilling.
Inthetelecomsystem,telecommunicationbillingsystemisamajorsupportsystem,playsanimportantrole.Billingsystemiseffectiveandsafeoperationofcarriersinlargelyaffecttheefficiencyofthesystemitselfandcredibility.
Thissystemisabillingsystem,inordertochargetheuseranaccurate,usermustfirstopenaccesstotheuseofaccuratelaboratoryrecords,acquisitionsubsysteminordertoobtaintheserecordsisprovided.Integrationofsubsystemswillthencollatethedatacollected,andpersistence.Andthroughthefrontdeskoperationandmanagementsystemforpersistentdataoperationsmanagement.Mastersystemismainlyresponsibleforcollectionmoduleandintegratedmodules,thebasicgoalofthesystem'smainfunctions.
Keywords：
Billing,collection,integration,systemdesign
目录
前言1
1.数据采集与整合子系统概述2
1.1选题背景2
1.2选题意义2
1.3系统介绍2
1.4系统可行性分析3
2.数据采集与整合子系统需求分析4
2.1业务目标4
2.2用例分析5
3.数据采集与整合子系统总体设计8
3.1系统框架8
3.2系统功能模块设计9
3.3数据表结构设计9
4.数据采集与整合子系统详细设计及实现11
4.1数据采集类图设计11
4.2数据整合类图设计21
4.3开发准备23
4.4系统发布24
总结30
致谢31
参考文献32
前言
面对更加复杂的全业务运营模式，中国电信业运营支撑系统将面临机遇与挑战，作为电信运营支撑系统的重要组成部分，计费系统也将迎来新的发展机遇。
首先，在全业务模式下，对计费系统的实时性提出了新的要求。
在过去，已经实现准实时地对业务进行计费，提高了业务的处理速度，优化了客户体验。
但一些高风险的新业务，要求能立即扣费，却由于现网的各种系统都无法较好支持，影响了业务的开展。
在全业务时代，实时费用查询，计费通知，对客户来说十分必要。
计费信息可以实时影响业务的提供、帐户余额可以实时更新的计费机制，因此需要计费机制与会话/服务控制直接的交互，不仅是包括了在线的和离线的，而且跟客户关系管理紧密联系起来。
而有效预防风险，提升客户满意度，本身就是优化业务成效的一个表现，将大大增强运营商的竞争力。
其次，全业务运营要求计费系统进行预付费和后付费的融合。
目前由于预付费、后付费用户在不同平台，所以产品资料、用户资料分散存放，导致不能进行预付费、后付费互转，以及融合计费。
在全业务运营时代，所有的客户都希望在处理各种服务时不必区分移动或固定电话，后付费或预付费。
客户并不想在各种服务、促销、折扣之间费尽周折。
用户希望可以自由选择业务组合方式，比如神州行的用户要想转成全球通套餐，虽然两种品牌分别属于预付费和后付费业务，但用户不希望在业务切换时带来更换电话号码的麻烦。
全部用户和业务的预付费是发展的方向，但首先必须把后付费用户的计费功能纳入到（OnlineChargingSystem—在线计费系统）系统当中。
最后，全业务运营也对系统提供商提出了更高的要求。
受过去以业务为中心的思想影响，各个系统往往为了某种业务而单独建设一套系统，包括计费、帐务、营业等全部功能，当业务较多时，无疑会加大业务流程和系统维护、处理、数据分析的难度。
在全业务运营环境下，运营商可以提供包括语音、数据、游戏在内的所有业务，在这种新的变化形式下，需要各大运营商对自己的计费系统进行升级，做为运营支撑系统的提供者，各计费系统集成商必须具备全方位整套解决方案能力，如亚信、HP、中兴软创等纷纷推出的融合实时在线计费系统产品，其产品包括开发、测试、集成、服务在内的一揽子解决方案，并在标准化方面与运营商充分合作，这样的产品能更好地适应目前中国电信市场的发展。
基于上述背景，结合特定企业的特定要求，开发一套具有较高可移植性、可扩展性、可维护性和容错性的数据采集与整合系统，不仅成为摆在国内电信运营企业面前的重大课题，也是广大软件工作者为之努力的目标。
1.数据采集与整合子系统概述
1.1选题背景
电信运营商新增一项OpenLab（开放实验室）出租业务，即该电信运营商提供基于Unix平台的实验室环境，选择使用这种业务的用户能够远程登录到实验室中做基于这个实验室环境的一些工作和实验。
运营商希望借助先进的计算机技术对访问实验室的用户进行管理和计费，由此实现对此项业务运营的支持与管理，于是电信运营计费管理系统应运而生。
1.2选题意义
要想对用户进行准确的收费，首先必须能够获得用户使用开放实验室的准确的使用记录，采集子系统正是为了获取这些记录而提供的。
采集系统定时将用户使用服务器的数据存入到了数据库中，但这些数据都是流水帐的数据，是用户每次使用UNIX操作系统的用时。
如果用户量大，用户频繁地登入/出，将产生大量的数据，不便于将来生成用户的月账单和对开放实验室的使用情况进行月统计和年统计，因此，出现了整合系统。
1.3系统介绍
电信计费系统作为对出租实验室的计费管理，主要包含了以下子模块：
数据采集、数据整合、用户管理、资费管理、管理员管理、账单查询、账务查询、用户自服务和权限管理模块。
用户管理子系统就是对用户的帐务帐号和业务帐号进行管理。
资费管理子系统就是用来管理资费的。
具有资费管理权限的管理员登陆成功后，可以添加新的资费，查询所有的资费，可以修改现有的资费信息，还可以删除资费。
管理员管理系统就是超级管理员来管理普通管理员。
超级管理员登陆成功后，可以增加新的普通管理员，同时为他分配一些权限，可以修改普通管理员的信息，可以查询所有的管理员信息，可以删除某些管理员。
具有帐单查询权限的管理员可以利用此子系统对所有用户的月账单进行查询。
此子系统不仅提供对某个帐务帐号上产生的总的费用进行查询，还提供对某个帐务帐号上的每个业务帐号上产生的费用明细进行查询。
具有帐务查询的管理员可以使用此子系统对开放实验室的使用情况进行查询。
此子系统可以提供以月为周期的查询，也可以提供以年为周期的查询。
用户自服务系统可以方便地供用户查询自己的账单和修改自己的个人信息。
这个子系统是唯一的一个用户可以使用的子系统。
而采集系统通过调用Unix系统函数来读取这个日志文件中的内容，然后对读取到的内容进行整理，整理为方便计费的数据，其中包括登录名、登录时间或登出时间等作为计费依据的数据。
最后把这些数据存入数据库中，以备其他系统使用。
整合是将某个用户在某一时段内所用机时求和后形成一条记录。
1.4系统可行性分析
由于系统运行过程中可能出现不可预知的状况,可能出现数据丢失的情况,从五个方面考虑数据的准确性问题:
1）综合考虑,先把日志文件在处理前进行备份。
今后的任何失败,都可有原始数据参考。
2）客户端数据读取,解析:
解析没有匹配的数据一定要保存,在下次采集匹配的时候再次读取出来匹配。
从理论上讲,登出数据肯定能找到匹配的登入数据.反之则不一定。
解析过程一般不会出现数据异常的情况。
3）客户端数据发送:
数据发送的时候,可能出现网络故障,数据可能发送不出去。
网络正常也有可能服务器端接收数据或保存数据错误。
上面两种或其他异常发生的时候,数据一定要保存到文件中,在下次采集的时候,先发送历史失败数据,在发送新采集的数据。
4）服务器端数据接受,存储:
在TCP协议下,在服务器端数据可能在保存数据库的时候出现错误,比如网络问题.当服务器出现保存错误的时候,向客户发送错误标记,让数据保存在客户。
5）数据整合:
数据整合的时候,可能发送数据库网络连接失败,延时等问题或其他异常问题,则需要记录该整合相关数据,便于客户通过PL/SQL编程或其他程序进行定点补充整合。
2.数据采集与整合子系统需求分析
2.1业务目标
本系统是一个计费的系统，要想对用户进行准确的收费，首先必须能够获得用户使用开放实验室的准确的使用记录，采集子系统正是为了获取这些记录而提供的。
获取用户使用实验室的准确记录有三种情况：
1）利用操作系统的自身功能：
开放实验室是一个Unix服务器，Unix服务器本身就具有记录系统日志的功能。
用户每次登录和退出Unix服务器的信息都会被自动保存到一个在线日志文件/var/adm/wtmpx中。
采集系统通过调用Unix系统函数来读取这个日志文件中的内容，然后对读取到的内容进行整理，整理为方便计费的数据，其中包括登录名、登录时间或登出时间等作为计费依据的数据。
最后把这些数据存入数据库中，以备其他系统使用。
为了使读取的数据量不至于过大，采集系统会每小时定时执行一次，每次只采集上一个小时时间段之内的数据。
2）利用开放实验室的个人web主页功能（personalwebhosting）:
只要用户在其主目录（home）下创建了public_html目录，采集系统通过扫描目录public_html就可以产生计费依据。
访问开放实验室的web信息:
用户每次访问web服务器，web服务器都会在access.log中记录下相应的信息，如客户端的ip和被访问的URL等。
通过分析web服务器的访问日志产生计费依据。
3）使用开放实验室的e-mail功能:
根据邮箱的个数产生计费依据。
4）说明：
2，3的情况目前不做处理，提供扩展接口便于今后扩展。
采集系统定时将用户使用服务器的数据存入到了数据库中，但这些数据都是流水帐的数据，是用户每次使用UNIX操作系统的用时。
如果用户量大，用户频繁地登入/出，将产生大量的数据，不便于将来生成用户的月账单和对开放实验室的使用情况进行月统计和年统计，因此，出现了整合系统。
整合是将某个用户或某个实验室在某一时段内所用机时求和后形成一条记录。
整合系统具体整合规则如下：
1）每小时定时整合一次，生成以小时为单位统计的数据，程序总是每小时定时整合前一小时的数据。
2）每天定时整合一次，生成以天为单位统计的数据，程序总是每天定时整合前一天的数据.
3）每个月定时整合一次，生成以月为单位统计的数据，程序总是每个月定时整合前一个月的数据。
整合按用户与实验室整合,便于帐单查询与帐务查询,以及用户自服务帐单查询.
2.2用例分析
2.2.1系统用例图
图2-1数据采集与整合用例图
如图2-1所示，数据采集与整合子系统包括数据采集客户，数据采集服务器，数据整合三个用例。
2.2.2系统用例描述
描述要素
描述内容
备注事项
用例名称
数据采集客户
用例编号
用例简述
读取日志文件，并清空日志。
从读取的数据中解析用户登录时间等信息。
把解析的用户登录时间数据发送到服务器。
如果发送失败，就存储在实验室上等下次发送。
参与者
系统管理人员
前置条件
需要root权限
后置条件
日志文件被备份后清空
异常事件流
备份读取数据源异常:
结束本次采集,并等待下次采集.
解析数据源异常,中断整个采集过程.
上次登入数据读取异常,忽略异常,并继续采集
数据发送失败异常,保存文件到本地,并等待下次采集
特殊需求
表2-1数据采集客户端用例描述
表2-2数据采集服务端用例描述
描述要素
描述内容
备注事项
用例名称
数据采集服务器
用例编号
用例简述
接受各客户采集程序发送的数据。
接受失败，请求客户端重新发送。
根据时间存储到相应的数据表。
参与者
系统管理员
前置条件
后置条件
异常事件流
连接数据库异常:
发送标记到客户端,让客户端按服务器异常处理.
服务器接受客户端异常:
认定为异常或客户采集结束,直接终止服务器对相关客户的处理,并释放资源.
特殊需求
表2-3数据整合用例描述
描述要素
描述内容
备注事项
用例名称
数据整合
用例编号
用例简述
每小时按用户业务整合一次用户登录时间数据。
每天按用户业务整合一次用户登录时间数据。
每月按用户业务整合一次用户登录时间数据。
每小时按实验室服务器整合一次用户使用的时间数据。
每天按实验室服务器整合一次用户使用的时间数据。
每月按实验室服务器整合一次用户使用的时间数据。
参与者
系统管理员
前置条件
后置条件
产生整合数据。
异常事件流
采集出现网络异常:
记录异常时间,便于用户定点整合.
特殊需求
3.数据采集与整合子系统总体设计
3.1系统框架
本系统，采用简单的J2SE+MySQL开发。
设计的时候采用基于网络的多层C/S的设计模式。
实验室上写一个程序,负责读取日志,解析日志,并写一个网络客户程序,把解析好的数据通过网络发送到某个服务器。
不是直接存入数据库。
[采集客户端]
在远程写一个服务器程序,接收个实验室服务器上采集并解析处理好的数据,然后再放入数据库，再通过数据整合程序将数据分组存放。
[采集服务器端]
图3-1采集系统结构框架
3.2系统功能模块设计
图3-2系统功能模块图
如图3-2所示，数据采集与整合系统为电信运营系统的子系统，其主要功能模块包括采集客户端，采集服务器端，以及整合端。
3.3数据表结构设计
在采集数据的存储方式,根据客户需求与系统性能的考虑,设计的时候把数据存储表结构分为三类:
1）采集的原始登录数据记录表。
2）按不同用户在不同实验室上的数据整合表。
3）按不同实验室的数据整合表。
注意：
按实验室整合与按用户在不同实验室上整合的存储因为数据量的问题在设计上有区别。
其中前者的表按天，月，年各一张，后者的天表31张，月表12张，年表根据年份一年一张。
表3-1原始采集用户登录时长明细表（details_x）其中x是1-31
字段英文名
字段汉字名
类型
约束条件
说明
loginname
登录名
Varchar（20）
loginip
登录IP
Varchar（24）
logintime
登录时间
Timestamp
logouttime
登出时间
Timestamp
labip
实验室IP
Varchar（24）
duration
登录时长
long
如表3-1所示，该表存储原始采集用户的登录名，登录IP，登录时间，登出时间，实验室IP，登录时长。
该表特点：
1）该类表一张。
该表设计成一个，主要是原始数据很少被查询。
2）数据量很大。
3）可能为用户查询使用业务的明细的时候查询。
登录/登出构成一条记录,不存储时长。
可能几个小时一条记录，也可能一小时内若干条记录
表3-2按用户统计整合的时记录表detaildays_x其中x是1-31
字段英文名
字段汉字名
类型
约束条件
说明
loginname
登录名
Varchar（20）
loginip
登录IP
Varchar（24）
logouttime
登出时间
Timestamp
labip
实验室IP
Varchar（24）
duration
登录时长
long
如表3-2所示，该表是按用户统计整合的时记录表
表3-3按用户统计整合的天记录表detailmonths_x是1-12
字段英文名
字段汉字名
类型
约束条件
说明
loginname
登录名
Varchar（20）
loginip
登录IP
Varchar（24）
logouttime
整合时间
Timestamp
labip
实验室IP
Varchar（24）
duration
登录时长
long
如表3-3所示，该表是按用户统计整合的天记录表
表3-4按用户统计整合的月记录表detailyears_xx不定x表示年
字段英文名
字段汉字名
类型
约束条件
说明
loginname
登录名
Varchar（20）
Loginip
登录IP
Varchar（24）
logouttime
整合时间
Timestamp
Labip
实验室IP
Varchar（24）
Duration
登录时长
long
如表3-4所示，该表是按用户统计整合的月记录表
该类表主要存储整合后的数据。
其中存储时长，按时间间隔分三种：
1）一小时内的数据整合成一条记录。
单独存放在一张表中-天表。
2）一天内的数据整合成一条记录。
单独存放在一张表中-月表。
3）一个月内的数据整合成一条记录。
单独存放在一张表中-年表。
注意：
这三张表结构完全一样，除时间范围具体的值不同。
因为该表查询的频繁度很高，在设计的时候设计成天表31张，月表12张，年表根据年份一年一张。
表3-5按服务器整合的时记录表detaildays
字段英文名
字段汉字名
类型
约束条件
说明
logouttime
整合时间
Timestamp
Labip
实验室IP
Varchar（24）
Duration
登录时长
long
如表3-5所示，该表是按服务器整合的时记录表
表3-6按服务器整合的天记录表degtailmonths
字段英文名
字段汉字名
类型
约束条件
说明
logouttime
整合时间
Timestamp
Labip
实验室IP
Varchar（24）
Duration
登录时长
Long
如表3-6所示，该表是按服务器整合的天记录表
表3-7按服务器整合的月记录表detailyears
字段英文名
字段汉字名
类型
约束条件
说明
logouttime
整合时间
Timestamp
Labip
实验室IP
Varchar（24）
Duration
登录时长
long
升级会员 