电信计费数据优化系统的设计与实现.doc

电信计费数据优化系统
的设计与实现

专 业：
指导教师：

2014年 9 月

电信计费数据优化系统
摘要
当今的世界时一日千里，在古代人们通信时用书信的方式来进行，加入一个住在北京一个住在南京，那么他们的书信可能快马都需要一两个之久。数据多媒体业务以及Internet业务的出现,移动通信计费系统势必朝着灵活化、复杂化、全面化方向发展。随着时代的发展，现代移动通信的出现改变了这种局面，使我们的通信变得不再那么复杂，变得简单，方便。数据多媒体业务以及Internet业务的出现,移动通信计费系统势必朝着灵活化、复杂化、全面化方向发展。然而传统意义上的计费系统不能跟上通信业务的发展变化,不能满足用户的服务需求,更不能适应市场经济下竞争的环境。我们这里设计的是电信内部管理人员的计费管理平台。本文针对计费系统必须满足的稳定性，实用性，开放性，可扩展性，安全性进行分析。在对传统移动内部人员，电信营业员计费系统的整合和优化。

关键词: JSP, 电信计费, 用户管理

Telecom Billing Data Optimization System
Abstract
Advances in today's world, in the ancient way people communicate by letter to join a live one in Beijing lived in Nanjing, then their horse correspondence may require one or two years. Emergence of multimedia services and Internet data services, mobile communications billing system is bound towards flexible, complex, comprehensive direction. With the development of the times, the emergence of modern mobile communication has changed this situation, so that our communications become less complicated, simple and convenient. Emergence of multimedia services and Internet data services, mobile communications billing system is bound towards flexible, complex, comprehensive direction. However, the billing system in the traditional sense can not keep pace with changes in communications services, can not meet the service needs of the user, but can not adapt to the market economy competitive environment. We are here to design the internal management of the telecommunications billing management platform. In this paper, the billing system must meet the stability, usability, openness, scalability, security analysis. In the traditional mobile insiders, salesperson telecommunications billing system integration and optimization.

Keywords: JSP, telecom billing, User Management

目 录
1 绪论 1
1.1 选题背景 1
1.2 研究意义 2
1.3 国内外研究现状 2
1.3.1 国外研究现状 2
1.3.2 国内研究现状 3
1.4 本文主要研究内容 4
1.5 重点难点及研究方法 5
1.6 小结 5
2 系统功能分析与概要设计 6
2.1 系统功能分析 6
2.1.1 登陆/退出 7
2.1.2 系统管理 8
2.1.3 业务受理 10
2.2 系统概要设计 11
2.3 系统运行环境 12
2.4 小结 13
3 系统详细设计与相关技术 14
3.1 数据库设计 14
3.2 系统开发相关技术 16
3.2.1 MVC与模板概念的理解 16
3.2.2 MVC的优缺点 17
3.2.3 JSP简介 18
3.2.4 JSP的优缺点 18
3.2.5 B/S结构简介与优缺点 19
3.3 小结 20

第 Ⅰ 页 共 Ⅱ 页

4 系统实现 21
4.1 登录界面 21
4.2 主界面 22
4.3 操作管理模块 22
4.4 业务管理模块 24
4.4.1 添加业务 24
4.4.2 修改业务 24
4.4.3 删除业务 25
4.4.4 查询业务 25
4.5 小结 26
5 系统测试 27
6 结束语 28
参考文献 29
致谢 29

第 Ⅱ 页 共 Ⅱ 页

