本地电信业务计费帐务系统分析与设计分析与设计说明

1、本地电信业务计费帐务系统分析与设计ver. 2.0分析与设计说明第一部分本地电信业务计费帐务系统 分析与设计说明目 录1概述31.1编制原则和主要思路31.2结合新计费帐务体制和规范v1.042系统功能的扩充和改进72.1电信新业务发展72.2对经营分析的支持82.3统一接口的设计92.4对规范v1.0部分功能的改进完善113系统规模和性能的考虑134设计任务范围134.1系统实现目标144.2设计工作目标144.3设计结果的表示184.3.1结构化设计表示194.3.2面向对象设计表示195分析设计方法195.1分析设计使用的方法195.1.1方法的选用195.1.2项目特点205.1.3方

2、法的选择205.2分析方法和分析步骤215.2.1需求调查报告的整理215.2.2系统边界的划定215.2.3功能的分析215.2.4实体-关系分析225.2.5控制分析225.2.6数据库表设计235.2.7系统功能设计235.2.8审核和测试246设计文档说明256.1设计文档的结构256.2各文档之间的关系266.3设计文档与需求分析的关系276.4设计文档内容使用和执行要求说明277各开发单位需要进一步完成的工作297.1研究设计文档297.2组织实施系统详细设计和开发29本地电信业务计费帐务系统分析与设计（v2.0）说明1 概述本地电信业务计费帐务系统（简称：本地计费帐务系统）是中国

3、电信业务支撑的关键应用系统之一，是提高服务质量、减少话费纠纷、提高经营管理效率的重要工具。中国电信集团公司为保证中国电信作为一个跨地域公司运行的可靠性和整体性，对本地计费帐务系统的改造工作提出了统一需求、统一设计、统一检测、分省实施的改造工作方案。集团公司在1999年组织了统一设计组，在计费帐务系统改造工作领导小组的领导下，以及计费帐务系统技术支撑中心的配合下实施统一需求和统一设计的工作，在1999年6月完成了本地电信业务计费帐务系统分析与设计v1.0（以下简称规范v1.0）的编写工作。作为本地网集中管理工作的一个重要组成部分，各本地网陆续都选用符合v1.0规范要求的本地计费帐务系统产品进行了

4、升版改造工作。集团公司在2002年12月组织了对整项工程实施进度的检查工作，并调研了计费帐务系统改造后的运作和使用情况。根据检查结果对如何发挥新计费帐务系统的作用和潜力进行了分析总结，同时也了解到规范v1.0应用实施中存在的一些问题和不足。中国电信集团广州研发中心自2002年接受电信总局委托进行本地电信业务计费帐务系统分析与设计v2.0的调研和设计工作以来，对部分省市本地网进行了一定的业务调研工作，逐步开始组织新规范编写。结合电信市场发展需求和在本地计费帐务系统研发和推广过程中的经验和思考，在规范v1.0基础上进行了较大修改和扩充，于2003年6月完成了本地电信业务计费帐务系统分析与设计v2.

5、0的全部分析设计和文档编写工作。1.1 编制原则和主要思路规范v1.0在总体设计思路、业务模型规划、数据标识统一和适应新帐务体制方面奠定了良好的基础，有效的提高了各本地网集中管理工作的效率和水平。对于使用中暴露的一些不足和目前新的市场环境、电信业务的发展变化，则需要在规范v2.0中进行完善提高和进一步体现。编制上主要考虑遵循以下几条原则和思路：Ø 规范v2.0对于前一版中主要有特色和优秀的设计思想内容采取了继承吸收的原则，并适当参照新业务发展需求进行改进，但考虑适应新业务发展需要，对原业务模型需要进行适当改进；Ø 从今后升版改造的延续性和可移植角度出发，对规范v1.0进行的

6、结构修改和流程修改时不对主要部分做完全重构性改动，以分拆、合并和扩充性调整为主；Ø 明确了计费帐务系统在新的业务支撑环境中的职能定位和与其它系统关系；Ø 考虑越来越多接口系统、外挂系统、代理商与合作伙伴支撑，以及营销与渠道管理支撑等外部需要，对上一版设计较为薄弱的接口设计部分进行改进加强，强调规范化和一致性，统一接口模型；Ø 规范v1.0中部分数据量增长快和部分性能瓶颈较为明显，需要从结构和方法上进行调整；Ø 新业务增加较快，流程差异较大，需要引入嵌入式功能设计方法，有效扩展系统功能，提高适应性；Ø 考虑支撑经营分析和渠道建设的数据需求，在系统

7、总体结构上进行改进，剥离出独立的业务数据支撑层概念，提出统计基表的设计，可以此为基础扩展为专项统计数据集，与接口设计配合来对外系统提供业务数据支持；Ø 新规范仍然以提供指导性设计建设依据为主要目标，具有一定强制性，实际系统建设过程中可在许可范围内根据需要对规范进行实例化和扩充调整，以适应各本地网的不同需求发展水平。Ø 由于各地网间结算系统的建设启用，原本地网计费帐务系统中的结算功能将转移到结算系统完成，因此规范v2.0中对结算部分设计不再扩充修改，仅保留原设计，供有特殊需要的本地网参考。本次本地计费帐务系统分析设计工作同规范v1.0版本相比强调了以下方面：1.2 结合新计费