1 绪论
1.1选题背景
随着电信行业业务量的膨胀，电信计费数据量也呈迅猛增长之势；并且随着业务的不断深入，电信行业对电信业务数据的安全性及高效性等提出了比以往更加严格的要求。如何安全、可靠、完整地保存宝贵的数据资料已成为电信行业以及其它关键行业（如能源、地质、气象、金融、保险、政府等）的当务之急。使用自动化的存储管理手段，不仅可以解决现有电信计费数据的存储和备份问题，而且可以同时为网络上各种工作站提供数据备份的解决方案，减轻系统管理员的负担，有效地保护宝贵的数据及人力资源，不幸遇到灾难后，可以很迅速地恢复数据，使整个系统在最短的时间内重新投入正常运行[1]。
移动通信的计费系统是随着电信产业和计算机产业的发展而不断成长起来的,特别是随着交换机技术和计算机技术的不断进步而不断完善的。传统的计费系统,由于计算机硬件性能的限制,软件开发成本和难度较高,此外,电信运营者服务意识和竞争意识的淡漠,只能以自动化为目标,以算费、计账和收费的简单功能实现。这样的简单功能,不能跟上电信业务的发展变化,不能满足用户的服务需求,更不能适应市场经济下竞争的环境。随着智能、增值业务、数据多媒体业务以及Internet业务的出现,计费系统势必朝着灵活化、复杂化、全面化方向发展。与此同时,由于市场竞争的形成,用户服务需求的扩大,电信运营商也迫切需要这样的计费系统。 本文针对计费系统必须满足的稳定性， 实用性，开放性，可扩展性，安全性进行分析,着眼于计费系统整体功能的描述、系统外部关系、系统数据传输、预处理、计费核心模块、数据分发、数据装载、号码资源的上传、计费汇总以及整个系统的性能要求进行了研究。通过对各项业务整个计费环节中特点和要求的分析,概括抽象出整个计费系统各模块的功能、模块之间的接口关系、功能模块之间的数据传输处理等,以此来组成实现计费系统[2]。
电信计费数据的存储管理系统是电信部门业务运作的基石。尽早建立数据存储管理系统是电信行业健康、快速发展的保障。所以，电信行业数据存储管理系统的建立是十分必要的。
1.2研究意义
本课题主要研究的意义在于通信行业内部人员对客户的账户进行管理：根据账号判断是否为新账户，是否为老账户，验证账户的有效期限，并且校验账户有效性，此过程运用了事务的机制，如果过程中有非法之处，则事务回滚，保证不发生占用手机号码资源而不交开户费的情况；使通行行业内部人员能够便捷的管理用户的资料，费用情况，及所办理的业务种类。
1.3国内外研究现状
1.3.1国外研究现状
在国外，移动通信计费系统经过多年的发展，已进入成熟期。与此同时，移动通信近些年呈现出技术不断更新、业务层出不穷、市场飞速膨胀的空前活跃的态势，形成了多种技术并存，业务多层次、多样化以及不同业务市场相互促进和竞争的格局。移动通信市场飞速膨胀的动力来自新业务和增值业务两方面，其中话音业务中的预付卡业务是目前市场增长的最重要动力，数据业务特别是移动互联网业务也有力地推动着目前的增长，并且将在推动未来移动通信的发展中起着越来越重要的作用。第四代移动通信的基本概念还处于研究阶段，目前还难以用准确地语言加以描述。概括起来，未来的第四代移动通信应当具备以下基本特征： 业务：无论何时何地，能够为终端用户提供“身临其境”的高分辨率业务[3]。
网络：能够使用无所不在的“空间分集”技术提供广域服务，对抗更高频段上的电波传输特性。 终端：在体积受限的情况下，能够使用革命性的多天线技术，为用户提供高质量的无线通信服务。
基于以上考虑，我们认为4G蜂窝通信系统研究应具有以下基本特征： 基于IPv6核心网的互连互通；地面网络承载与控制全程分离，符合全IP发展趋势；支持个人可携带资源（MIP/M-eN）的全程漫游与切换；无线网络对于核心网络透明，CC/MM位于核心网侧（无线接入用户与固定接入用户等同），RR/LL/PL全部位于接入层； 分类端到端QoS，实时业务的QoS优于现有电信级；全新的基于时空联合处理、网络分集等新技术的蜂窝系统，发射能量较3G系统降低10dB以上；频率利用率较3G系统提高5至20倍，达到3-10Bits/Hz/s；特别适合于分组突发业务的空中接口，峰值传输速率达到20-100Mbps，可灵活调配无线资源，适用于大动态范围（10kbps-100Mbps）业务；与区域性的无线接入系统和自组织网络的无缝联接等。
未来移动通信的峰值速率将达到100Mbps以上，但实际用户所需要的传输速率可能会在10kbps至100Mbps之间动态地变化。为满足这一需求，未来移动通信的无线资源管理调配方式必须极为灵活，能够高效地适应这一变化。
对于4G核心网络，IP地址的个人化是未来移动通信的主要发展趋势之一，具有电信级QoS的IPv6将是未来的主要发展趋势，其主要原因之一是现有的IPv4不能提供足够的地址空间。
1.3.2国内研究现状
在今天移动通信业务向全业务发展的过程中，计费系统面临的主要挑战是使快速生成新业务的边际成本最低，甚至为零。这是来自像Google、iPhone等业务模式的挑战，特别是随着3G业务的开展，人们越来越认识到像短信这样的杀手级应用不太容易出现了，代之的是如雨后春笋般快速生成的多种数据业务。　　
一般情况下，这些业务的生命周期较短，客户群也非常分散，按目前计费系统开发套餐的速度和成本，是无法满足未来用户对在手机上实现的各种功能的市场需要。从效益和效率方面也无法使客户及运营商满意，其重要原因就是我们今天的支撑系统不能为新业务模式提供灵活支撑所致[4]。
在以语音业务为主的市场策略执行过程中，计费系统套餐的制定者、执行者以及客户都是相对稳定持久的，比如中国移动的全球通、动感地带和神州行三大品牌实际是三类不同的套餐组合，至今仍是中国移动各种业务核心品牌。　　
稳定之余，实际上也使计费系统的设计和开发人员产生一种系统开发的思维定势，每次套餐变化思路和做法基本一致。尤其针对少数的多种业务套餐组合需求，其产品生命周期相对较长，运营商一般不计较产品开发成本，这也促使移动运营商长期依赖同一开发商。这种发展方式实际上锁定了甲乙两个方面成长，运营商新业务生成的难度越来越大；因为系统的紧耦合，开发商也把大量开发人员聚集在省级计费中心周围承担了大量的本地化开发工作，严重影响了开发商系统产品化，模块化和低成本复制系统的进程，造成了“双输”局面。
随着全业务的竞争展开可以看出，对支撑系统的需求已经从原来的市场部，扩大到数据业务部、宽带业务部，移动互联网的业务发展模式已经近在眼前。我们可把当前计费系统中紧耦合的如计费、账务、营业、结算、报表等核心功能进行松耦合，并封装成不同层面的服务，最终形成一个移动互联网的开发大平台，充分使能现有无线和固定网络资源当是计费系统发展的方向。　　
我认为展开在计费系统松耦合过程中面临问题的讨论，特别是针对全业务运营的业务场景，设计不同层面的服务组合将非常有意义。如是，可使移动新业务生成的开发成本大幅度下降，并最大限度地满足用户的需求。这是电信业务转型的标志之一，电信运营商将从管道提供商转型为服务平台提供商，服务平台将拥有最权威的信用保障机制、最完善的安全保障和最可靠的运营维护。我们为什么要追求实时计费这样一个当前需求并非很大的技术而忽视了对移动互联网发展中重大问题的讨论。
针对目前的计费系统，我认为应该考虑最大限度的保留其原有功能，特别是对于账务管理的计费系统，一方面原因是中国移动的省级公司，大部分都承担着千万级甚至数千万级用户的计费工作，其可靠性，稳定性要求非常高，在进行系统松耦合的过程中，要最大限度的保留原有成熟稳定的模块，至少应该从粗粒度封装开始，这是对企业原有投资的保护。
松耦合首先应该注意企业网元能力的服务封装，使之与计费的基本能力封装匹配，并按业务组合的基本规则，为新的用户群体提供一个开放的业务开发平台
按移动计费方式开发的计费系统可以和老系统并行，特别是松耦合的架构下，成为一组新的计费服务组合，开发者可以根据其新业务的特点选择采用更合理或有效的计费方式。
在中国移动实施“服务与业务领先”战略的环境下，系统将朝着世界一流的业务支撑系统的目标迈进。系统将通过不断的演进，以实时性、准确性为核心，逐步提高系统标准化程度，最大限度地满足系统灵活性和可扩展性的要求，保障系统安全稳定的运行，从而为业务发展提供更有力的支撑[5]。
1.4本文主要研究内容
本系统是一套基于Internet的移动通信公司计费系统。通过该系统，电信行内部人员可以方便的对各种卡的信息进行编辑设定，并有权限对操作员进行增加删除等操作，也具有对顾客开户的权限。一般的操作员只具有对顾客进行办理新业务的权限，系统根据登录号自动识别登录人员权限并显示相应菜单。
系统认可两类用户：管理员和一般操作员，其中管理员拥有最高权限，管理员用户通过账号和密码登录之后，可以增、删、改、查系统里面的资源和业务费用以及普通操作员信息；普通操作员通过账号和密码登录之后可以对顾客办理开户业务。
1.5重点难点及研究方法
本课题研究的重点在于全面认识我国移动通信业务发展现状的基础上，正确分析国内外计费系统开发情况,从而根据我国国情和客户需求情况为移动用户开发一个计费模块—开户业务。研究的难点在于通过比较分析国内外移动计费系统技术的发展，如何找到适合中国移动业务发展所需要的计费系统，以达到中国广大用户的需求。本课题主要是对客户的账户进行管理：根据账号判断是否为新账户；如果是老账户，将新手机号的账户指定到一个已存在的账户进行合账，并且校验账户有效性，此过程运用了事务的机制，如果过程中有非法之处，则事务回滚，保证不发生占用手机号码资源而不交开户费的情况；如果此账户在系统中无记录，则新建账户，并且录入开户银行帐号和账户名，之后再完成客户开户后的扣费工作。
1.6小结
在第一章的内容中，简单的介绍了电信行业计费系统的一些相关情况，具体的分析了目前移动计费系统的发展前景，结合国内外发展情况，以及目前中国市场的需求做了进一步的分析和调研，为后面的开发奠定了基础[6]。

2 系统功能分析与概要设计
2.1系统功能分析
系统开发的总体任务是要实现移动公司对新用户的开通，实施的一套完整
的系统。
系统功能分析是在系统开发的总体任务的基础之上完成的。本系统主要有以下几项功能:
1.操作员(Operator):本系统的使用者，分为管理员(Administrator)和一般操 作员(Operator),管理员具有一般操作人员的权利，并可以对操作人员进行增、删、改、查的操作。
2.资源管理: 由界面输入号段或指定一个含有号码信息的文本文件生成资源表，资源表需要记录手机号码、手机卡类型（UIM 或者 SIM）、手机卡号和号码状态等。此部分功能只有管理员有权限。
3.业务管理:对用户开通手机号码时的各项收费项目，并可以对收费数值进行查询、修改。此部分功能对所有操作员都有权限。
4.开户: 开户功能包括以下内容：
录入客户信息
◆ 根据证件类型和号码判断是否为新客户；
◆ 如果为已存在客户显示客户资料；
◆ 如果是新客户输入其它客户信息。
录入用户信息
◆ 输入号码及卡号，校验输入的资源状态是否为可用；
◆ 录入通话级别和漫游状态。
◆ 显示需要收取的业务费用（列出“业务费用配置”中所配置的费用，计算费用总和）；
◆ 提交录入的数据建立三户资料及相关关系，修改资源状态，记录业务费用。此部分功能对所有操作员都有权限。
仔细分析调查有关企业人事信息需求的基础上,将得到如图2.1的数据流程。