8、帐务体制和规范v1.01. 市场环境的变化和对系统的要求新系统规范对以下几种环境变化影响作了设计上的考虑：a) 外部环境电信的南北拆分，使中国电信的本地计费帐务系统的建设，不但要满足南方21省作为原有本地运营者（ilec）的需求，还应该考虑在北方十省作为竞争性本地运营者（clec）应该建立怎样的本地计费帐务系统支持中国电信北方公司的运营。在外部市场方面，中国电信不仅面临网通在南方的渗透，还直接面临着移动和联通的替代性竞争。原有的系统只是位于生产层面，没有真正起到面向客户提供服务的作用。系统对合作伙伴（例如：互联星空）和各个代理点（长话代理）的支持没有进行考虑，在向这些新型的商业模式转换过程中，

9、系统难以进行扩展和提供有效的支持。新系统规范将对数据业务、卡类及智能网等业务处理、代理商与合作伙伴支撑、渠道管理等方面提供较灵活的业务支撑模式，以适应外部市场环境的变化。旧系统由于出版时间和当时市场格局等因素，对这些方面的支持考虑较少，不利于开展上述业务，不能有效适应这类变化。b) 内部运作管理中国电信在海外上市，将面临更加严格的监管。计费帐务的准确性和合理性直接影响着企业的形象和企业的市值。中国电信内部正在进行流程重组（bpr）以适应现代企业管理的需求。另一方面，计费帐务系统涵盖了用户资料和费用等敏感数据处理的全流程，从保证准确性、减少投诉、提高运作管理水平来看，必须要明确全程审核校验的操作

10、要求。在帐务系统中加强审核校验，界定相关系统的关系和接口界面，这些将贯穿于整个业务流程，规范v2.0在这些方面继续完善了方式和标准的规定。规范v1.0中对此有一定的具体设计规定，但各本地网的实际应用来看方式不统一，效果不一致。c) 网络技术和业务发展ngn/3g等网络技术的出现，使业务模式较目前发生了很大的转变，基于内容、流量、第三方服务、虚拟运营商会变得越来越普遍。尤其是用户的自服务（self-service）的出现，对本地计费帐务系统的功能提出了新的需求。电信多元化新业务、新服务的出现，使得原来的设计不能充分满足新业务开发的需要，尤其是一些业务流程与原设计有冲突的服务无法开展或较难开展，例

11、如：合作伙伴的代收费的违约金的收取，业务费用的分成、银行代办费用的结算和实时计费帐务业务的即时结算等。另外在普遍利用银行和社会代办点收费的模式下，系统的安全机制必须进行充分的考虑。新系统针对这种业务技术的发展变化情况进行了较多考虑，设计实现方面也考虑了对规范v1.0的继承性，以及工程实施上歌接升级的简便性。除继续保留原综合业务支撑、提供客户化服务等特色外，增加了较为灵活的嵌入业务模块设计，方便新业务增加，并对融入系统整体数据统计进行了设计考虑，满足电信业务不断发展的需要，为各地综合电信业务经营和管理提供科学的依据。2. 新的支撑系统定位和系统关系a) 各支撑系统间的关系：主要是与综合业务系统、

12、客服系统的关系，目前电总正在制定综合业务系统和客服系统的规范，目前分散在各系统的一些业务性功能今后可能会主要集中到综合业务系统，比如部分销帐前台业务，客服系统主要作为一种渠道存在，帐务系统则以提供数据和应用服务的支撑为主，在此之上是各类经营分析、增值服务系统。b) 帐务系统定位：计费帐务系统今后是业务数据提供的核心系统之一，电信主要的业务量数据需要由计费帐务系统提供，同时包括各种类型费用回收服务、欠费管理等传统功能。另一方面计费帐务系统仍然是面向生产和数据的系统，不应承担过多的直接经营分析功能，今后的发展应更倾向于综合生产和数据支撑中心的概念。规范v2.0针对这种发展动向在系统业务资料模型、对

13、外接口管理、数据支撑等方面的设计上有所体现。3. 理顺生产组织流程和发挥系统潜力电信业务种类繁多，计费帐务处理环节复杂，经过本地网集中管理的调整过程和计费帐务系统的升版改造，各个本地网的管理模式得到了一定程度的统一。不论是规范v1.0还是规范v2.0，都强调了“三分技术，七分管理”的指导思想，从管理模式出发，理顺计费帐务生产组织机制的关系，明确岗位、工位的设置，强化授权管理、闭环管理等手段，以现代技术手段和新型的管理思想相结合，建立本地计费帐务生产新的目标管理体系。在规范v2.0中更加侧重在如何组织好生产管理流程，更好的发挥新系统的作用上。从对目前版本的计费帐务系统使用的调研情况来看，计费帐务

14、的生产压力仍然很重，分析原因主要在于三点：一、很多地方的计费帐务生产人员也是其它支撑系统和业务系统的运行维护人员，职能重叠，工作繁重，比较缺乏科学的管理流程，组织保证上不够；二、目前在业务系统不够规范和完善的情况下，基本业务资料的问题较多，而计费帐务系统由于涉及准确计费，是对资料非常敏感的系统，为保证计费生产准确性，需要在每个出帐周期内单方面进行大量的资料审核和业务校验工作，压力较大；三、计费帐务直接承担了较多经营分析方面的工作，包括数据提供和直接报表生成。从理论上讲面向生产和面向分析的系统在设计方法上存在固有矛盾，二者难以同时满足，这也是原有系统结构无法很好的同时支持生产需求和经营分析需求的

15、原因。在各地经营分析系统建设完善之前，计费帐务系统仍然要不可避免的承担部分经营分析支撑的职责，在经营分析系统建设完成后，计费帐务系统应主要承担数据支撑的职责。要充分发挥新计费帐务系统的作用，必须在理顺生产管理流程和搞好其它系统建设的同时，从人员组织、审核校验、对外数据和报表支撑方面考虑进行改进和提高，后两点是可以从系统设计角度着重考虑的焦点。4. 计费帐务体制的变化考虑按照信息产业部技术规定中国电信计费帐务体制标准，计费帐务体制的采用中央、省、本地网三级模式建设，本规范原则上适用于其中本地计费帐务中心的要求，系统的设置不受地域的限制，能够与省级电信计费结算中心（如省级长途计费中心、省级智能网中