登录/退出

系统管理

业务受理
操作员

图2.1 数据流
2.1.1 登陆/退出
登录的业务逻辑如表2.1所示：
表2.1 登陆业务逻辑
用例名称
登陆
功能简述
操作员进行任何的操作，都必须首先登陆到这个系统。此用例用于处理操作员的登录
后置条件
是否登陆成功、操作员的角色
前置条件
无
基本流
1、 操作员在图形界面中输入操作员代码和密码，并提交；
2、 判断操作员输入的操作员代码和密码是否匹配，并且确定操作员的角色（管理员还是一般操作员）。
退出的业务逻辑如表2.2所示：

表2.2 退出业务逻辑
用例名称
退出
功能简述
当操作员完成所有的操作后，应该退出。此功能提供给操作员退出此系统
后置条件
退出是否成功的信息
前置条件
登录成功
基本流
1、 用户退出本系统
2、 返回到登录界面
2.1.2 系统管理
本用例包括操作员管理、资源管理两个子用例。这两个子用例之间是相互独立的，没有必然的联系[7]。
操作员管理的业务逻辑如表2.3所示：
表2.3 操作员管理业务逻辑
用例名称
操作员管理
功能简述
管理员输入新增的操作员的代码、姓名、密码、角色（一般操作员还是管理员）
后置条件
新增操作员是否成功的信息
前置条件
登录成功，并且具有管理员身份。
基本流
1、 管理员输入新增的操作员的代码、姓名、密码、角色；
2、 提交保存到数据库中；
3、 返回操作的结果。
备注
只有系统管理员角色（Administrator）有权限完成此功能。
资源管理的业务逻辑如表2.4所示：