16、心等）相配合，能够适应将来多个电信企业间的计费结算体系（如联通、移动等），计费帐务体制的灵活适应性较强。实际在系统建设过程中，部分省根据自身特点选择了省集中计费帐务处理的模式，本地网不再保留主要计费帐务功能，目前这类系统已经投入运行。今后在各省的计费改造工作方面，仍然有可能出现其它集中方式，比如建立大区中心（界于省和本地网之间）系统，考虑各省规模和业务管理特点，规范v2.0所定义的计费帐务系统必须要能适应这种规模和管理模式上的变化，为各省的后续改造工作提供指导方法和标准，这一点在新规范中也会从数据管理、功能分布、管理流程设计上得到具体体现。5. 统一接口与业务标识规范v1.0从中国电信网络长远

17、发展的需要出发，提出了电信业务的统一业务标识、统一客户标识，并给出了统一的编码解决方案，为中国电信计费帐务系统的三级模式的联网打下坚实的基础，同时满足本地网计费帐务系统的改造方针“统一需求、统一设计、统一检测、按省实施”。但由于电信业务在近几年发展十分迅速，各本地网在新业务开展、旧业务保留方面还存在很多地方特色的东西，从系统升级的业务延续性来看还不能采取一刀切的方式，规范v1.0业务处理的覆盖范围有限，不能完全满足很多特殊要求。对于这个问题，一方面应该从管理上入手，对各类业务进行规范化、流程化处理，以及统一标准化业务标识；另一方面系统需要考虑提供更为开放的接口方式和标准，便于系统改造和接口。规

18、范v1.0在对外接口定义和设计考虑上较为简单，不能很好地适应这种实际情况，因此也在各地实际应用中造成一些困难。新规范改进的一大重点就是提高接口的开放性和易用性，提出了统一接口模型的业务技术设计方案，也为今后与其它正在改进和完善中的支撑系统的接口交互提供了有利条件。2 系统功能的扩充和改进规范v1.0中在系统功能方面提供了客户化帐单、话费限额管理、灵活缴费（纵向帐目）、灵活设置帐务周期、帐户客户概念的明晰、加强优惠处理、完善审核校验等有特点的设计，在规范v2.0中保留了上述基本功能，并根据实际应用中的问题和经验对其进行改进完善，同时也针对最近几年来电信业务的变化趋势新增了部分实用功能，提高了系统

19、适应未来需求发展的能力，以下分几个方面来阐述：2.1 电信新业务发展目前电信业务发展势头很快，从业务种类看小灵通、预付费、缴费卡、代办业务、固网短信、数据业务等迅速增长，未来可能继续增加3g移动类业务；从处理类型来看有实时计收费、预扣预划帐、分期分批和固定周期处理等不同种类。规范v1.0中对实时处理、多帐务周期处理是有一定考虑的，但在业务适应性和实用性方面考虑还不够充分，从业务流程、结构设计、数据统计上如何保证各种类型业务实施需要进一步改进。另外不同类型的业务开展在资料结构、业务模式上提出了新的需求，需要系统提供便于新业务模块加载和扩充的设计结构和流程接口。规范v2.0中对这方面进行了重点考虑

20、，引入了嵌入式模块设计概念，保证流程的接入和数据统计整合。重点针对的改进方面是：a. 提出较为灵活的新业务模块系统嵌入概念，可实现较小的流程接入改造代价，适用于小灵通、3g、预付费、缴费卡、代办业务等新业务特殊处理；b. 针对各地已经采用或计划上的联机采集系统，从帐务的实时采集接口和实时计费统计、实时帐务处理、实时停复机处理等方面来设计业务流程。实时业务收费方面可以按照目前的实时银行代扣的模式，规范v2.0中重点提出了预扣记帐或预付费直接划扣模式，另外也允许与传统业务一起收费；c. 加强对卡类业务的管理和支持，包括各种缴费卡、预付费卡业务；d. 临时用户实时结算，结合联机采集、实时计费、包租包

21、时段等方式；2.2 对经营分析的支持目前各地计费帐务系统都面临着一个比较大的压力，即业务和财务管理部门对统计分析报表的需求。计费帐务系统由于主要面向生产，结构设计上为保证快速出帐、快速出托和销帐等因素，数据库表会采取适合快速查询更新的设计方法，而面向统计分析的数据库表设计更强调关联集合统计和分析的粒度与性能，二者在结构设计上存在一定矛盾。考虑电信基本业务量数据来源于计费帐务系统的事实，必须对对外输出的数据和接口进行剥离和管理，建立较为独立而又面向经营分析需求的数据支撑层，这个矛盾才能得到比较好的解决。规范2.0中，从帐务系统剥离出独立的数据支撑层面，用于支持各类对外数据输出、经营分析的数据统计

22、和分析功能，并遵循统一的接口模式。在数据支撑层的基础上还可以继续考虑按照不同业务方向和主题进一步形成数据集市，但不宜上升到数据仓库的层面，这类扩展功能可以由用户和开发商自行组织开发。增加的数据层目前提供应收统计基表的设计和概念，根据需要可以扩展到实收和不同需求层面的数据集，例如：a. 运营商摊分结算和流向流量分析，其中流向流量从清单入手统计分析，所得数据对于业务经营有重要参考意义；b. 市场经营分析基础数据：如业务量数据，是按照号码、分局、业务属性、终端类型、区域等一系列基本维度组成统计分析用的基础表，维度粒度很细，建设方和开发商可以在此基础上，根据市场经营分析的需求汇总扩展出直接用于主题分析

23、的报表数据集，侧重分析业务量和用户群、大客户等；c. 面向财务分析的扩展数据集：在基础数据集上生成，更强调帐务的平衡需求和业务量的种类划分；d. 对客户经理、社区经理的支持，包括业务总量、变量、欠费追缴等方面，也在基础数据表上生成，结合用户资料可提供特定用户群业务量分析数据和统计报表；e. 信用度，目前电总范围内没有明确统一的信用度模型，已知的信用度应用上都集中在欠费管理环节，作为催缴、停机依据，在特殊优惠、业务分析等方面还没有应用。规范2.0提供了一种综合的信用度分析模型，侧重业务量和行为分析，建设方和开发商在建立实际生产和分析模型前需要明确信用度建立的用途、目标，并选择合适的要素和方法进行

24、分析；2.3 统一接口的设计基于目前国内支撑系统建设的具体情况：各个支撑系统分期分批建立、分集成商单独建立或者由于工期限制进行分期招标建设，造成各个支撑子系统各自为政，数据相互之间难以共享。一些厂家提出在企业信息系统中有四类数据必须共享：客户/帐户（customer/account）、网络拓扑（network model）、产品数据（product portfolio）、服务数据（service portfolio）。为了解决这个问题，提出了数据源唯一的概念，即各个系统的同一个数据的数据源只能是产生该项数据的系统。根据以上概念，必然涉及接口问题，各个系统的接口都不一样，需要统一。现提出以下接口

25、模型：考虑到xml可以定义任何数据，在支撑系统互联中可以利用xml定义接口数据。但是完整的xml定义较为烦琐，接口处理效率较低。为了解决以上问题，规范2.0中提出专门针对计费帐务系统所需要的数据专门定制接口协议的标记，可称之为“类xml语言通用接口协议”。该协议由标记、动作和数据三部分组成，其中数据可以分成并列的数据子项，如果是结构型的还可以定义为结构，今后在有实际需要时还可以扩充成对象的形式，以便于进行继承。全局数据模型可以根据实际需要进行定义，它的功能有点类似数据仓库概念中的元数据（meta data），它是用于解释接口数据的数据。在计费帐务系统与不同系统接口时，现在是双方商定协议，双方修

26、改接口程序。在上面的接口模型下，只需要修改全局数据模型就可以完成。而且这种模式有利于利用全局数据模型实现数据中心。这种语义解释方式定义的接口，可以与业务涵义紧密结合，易于表达和解析，结构上便于扩充，同时在实现方式上可以支持到实时和定时交互两种方式，便于在更广泛的平台范围上构建统一的交互接口。该模型概念基于xml，开发商可以利用平台附带的xml支持功能来实现，也可以基于自行开发的处理系统实现。统一接口主要考虑下述类型的业务处理：a. 提供与其它支撑系统、外挂业务系统和经营分析类系统的接口；b. 支持提供经销商和代理商收费、追缴接口，以及特定的结算数据和统计报表；c. 能提供对特殊/非特殊群体的优

27、惠支持和与营业系统的优惠协议转换接口。今后一个可能的发展方向是类似优惠规则这样的业务受理和管理功能会集中到综合业务系统，作为对客户提供服务功能的一部分。但因综合业务系统只能提供业务层面的参数表述，要把所有优惠规则用一种计费帐务系统可操作的参数来描述存在很大难度。系统差异造成帐务系统和营业系统使用的优惠规则必然会存在不同的表述方式，这之间有一个规则转换的接口存在。理论上计费帐务系统与综合业务系统如果在用户、帐户等概念和数据定义上完全一致，并有及时的变更通知的话，所有优惠都可以由综合业务系统设置管理。规范v2.0中提供的统一接口数据表达方式，可以在此基础上扩展到对公众普遍优惠类型的规则转换接口设计

28、，或对一些特定条件的用户群或特定用户优惠规则的转换接口设计。另外，针对对外应用接口的形式，除类xml应用方式外，各厂家应尽量统一使用中间件平台来完成，减少接口形式的复杂性。2.4 对规范v1.0部分功能的改进完善对原结构设计某些方面应用存在问题，或不完善的地方进行必要调整，以方便提高系统灵活性和便于应用设计开发。主要的一些改进点如下：a. 对用户-帐户-客户模型表达进行适当改动。其中用户-帐户-客户的模型关系不变，但考虑目前越来越多的同一用户拥有多种类型设备/服务的情况，在优惠设计、出帐、销帐打单选择组合方式等多方面要求系统具备越来越多的灵活性，比如一户多机、isdn主从号码（含32b+d等）

29、、主叫鉴权、centrex、800捆绑业务等。规范v2.0设计上对用户和设备增加了集群业务关系的字段，用户设备或服务的捆绑集群关系可以用较简单的方式实现串联。这个设计上的变动对用户数据割接转换影响不大，对优惠、销帐等应用程序设计则会有一定影响，但更有利于设计实现和适应新业务；b. 针对今后可能发展的同一付费关系帐户下多种缴费方式和不同银行帐号的业务的情况，对帐户与银行帐号分级分表对应，除考虑同一帐户对应多个银行帐号或缴费方式外，也考虑到单用户不同帐目类型不同付费帐号，但要求集中缴费打单的情况，这种做法对多用户帐户的余额摊分等情况也易于处理，比较适应未来预付金类型缴费业务的发展；c. 由于实时业