表2.4 资源管理业务逻辑
用例名称
资源管理
功能简述
此功能主要是对手机号码这个资源进行管理。
后置条件
业务受理能够进行的前提
前置条件
登录成功，并且句有管理员身份。
基本流
分成两种情况：
1) 直接在界面上输入号段；
2) 指定号段的类型、状态
3) 根据指定的号段，产生相应数量的号码资源，并且保存资源或者从一个包含有号码信息的文本文件中读取信息
分析这个文件并且从中读取号码资源

费用细项管理的业务逻辑如表2.5所示：
表2.5 费用细项管理业务逻辑
用例名称
费用细项管理
功能简述
此功能主要是对各项收费内容所收取的费用进行管理。
后置条件
业务受理能够进行的前提
前置条件
登录成功，并且具有管理员身份。
基本流
1) 列出各个收费项目；
2) 在对应的收费项目中输入需要收取的费用；
3) 保存各个项目的费用。
备注
只有管理员有此权限
配置业务费用业务逻辑如表2.6所示：

表2.6 业务费用管理业务逻辑
用例名称
业务费用管理
功能简述
对各个业务所需要收取的费用进行管理（但并不在此对具体的费用进行管理，而是从费用细项列表中选择，根据选择的要收取的收费项来计算）
后置条件
业务受理能够进行的前提
前置条件
登录成功，并且具有管理员身份
基本流
1) 列出所有需要收费的业务（目前只有开户这一项业务）和各项收费项目，如果此业务费用曾经经过配置，需要显示当前已经选定收费的项目；
2) 选择要进行配置的业务；
3) 配置此业务需要收取的费用；
4) 保存业务费用。
2.1.3 业务受理
本用例包括录入客户信息、录入用户信息、录入账户信息等子用例。只有三户信息齐全，此业务才算完整。
录入客户信息业务逻辑如表2.7所示：
表2.7 录入客户信息业务逻辑
用例名称
录入客户信息
功能简述
此功能是业务受理的第一步。用于输入客户信息。
后置条件
录入用户信息
前置条件
登录成功
基本流
选择证件类型，输入证件号；
根据证件类型和号码判断是否为老客户
如果为老客户，显示信息
否则输入客户姓名、性别、生日、通信地址等
保存客户信息
录入用户信息业务逻辑如表2.8所示：