30、务发展的需要，预付金、缴费卡等预存业务发展较快，规范v1.0中没有针对此类业务的专门设计，仅在原帐户表中设置了帐户余额字段，还不能有效支持业务需求。新的规范设计中结合对用户、帐户资料结构的调整，以及对销帐相关设计的调整来对此类业务进行支持，并增加了相关的资料表、预付费余额表、预扣款记录表等，以实现对预付金和实时预付费的管理；d. 增加销帐处理方式，提供帐单项表设计。帐单项表主要存放按照预定制的帐单格式生成的帐单项目，数据量增长比帐目小。对大规模或者设备性能条件不足的本地网，可以考虑不在帐目一级进行销帐，而是在帐单一级销帐，帐目仅用于查询和拆分依据，这样可以提高托收销帐等耗费资源和时间的处理的性

31、能，相应的应用设计上销帐和反销帐方式都要调整。用户还可以选择预生成帐单或改帐单表为横表的方式进一步提高处理性能。e. 区分开用户注册帐户付款类型和实际缴费付款方式，便于生产和财务统计上区分不同来源和归属需要。f. 对销帐记录表、付款记录表等销帐、付款过程相关表进行了较多修改，以适应业务发展和分析统计需要。结合新增的预付费有关的表，在销帐方式和记录上有较大扩充和修改。g. 增加发票和发票管理有关记录表，并区分开定制发票项和定制帐单项。h. 考虑滞纳金在实际应用过程中常因为争议、故障等原因不能按照依附帐务周期的方式来计算，另外部分地区也存在滞纳金按帐目摊分、统计、减免等问题，设计上暂未对滞纳金计算

32、的参考时间结构进行调整，但具体应用中滞纳金起算日期和批量减免可以与费用挂钩，而不是依附帐务周期；i. 根据分运营商、分卡等收费、统计和优惠减免等需求，考虑关联帐目类型来增加优先级、运营商字段、卡类、帐单项分组等信息，便于收费、分类、打单和统计需要；j. 零头对应合同号和服务单独进行管理设计，解决多用户帐号摊分和历史欠费帐务平衡的困难；k. 目前业务上新的优惠方式和规则变化很快，规范v1.0在规则表达上提供了较好的基础，但还需要进行补充完善，对优惠设计进行调整。比如优惠的违约回追、返还方式，清单级优惠及与总量的交叉优惠等。例如根据总量返回优惠打往某地区的通话费，或超过优惠约束期限来缴费的已出帐用

33、户不给予优惠，需要把已出帐生成的优惠回追，以及可能的对旧周期优惠的返回等。新的规范v2.0对这些方式进行了较多完善；l. 强化全程审核校验功能，规范v1.0对计费帐务处理过程中主要审核校验环节作了说明，规范v2.0在审核方式、要求，以及用户自定义业务校验规则的接口进行了完善，保证出帐、收费等程序化、自动化、可视化，可调度、可统计、可稽核，重点解决自动稽核和人工增减稽核规则的应用问题。3 系统规模和性能的考虑规范v1.0主要面向本地网的建设，按实装用户量把本地网规模分为小规模（20万）、中规模（2060万）、大规模（60150万）、超大规模（150万以上）四种，分类基本合理，但系统结构设计上在网

34、络规模适应方面还存在不足，对超大规模用户量的情况性能较差。规范v1.0对不同规模的系统结构设计是一样的，实际在超大规模局应用时用户资料、帐目、帐单等表都会出现数据量增长过快，访问率高、销帐和统计性能下降等情况，按原设计方法只能通过一些物理调整优化方法来进行改善，比如结合数据库系统特点用分段子表、分散物理位置等，由于实际的设备条件限制往往很难达到较理想效果。考虑这个因素，规范v2.0主要从以下三个方面来提供解决途径：1. 根据业务特点进行逻辑分表设计2. 调整出帐、销帐方式，降低高频率业务对系统的压力3. 剥离统计数据，与生产数据降低关联，减轻统计分析对系统的压力其中后两种方式前面第2节中都略有

35、描述，第1、3种方式还会在数据库设计章节中结合表结构设计具体进行表述。4 设计任务范围本地计费帐务系统的设计工作是在规范v1.0基础上，对中国电信本地计费帐务处理新业务需求进行补充调查和分析的基础上，结合对今后电信业务的发展的需求预测，采用规范的系统分析设计方法进行的。根据各地的现实条件和经营现状，继续坚持中国电信对本系统的改造工作提出的统一需求、统一设计、统一检测、分省实施的方针。根据这一方针，结合对今后跨系统共享数据和协同工作以及企业系统的统计一致性的要求，规范v2.0设计组将系统设计任务的范围确定为：以规范v1.0设计为基础，尽量保证系统结构和功能的延续性、修改完善现有功能设计、扩充适应

36、新业务定义为核心的系统概要设计和逻辑设计。在设计工作中尽量将与实现平台和工具相关的工作，留到系统数据库物理设计和详细设计阶段，由各公司结合具体使用的工具平台自行进行。系统设计方法和特点与规范v1.0基本一致，因此分析设计方法方面沿用了大部分相关文字说明，仅作为设计阅读参考，其中设计目标、结构方面根据新增和修改内容进行了调整。系统设计任务仍然分为三大部分：· 数据库逻辑设计：包括系统数据库逻辑设计、基本表结构设计、必要的索引和主外键设计、数据编码规则设计，以及面向对象方法中的表类、实体对象类设计等工作。· 系统功能设计：包括事件事务设计、事务依赖性设计、处理流程设计，以及面向

37、对象方法中的操作类设计等。· 系统操作关系设计：包括事务-数据表操作关系设计、数据状态迁移设计及数据生命周期设计等。话单和计次数据的采集系统的设计不包括在本系统设计工作范围之内。系统对话单数据的采集方式可根据各地的实际情况来选择。本次系统设计对此处的要求是本地计费帐务系统应可与包括实时联机采集在内的任何方式的数据采集系统配合工作。4.1 系统实现目标本地计费帐务系统的实现目标：为建设集中的、权威性的本地综合计费帐务中心提供可靠的、先进的、适应性强的应用系统。从多方面为用户提供及时、准确的计费服务，为用户提供灵活的、多样的交费方式；为中国电信制订和实施灵活多样的营销策略和资费政策提供平

38、台；满足中国电信今后向用户提供新业务、新服务，适应今后市场竞争的需要。为尽快建立中国电信上下一体化的、统一的计费帐务处理、管理系统，构建统一的服务网体系打好基础。新规范设计的实现目标主要集中在新业务发展的扩充和适应能力，以及体现计费帐务系统数据支撑作用两大方面，另外对旧的设计不够完善或结构需要调整的地方进行了修改补充，使系统设计更加适应未来数年电信业务发展、企业信息化和提高服务水平的需要。本地计费帐务系统必须使用：统一业务处理和管理流程、统一计费规则和计算方法、统一计费数据分类和使用、统一标准化的数据字典、统一数据标识编码；必须具有：统一的与其它系统的接口，包括：统一的协议栈、统一的数据格式。

39、4.2 设计工作目标系统的设计工作目标是对系统实现目标的保障。本地计费帐务系统的新设计规范是在充分考虑计费帐务处理的特点和新业务发展的前提下进行。由于已经具备了v1.0的实现基础，系统设计工作重点保证实现系统的新开发目标，并确保原有目标的实现，即：应达到在保证系统模型的统一、系统核心的统一的情况下为系统的实现提供一定的灵活性。系统设计的工作目标为：1设计面向企业信息数据支撑的系统：计费帐务系统是企业经营信息的重要数据来源，所生成的数据反映了企业经营活动的效益和产量，并对分析业务发展动向和竞争对手经营状况具有重要意义。但由于计费帐务系统属于面向生产的系统，在数据结构、流程处理等方面都不利于直接支

40、撑经营分析类业务处理，一般需要提取基本生产数据进行转换和分析组合后才能表达为经营分析所需要的结构形式。生产型系统和分析型系统在接口上必然存在一个基本数据抽取和转换的过程，这就要求计费帐务系统必须能根据经营分析系统等管理系统的需要，灵活提供具备指定结构和对应关系的数据。另外在多数地区经营分析系统等管理系统未完全建设的情况下，很多市场和经营分析报表还需要从计费帐务系统直接获取。根据业务需求分析对系统数据支撑的要求，可以在此基础上剥离出独立的业务支撑数据层，按照业务需求的最小需要和业务关系主题进行组织，可直接用于经营分析和其它业务管理系统进一步分析统计的需要，同时避免了与计费帐务生产数据混杂带来的结

41、构设计和性能设计的矛盾。规范v2.0对建立业务支撑数据层的业务需求进行了调研，从中考虑了企业业务分析管理的基本数据模型需要，提供了统计基表的设计概念，该类表提供基本的业务统计数据元，在实际应用中可扩展到按照所需要的最小业务对应关系建立关联，并按照一定的主题方向聚合，便于其它系统获取原始统计数据。对于应收数据较易形成定期抽取的业务数据集，但对始终在动态变化的实收数据需要开发商在应用设计上避开业务操作繁忙的时间和处理类型。动态数据的抽取模型需要根据具体统计分析需求来确定，规范v2.0中不限制具体实现的方法。剥离出的业务支撑数据层可以在物理上与生产数据分开存放，不影响原有的系统数据结构，不过量妨碍生

42、产，抽取过程一般安排在非繁忙时间和与低耗费资源类型处理并行进行。业务支撑数据层应包含的是基本统计分析数据和大主题聚合，是通用的对外数据支撑集合，还不能直接满足经营分析系统等其它业务管理系统的所有需求，其它系统应在按需提取和进一步汇总转换的基础上满足自己的需要，但其存在完善可减轻在数据支持和需求上的供需矛盾。根据新业务的发展，在新增业务数据类型方面，应设计较为灵活的参数描述方式和可扩充结构，保证同性质业务变更对数据结构无须调整，同时便于增加异构性质业务，减轻维护工作量和增强了业务适应能力。2、设计面向新业务发展的系统：目前电信业务发展十分迅速，经常会需要计费帐务系统在短时间内提供业务开通和计帐的

43、工作。原系统设计虽然建立了基本业务关系模型，并应用了纵表等较为灵活的方式，但对于业务处理的灵活增加仍然不足，生产维护部门和开发商还需要经常面对较大量的代码修改、补充开发工作，压力很大。解决业务添加问题，需要重点对以下几个方面进行设计考虑：l 通常新业务对计费帐务系统的处理要求有：计费、优惠、特殊减免、合帐、收费、退款、统计等几方面或部分环节，要实现较为灵活的业务添加必须先对以上各个环节的处理流程、数据结构进行妥善分析，找出主要制约因素；l 对主要制约因素要从结构设计上重点来解决添加问题，一方面要考虑应用程序实现的可能性和业务合理性，另一方面也要考虑对每个环节的流程规范化、参数化，通过规则语义的