表2.8 录入用户信息业务逻辑
用例名称
录入用户信息
功能简述
此功能是业务受理的第二步。用于输入用户信息。
后置条件
录入账户信息
前置条件
录入客户信息成功
基本流
输入号码；
检查号码是否可用；
选择通话级别和漫游状态；
保存用户信息以及客户和用户的关系，将手机资源列表对应手机号的可用状态改成不可用（因为号码已经被占用）。
检查输入的账号是否已经在数据库表中存在，如果存在，形成“合账”，需要检查对应账户中的余额是否大于“开户”所需要的费用；如果账号不存在，那么需要进行新增账号的操作。（见下一用例）
录入账户信息业务逻辑如表2.9所示：
表2.9 录入账户信息业务逻辑
用例名称
录入账户信息
功能简述
此功能是业务受理的第三步。用于输入账户信息。
后置条件
业务处理成功与否信息
前置条件
录入用户信息成功
基本流
如果合账，则显示账户的信息：账号、余额、账户持有人姓名、通信地址等。否则：
新建一个账号（此账号为上一个用例中输入），输入账户持有人姓名、通信地址、金额等；
保存账户信息以及用户和账户之间的关系。

2.2系统概要设计
系统概要设计如图2.2所示：

1. 操作员管理
2. 资源管理
3. 费用细项
4. 配置业务费

系统管理

管理员

登录

1. 录入客户信息
2. 录入用户信息
3. 录入帐户信息
4.
业务受理

退出
操作员

1.录入客户信息
2.录入用户信息
3.录入帐户信息

业务受理

图2.2系统概要设计图

登陆本系统主要有两种角色，一种是管理员，另一种是操作员，管理员主要是对系统进行管理以及对操作员的信息进行修改，负责资源管理，配置业务费用和对费用细项的更改，同时也受理业务。而作为操作员只负责开户功能。
2.3 系统运行环境
该系统开发与运行环境如下：
开发环境：Windows 7
开发工具：myeclipse
开发环境：JDK7.0
开发框架：Struts+Hibernate+Spring+Tiles
数据库管理系统：MySQL 5.0
服务器：Tomcat
浏览器：FireFox

2.4 小结
本章主要是介绍了通信行业的营业员对计费系统的功能需求和系统概要设计，通过功能结构图直观地描述了系统各部分之间的关系，为下一步系统的详细设计实现提供依据[8]。