44、设计定义来描述流程的输入/输出以及过程方式。要实现这两点，需要对业务处理进行基本分解，把易变的业务逻辑尽可能体现在参数和规则上，对处理规则的描述要涉及到行为性定义；l 应用嵌入式处理方法，对与核心业务逻辑关联松散或流程矛盾的新业务，尽可能采用外挂嵌入的方式，保证应用可融入流程控制，并重点从数据结构设计上解决相关的数据流程融入和统计汇总的问题，定义较为灵活的外挂嵌入应用接口方式；3、设计统一接口平台的系统现有系统与97营业、1000号、结算、112、经营分析等多种系统有直接接口，接口种类繁多，处理流程各异，维护复杂，不利于查找问题，并容易引发争执。解决接口问题必须在设计方法和平台上进行改进。分析

45、对外接口特点，可以简单分为主动、被动方式，也可从时效上分为实时/准实时、定时、不定时触发等类型；还可以从技术形式上分为接口表、socket通讯接口应用、中间件、文件等。实际应用中还因为业务需求因素导致数据结构多样、服务种类繁多等问题，给维护方和开发商带来很大压力，也不利于业务的及时开通和稳定运行。归结起来，接口需要解决的就是数据传送和提供应用服务，规范v2.0中定义了两类基本接口业务形式：新的类xml接口和中间件接口，前者重点解决接口数据传送的结构适应性，后者主要解决应用服务提供问题：l 对其它系统的数据接口，采用类xml接口的方式进行解决，降低接口复杂性，类xml结构使数据语义、格式等都成为

46、可动态定义的、有具体含义的参数，可以在此基础上开发较为通用的接口逻辑处理程序，增强通用性和可扩展性；l 应用接口普及中间件方式可以取得较好的整体效果，应用服务可动态加载卸除，有负载均衡和压力控制，对于服务质量、数据库安全性都有可靠保证。接口的统一有利于系统互连、降低平台维护复杂性，但需要各个系统都朝同一个方向努力，统一进行规划设计，才能达到较好效果。另一方面，针对目前接口中经常出现的问题查证困难、责任不明等问题，在流程设计和管理制度上还应要求：l 有交互接口的任意两个系统都必须对各自取/放的数据进行业务规则检查，保证己方提供和获取的数据的业务正确性；l 接口数据和服务必须具备基本的异常校验和错

47、误纠正措施，保证在数据传送和服务调用过程中的正确性；l 交互系统双方应在新接口的设计开发、调试、开通过程中保证设计沟通、事先通知、事后交流总结，本着对对方系统负责的态度如实、及时的把己方需求、变更、计划书面传达对方并确认，减少沟通交流不足造成的异常、拖延、投诉等负面影响。规范v1.0中列举的几项设计工作目标仍然是需要继续保证的，内容如下：1设计面向服务的系统：设计便于灵活配置的应用系统，同时要考虑系统分布，提高构件和对象的集成度，适应不同规模用户的使用，适应多种结构。为了满足互操作和系统规模的适应性，同时体现集中设计系统核心功能的要求，将系统设计成为一个服务提供系统。人机界面的设计一般不加考虑

48、，留待各地实现时完成。为了适应不同实现技术的需要，设计将以两种方式表达，一是结构化方式，二是面向对象方式。在客户/服务器体系的三层结构中，设计重点在应用层和数据管理层（不包括数据库管理系统）。设计的结果可以以三层结构实现也可以以传统的两层结构实现。这样可以保证实现的灵活性。系统提供的服务可定义为两个层次，一个层次是向本系统内部提供的服务，另一个层次是向外部提供的服务。后一个层次的服务应当给出严格的接口定义，能够适应不同的分布体制，以便于互联和互操作。同时，后一层次的设计还应当考虑与安全机制的兼容。2保证系统的内在质量：系统设计应保证系统的内在质量，要求所设计的系统必须要内聚性好、耦合性低。使系

49、统方案具有较好的结构稳定性和业务扩展性。要保证所要求的内聚性和低耦合性，必须要使构件的划分做到 保证事务的完整性 有明确的数据输入/输出系统设计的内在质量，应符合对软件设计质量的一般要求。对于概要设计来说，重要的一点在于保证高的模块内聚性和低的模块间的耦合性。在系统划分和模块设置时，应当根据计费系统的特点，找到耦合简单的点，划分子系统；同时将操作和数据关联较大的成分组合成模块。3充分考虑计费系统与其它系统的区别及与其他系统的配合工作：根据需求分析中对本地计费帐务系统的位置定义，本系统必须要与其他系统协同工作，如：“九七工程”系统（营业管理系统）、省计费结算系统、112系统等。与其他系统相比，本

50、地网计费帐务系统具有以下特点,在设计中必须加以考虑： 既有对联机事务处理要求，处理日常帐务处理功能（如销帐等）；又有大量的批处理，如数据采集、计费等。设计时必须兼顾这两方面的要求。 系统处理和吞吐的数据量很大。以长途话单为例，若以每用户每月30张计，一个具有50万电话用户的局，每月有1500万张长途话单。如果处理市话详细话单，这个数目可能要增加一个数量级。设计时，应当保证这一情况下的系统性能。 计费系统涉及到企业的经济效益和形象，也关系到用户的切身利益。它的运行正确与否，是十分敏感的问题。在设计中，必须保证设计的正确性，保证处理的一致性和设计质量。 本地计费帐务系统的运行环境复杂，对互操作的要

51、求较高。本地计费帐务系统需要和上级计费结算系统、本地“九七”系统、银行金融系统等作业务方面的接口，还要和上级、本级的管理部门进行纵向的统计查询接口。电总还提出了统一客户管理、集中交费和异地交费等长期系统目标。为此，系统设计时，必须考虑与其他系统的良好互操作性。4设计方案尽量适应不同技术特点的公司使用电总要求采用集中设计、分省实现的方式建设本地网计费帐务系统。这就要求此次的设计能够满足各地的不同需要，包括不同的规模、不同的实现工具等。设计要针对系统核心功能进行。在统一业务、统一数据格式的基础上，各地可有实现上的灵活性。设计方案应能适应采用不同开发体系的公司如采用面向对象分析和设计（ooa&

52、;d）技术的公司和采用结构化（ssa&d）及面向数据（ie）技术的公司使用。5减少互操作界面，以适应不同的分布体制，减少接口种类为保证系统的业务操作稳定性和安全性，减少因与其它系统耦合过紧造成的实施和管理困难，系统的设计应考虑对构件分级：· 互操作相关的构件· 内部处理构件尽量将互操作构件规范化并统一，避免过多和分散的互操作造成系统变动的困难，和对外部系统的影响（或受外部系统变动的影响）。保证在内部系统分布体制与外部系统分布体制不一致的环境下降低转换的难度。设计方案不应限制系统实现的体系结构，应能适用于目前常用的应用体系结构 应能保证在c/s（client/serv

53、er）这样的两层结构上实现，也能在三层结构（3 tiers）上实现。4.3 设计结果的表示为方便不同技术特点，采用不同开发方法的公司使用本设计结果，本地计费帐务系统的设计结果仍然采用规范v1.0中使用的两种不同的描述表示方法：结构化设计表示方法和面向对象设计表示方法。数据库设计对两种设计表示方法是一致的，即：两种表示方法在对数据层的描述上是一致的。主要区别在于对处理方式、构件、功能（事务和处理）与数据的关系等的描述和定义上。因此，数据库设计报告不分结构化设计和面向对象设计。系统功能设计采用结构化和面向对象两种表示方法描述。4.3.1 结构化设计表示结构化设计的结果描述是一组功能部件（事务和处理

54、），及其功能（事务和处理）和数据的处理对应关系。功能部件必须保证功能和事务的完整性。部件由一系列处理组成。部件的设置充分考虑计费系统的特征，其接口有相对的稳定性。4.3.2 面向对象设计表示面向对象的设计结果由一组对象或类来表示。由于采用关系数据库，数据库的表和类不能严格对应，因此，对象类将分为三个层次。一个层次是与数据库表或视图对应的数据库类，属于三层结构的数据管理层；另两个层次为实体类和处理类，对应三层结构的应用层；实体类处于应用层的下部，面向数据层；处理类处于应用层的上部，面向业务。5 分析设计方法规范v2.0采用的分析设计方法与规范v1.0基本一致，本章内容主体沿用规范v1.0的相关文

55、字，以作设计参考，并适当进行修改补充。5.1 分析设计使用的方法5.1.1 方法的选用系统分析或需求分析是系统开发的重要阶段和步骤。其主要目的是从用户提出的需求出发，描述系统的构成和功能，为系统设计奠定基础。系统设计使用系统分析的结果，从实现的角度进一步描述系统的功能和数据结构。各地以此为依据实现本地计费帐务系统。普遍采用的分析和设计方法主要有结构化方法和面向对象方法。方法的选用主要由如下几个方面确定： 开发人员对方法的熟悉程度 方法否能够适应项目的要求和特点 有无足够的工具支持软件工程的过程有传统的瀑布模型和各种渐进的演化模型。由于计费帐务系统的需求比较明确，各地开发人员对应用比较熟悉，所以

56、系统开发过程以瀑布模型或改进的瀑布模型为主。5.1.2 项目特点中国电信“本地计费帐务系统”是面向全国本地网开发的系统。系统分析开始以前，中国电信的相关部门已经对系统的需求进行了相当广泛的调研和定义。开发人员也都有类似系统的开发经验。所以项目的需求从总体上来说是清楚的。该项目是一个生产处理系统，其功能必须和相应的业务规范保持一致。目前各地已经参照设计较为详细和稳定成熟的本地网计费业务规范v1.0建设了本地网集中计费帐务系统，但为了适应当前和未来的业务规范变化，要求系统的分析和开发方法能够配合现在和将来的业务发展情况。5.1.3 方法的选择综上所述，分析和设计方法应当具有如下特点： 方法足够成熟

57、，参加开发的人员能够迅速熟悉和掌握； 应当能够保证分析和设计的结果应当具有足够的灵活性和可扩充性； 应当能够保证分析和设计的结果易于实现； 应当保证分析和设计的结果能够适用于不同的编程方法和编程工具，例如面向对象的编程和结构化编程，第三代和第四代编程语言等等； 应当保证分析和设计的结果能够适用于不同的系统结构，如集中式系统、分布式系统、各种客户/服务器系统等等； 反映计费系统的本质和特点，使系统在适应需求变化的情况下有足够的稳定性； 应当保证按本设计生成的系统具有可测试性； 应当保证开发全过程的平稳，尽量减少不同阶段间的转换。目前广泛采用的分析和设计方法主要有两种，即结构化方法和面向对象的方法。在对数据的描述方面，主要有关系方法和面向对象的方法。分析、设计和实现三个阶段可以采用同一种方法，也可以采用不同的方法。从以上要求来看，虽然面向对象的方法在许多方面比结构化方法优越，但由于面向对象的数据库产品的应用尚不广泛。如果完全采用面向对象的方法进行分析，在其后的设计中，需要进行数据模型的转换，难度较高。加之参与开发的大多数人员对结构化和关系方法比较熟悉，因此，设计组决定主要采用结构化方法和关系方法进行分析。5.2 分析方法和分析步骤在分析阶段，设计组进行了与规范v1.0设计组类似的几方面工作： 整