3 系统详细设计与相关技术
3.1数据库设计
数据库的设计是指对于一个给定的应用环境，构造最有效的数据库模式，建立数据及应用系统，实质能够有效地存储数据，满足用户的需求，数据库设计是在数据库管理系统支持下进行的。
根据数据流程图,可以列出以下数据项和数据结构:
操作员信息表：操作员编号，操作员姓名，操作员密码，是否为管理员角色
客户信息系表：客户序号，客户证件类型，证件号码，客户姓名，客户生日，客户性别，客户联系地址
手机号码资源信息表：手机号码，手机号码类型，卡号，号码是否可用
用户信息表：用户ID，手机号码，漫游状态，通话级别，客户ID，账号
费用信息表：费用代码，业务费用
1.Toperator（操作员信息）表的逻辑关系与对应字段解释
操作员信息表（Operator_ID，Operator__Name，Operator_Pwd，Is_Admin）。
Operator_ID：操作员编号，作为实体的唯一标识，在登录的时候需要输入此ID，PK（主键）。
Operator_Name: 对应此编号的操作员姓名，只作为显示使用。
Operator_Pwd：此操作员的密码，在登录本系统的时候需要使用。
Is_Admin：此操作员是否具有管理员的角色，’Y’表示是管理员，’N’表。默认值为’N’。
2.TCustomer（客户信息）表逻辑关系与对应字段解释
客户信息表信息（Customer_ID，ID_Type，ID_Number，Customer_Name，Customer_Birthday，Customer_Sex，Customer_Address）。
Customer_ID：客户序号，是一个自动增长的数据，作为主键使用主要是为了方便在程序中唯一表示一个客户。
ID_Type：客户的证件类型，分为居民身份证、军官证、护照。
ID_Number：客户的证件类型，分为居民身份证、军官证、护照。
Customer_Name：客户姓名。
Customer_Birthday：客户生日。
Customer_Sex：客户性别。
Customer_Address：客户联系地址。
3.TAccount（账户信息）表逻辑关系与对应字段的解释
账户信息表（Account_ID，Contact_Person，Contact_Address，Account_Balance）。
Account_ID：账号，主键。
Contact_Person：账号对应的联系人姓名。
Contact_Address：账号对应的联系人地址。
Account_Balance：账户余额。
4.TMobiles（卡号信息）表逻辑关系与对应字段解释
手机号码资源信息表（Mobile_Number，Mobile_Type，Card_Number，Is_Available）。
Mobile_Number：手机号码，主键。
Mobile_Type：手机号码类型，可以是SIM或UIM。
Card_Number：卡号。
Is_Available：此号码是否可用。
5.TUser（用户信息）表逻辑关系与对应字段解释
用户信息表（User_ID，Mobile_Number，Roaming_Status，Com_Level，Customer_ID，Account_ID）。
User_ID：用户ID，自动生成。
Mobile_Number：手机号码，是Tmobiles的外键，引用到Tmobiles.Mobile_Number。
Roaming_Status：漫游状态，分为：省内漫游(‘P’)、国内漫游(‘D’)和国际漫游(‘I’)三种。
Com_Level：通话级别。分为本地通话(‘L’)、国内长途(‘D’)和国际长途(‘I’)。
Customer_ID：客户ID，是Tcustomer的外键，引用到Tcustomer.Customer_ID。
Account_ID：账号，是Taccount的外键，引用到Taccount.Account_ID。
6.TCharge（收费项目信息）表逻辑关系与对应字段的解释
收费项目信息表（Charge_Code，Charge_Name，Charge）。
Charge_Code：费用代码，PK主键，A-开户费，B-漫游费。
Charge_Name：费用名称。
Charge：业务费用。
TCharge_Rule（收费项目规则信息）表及对应字段解释
7.收费项目规则信息（Func_ID，Func_Name，Charge_Code）
Func_ID：ID，PK，用于表示功能的唯一标识，目前只需要有表示“开户”功能的’O’。
Func_Name：功能名称，目前只要考虑开户和变更通话级别/漫游状态两种情况。
Charge_Code：PK，是Tcharge的外键，引用到Tcharge.Charge_Code。
3.2系统开发相关技术
本系统是运用MVC模式开发，基于B/S模式，采用JavaEE技术，前台使用Jsp作脚本语言，后台使用数据库mysql，通过MVC开发模式，可以实现视图和数据分离，采用Jsp脚本可以实现页面的动态交互。使用该模式能够使各模块之间互不影响，系统完全依据高内聚低耦合的设计原则，可扩展性好，安全便移植。
3.2.1 MVC与模板概念的理解
MVC(Model View Controller)模型－视图－控制器。
MVC本来是存在于Deskt op程序中的，M是指数据模型，V是指用户界面，C则是控制器。使用MV的目的是将M和V的实现代码分离，从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步，一旦M改变，V应该同步更新。
模型－视图－控制器（MVC）是Xerox PARC在八十年代为编程语言Smalltalk－80发明的一种软件设计模式，至今已被广泛使用。最近几年被推荐为Oracle旗下Sun公司Java EE平台的设计模式，并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型－视图－控制器模式是一个有用的工具箱，它有很多好处，但也有一些缺点[9]。
3.2.2 MVC的优缺点
MVC的优点：
1. 低耦合性 视图层和业务层分离，这样就允许更改视图层代码而不用重新编译模型和控制器代码，同样，一个应用的业务流程或者业务规则的改变只需要改动MVC的模型层即可。因为模型与控制器和视图相分离，所以很容易改变应用程序的数据层和业务规则。
2.高重用性和可适用性 随着技术的不断进步，现在需要用越来越多的方式来访问应用程序。MVC模式允许你使用各种不同样式的视图来访问同一个服务器端的代码。它包括任何WEB（HTTP）浏览器或者无线浏览器（wap），比如，用户可以通过电脑也可通过手机来订购某样产品，虽然订购的方式不一样，但处理订购产品的方式是一样的。由于模型返回的数据没有进行格式化，所以同样的构件能被不同的界面使用。例如，很多数据可能用HTML来表示，但是也有可能用WAP来表示，而这些表示所需要的命令是改变视图层的实现方式，而控制层和模型层无需做任何改变。
3.较低的生命周期成本 MVC使降低开发和维护用户接口的技术含量成为可能。
4.快速的部署 使用MVC模式使开发时间得到相当大的缩减，它使程序员（Java开发人员）集中精力于业务逻辑，界面程序员（HTML和JSP开发人员）集中精力于表现形式上。
5.可维护性 分离视图层和业务逻辑层也使得WEB应用更易于维护和修改。
6.有利于软件工程化管理 由于不同的层各司其职，每一层不同的应用具有某些相同的特征，有利于通过工程化、工具化管理程序代码。
MVC的缺点：
MVC的缺点是由于它没有明确的定义，所以完全理解MVC并不是很容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。
你将不得不花费相当可观的时间去考虑如何将MVC运用到你的应用程序，同时由于模型和视图要严格的分离，这样也给调试应用程序带来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。
根据开发者经验，由于开发者将一个应用程序分成了三个部件，所以使用MVC同时也意味着你将要管理比以前更多的文件，这一点是显而易见的。这样好像我们的工作量增加了，但是请记住这比起它所能带给我们的好处是不值一提。
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
MVC设计模式是一个很好创建软件的途径，它所提倡的一些原则，像内容和显示互相分离可能比较好理解。但是如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶[10]。
3.2.3 JSP简介
JSP技术使用Java编程语言编写类XML的tags和scriptlets，来封装产生动态网页的处理逻辑。网页还能通过tags和scriptlets访问存在于服务端的资源的应用逻辑。JSP将网页逻辑与网页设计和显示分离，支持可重用的基于组件的设计，使基于Web的应用程序的开发变得迅速和容易。
3.2.4 JSP的优缺点
JSP技术的优势：
一次编写，到处运行。除了系统之外，代码不用做任何更改。
系统的多平台支持。基本上可以在所有平台上的任意环境中开发，在任意环境中进行系统部署，在任意环境中扩展。相比ASP/.net的局限性是显而易见的。
强大的可伸缩性。从只有一个小的Jar文件就可以运行Servlet/JSP，到由多台服务器进行集群和负载均衡，到多台Application进行事务处理，消息处理，一台服务器到无数台服务器，Java显示了一个巨大的生命力。
多样化和功能强大的开发工具支持。这一点与ASP很像，Java已经有了许多非常优秀的开发工具，而且许多可以免费得到，并且其中许多已经可以顺利的运行于多种平台之下。
支持服务器端组件。web应用需要强大的服务器端组件来支持，开发人员需要利用其他工具设计实现复杂功能的组件供web页面调用，以增强系统性能。JSP可以使用成熟的JAVA BEANS 组件来实现复杂商务功能。
JSP技术弱势：
与ASP一样，Java的一些优势正是它致命的问题所在。正是由于为了跨平台的功能，为了极度的伸缩能力，所以极大的增加了产品的复杂性。
Java的运行速度是用class常驻内存来完成的，所以它在一些情况下所使用的内存比起用户数量来说确实是“最低性能价格比”了。从另一方面，它还需要硬盘空间来储存一系列的.java文件和.class文件，以及对应的版本文件。
3.2.5 B/S结构简介与优缺点
B/S结构（Browser/Server结构）结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实