C++在大型工程项目中的应用 入门与提高 刘加权 Liu.Jiaquan

目录 C++快速入门 数据与应用的分布式解决方案 批价与资费计划 RuleCache相关功能实现

活动图和状态图的区别：  活动图侧重从行为的动作来描述 状态图侧重从行为的结果来描述

OCU主机应用部署

在线计费进程树 In-Memory Charging Rules In-Memory Session NE Web PCRF OLC SMS NE Web PCRF RecvAocMessage Mem AOC DealAocMessage OLC DBOperator SQL OCPro OCDis OCPCdrGen OCPro CDR Tm CDR RuleCache CdrGen_Reclaim CdrFileSplit In-Memory Charging Rules dereEvtIndb RuleMgr CDR SortTest PyScriptTry Database CC&RB BatchPreRealBilling PCdrInDB RecurrRefund Operator OODis PreRealBilling CDR FileRefund OCCreditCtrl PcrfSessionRecycle DealTop AbnFileRefund SpDealSNR In-Memory Session SyPro SyDis ABN CDR SyDealSNR AbnSession

目录 在线计费系统整体架构 数据与应用的分布式解决方案 批价与资费计划 RuleCache相关功能实现

OLC81路由分发 OLC提供两种分布式分发的路由方式： //route.ini文件 RoutAccess = 5或6 5： 只支持号码、按路由表分发； 6： 支持号码、IMSI号码，根据SUBS_IDENTIFY分发。 此方式时，QMDB OLC中的SUBS_IDENTIFY表使用QDG方式 加载。

5：

6：

全分布式部署选项 OLC 典型项目：越南iCS Rating App Server Rating App Rating App Server QDG Client In-Memory User Profiles Bal Agent User Balance Rating App Server Rating App QDG Client In-Memory User Profiles Bal Agent User Balance Billing App Server Billing App QDG Client User Profiles Acct Item DataBase Server CC RB QDG Master Slave DataBase Server CC RB QDG Slave Master 1 2 B 1 2 B

全分布式Active-Active部署选项 OLC Rating App Server Rating App Server Billing App Server Billing App QDG Client User Profiles Acct Item Billing App Server Billing App QDG Client User Profiles Acct Item Rating App Bal Agent Rating App Bal Agent Real-time replication User Profiles User Balance User Balance User Profiles User Balance User Balance QDG Client QDG Client DataBase Server CC RB QDG Master Slave DataBase Server CC RB QDG Slave Master

目录 在线计费系统整体架构 数据与应用的分布式解决方案 批价与资费计划 RuleCache相关功能实现

目录 在线计费系统整体架构 数据与应用的分布式解决方案 批价与资费计划 RuleCache相关功能实现

计费系统中的缓存机制

RuleCache提升-优点 减少内存占用 进程启动加快 通过不同排序规则索引提供多种接口，提高查找效率 时段费率数据：处理时展开前后1到2天的数据 改造前 改造后TT版本 改造后QMDB版本 OCPro 1112M 119 M 374 M RuleCache 369M 1264.21M 1264.21M TT版本和QMDB的差异是有Query的差异， 872KB VS 60KB

RuleCache提升-架构对比 Rule Cache Share Memory OCPro Rule Data Data Relation

如何写好文档？ 定位目标读者，了解读者需要的是什么。 文档都有其适用的读者，侧重的内容，不能指望一本文档适用所有场合。 我自己明白正在写的这段话的内容吗？ 理清思路、合理架构、简单表达 读者是否容易看懂？翻译是否可以无障碍地翻译？ 换位思考，把自己定位为读者，看看读起来是否轻松。 写作时考虑文档的用词和语句表达是否会造成翻译障碍，尽量用简单通俗的语句表达。

如何写好文档？ 文不如图，图不如表： 表达多个因素的关系、流程，图形的作用比纯文字有效得多。 文档中的概念关系、业务流程、配置流程尽量采用图形进行描述。 表达有关联的数据或者事实，表格的作用比纯文字有效得多。 文档中的相关数据或者事实，尽量采用表格进行描述。 文档规范在上述问题上可以助你一臂之力！

目录 为什么需要文档规范？ 什么是文档规范？ 如何应用文档规范？

文档规范的用户和目的 用户： 文档工程师 涉及写作的同事 目的： 指导大家如何编写高质量的技术文档。 提升工作效率。 Note： 本规范不对市场宣传类文档做要求。

文档规范有哪些内容 后续会增加“词汇辨析”一节，帮助大家分辨一些易混淆的词汇。

我们目前的文档现状 通篇都是密密麻麻的的文字，让人没有看下去的欲望。

我们目前的文档现状 通篇都是密密麻麻的的文字，让人没有看下去的欲望。

写作案例1 原文： 连词太多！ 修改后：

写作案例1 点评： 红框： “首先…、然后…、再然后…、最后….”直接转换为有序列表。 蓝框： 有些词语在句中没有实际意义，但往往习惯性夹带，该类词慎重使用，例如信息、支持、主要、可以、就、到、了、对于、关于、这时。 技术文档写作中，段落开头无需空格。

写作案例2 原文： 各参数项内容混在一起，不能让读者直观看到各参数项的解释。

写作案例2 修改后： 一系列相关的数据采用表格：便于后期维护、阅读时清晰度高。 表格中的参数顺序与正文中参数顺序保持一致，方便读者前后对比。 提示类文字转变为Note。

目录 为什么需要文档规范？ 什么是文档规范？ 如何应用文档规范？

文档规范的重点内容

第1章 技术文档标准 以实例形式告知读者，什么样的文档是符合技术文档标准的好文档，什么样的文 档能让读者拥有优秀的用户体验。 第1章 技术文档标准 以实例形式告知读者，什么样的文档是符合技术文档标准的好文档，什么样的文 档能让读者拥有优秀的用户体验。 本次培训介绍的文档标准包括： 清晰性：内容和表达方式简单易懂，读者快速理解所要表达的信息。 可读性：包含合适的例子、应用场景、图示、表格、列表等。 易检索性：很多时候并不是缺少信息，而是读者无法找到他们想要的内容。

第1章 技术文档标准——清晰性 修改前： 计算费用包括以下三类：计算周期费用、计算使用费、计算业务提供费。关于它们的详细含义请对应着黑线上的蓝字查阅椭圆形中的蓝字。 计算使用费包括两类，计算业务提供费包括四类。关于它们的详细含义请在同一椭圆中对应着黑线的黑色的数字查阅相同数字归属的较大矩形中淡紫色部分的黑字。 原文的表达方式较复杂，语句拗口，内容不够清晰。

第1章 技术文档标准——清晰性 修改后： 计算费用包括以下三类：计算周期费用、计算使用费和计算业务提供费。 第1章 技术文档标准——清晰性 修改后： 计算费用包括以下三类：计算周期费用、计算使用费和计算业务提供费。 详细含义参见椭圆中的紫色字体内容。 计算使用费包括两类，计算业务提供费包括四类。 详细含义参见各自椭圆的矩形框中黑色字体内容。 修改后的语言，言简意赅，便于理解和翻译。

第1章 技术文档标准——可读性 修改前： 南向接口服务于能力提供方即电信运营商与第三方（合作伙伴）。采用分布式设 置，一方面汇聚电信运营商能力，另一方面方便第三方能力更加灵活的挂载 至ZSmart API管理平台。运营商能力包含IT运营能力、认证能力、SMS能力、 MMS能力、用户资料查询能力、数据能力、支付能力以及QoS能力。API hub的 南向接口可以根据对接的不同业务采用多样化的接口协议，例如SMS业务采用 SMPP协议，MMS采用MM7协议，Authentication采用OAUTH2协议。 User profile、QoS、payment、IT Capability、data通常采用Web Service协议 与cvBS系统对接。ZSmart API管理系统包含3大功能模块： partner management、API hub和settlement。 所有内容堆砌在一个段落中。

第1章 技术文档标准——可读性 修改后： 每个段落只有一个中心思想。

第1章 技术文档标准——易检索性 修改前： 参考信息： CdrGenWrap.log 第1章 技术文档标准——易检索性 修改前： 参考信息： CdrGenWrap.log module.scr OCDis.log RuleCache.log system_param.ini win_mgt.scr 参考信息虽然按照字母顺序组织，但是将“日志文件”和“配置文件”2类参考信息混在一起，不便于用户查找。

第1章 技术文档标准——易检索性 修改后： 按照“日志文件”和“配置文件”进行归类描述，文档内容“一目了然”。 参考信息： 日志文件 第1章 技术文档标准——易检索性 修改后： 按照“日志文件”和“配置文件”进行归类描述，文档内容“一目了然”。 Tip：把关键字“日志文件”和“配置文件”暴露在文档中，便于读者搜索关键字时查询对应内容。 参考信息： 日志文件 CdrGenWrap.log OCDis.log RuleCache.log 配置文件 module.scr system_param.ini win_mgt.scr

第2章 文档组成元素 本次培训介绍的文档组成元素包括： 标题是指能够表明章节内容的简短语句。 词汇是指文档中所有词和固定短语的总和。 第2章 文档组成元素 本次培训介绍的文档组成元素包括： 标题是指能够表明章节内容的简短语句。 词汇是指文档中所有词和固定短语的总和。 句子以句号为结尾。句号表示句子已完成。 列表可以很好的展现相似信息，使文档组织更有条理、重点更突出。 段落是主题信息块的基本构成单元之一，由多个句子构成。 表格用来展示一系列相关的数据或事实，以表格形式展示内容，使表达的内容更简洁、更清晰。

第2章 文档组成元素——标题 常用标题写法： 名词词组：概述、账户余额类型 动词+主题词：配置订户事件 Note： 第2章 文档组成元素——标题 常用标题写法： 名词词组：概述、账户余额类型 动词+主题词：配置订户事件 Note： 同一篇文档的章节命名风格要统一，同一级标题建议用一种结构表达。 尽量避免使用3级以上标题。对于4级标题等，考虑使用列表等其他格式取而代之。

第2章 文档组成元素——词汇 错误案例： 呼叫转移（前转）是一种应用广泛的新业务，为了方便起见，它不但可以在用户话 第2章 文档组成元素——词汇 错误案例： 呼叫转移（前转）是一种应用广泛的新业务，为了方便起见，它不但可以在用户话 机上通过拨号登记和撤销，也可以在后台维护系统中通过人机命令直接进行，后者 的优点是可以由局方大批量集中维护。 正确案例： 呼叫转移（前转）是一种新业务。该业务有两种登记/撤销方法： 在用户话机上通过拨号登记/撤销。 大批量集中维护时，在后台维护系统中，通过人机命令登记/撤销。

第2章 文档组成元素——词汇 点评： 禁止滥用或误用代词“它” 和“it”。 “它” 和“it”经常指代不清，容易引起概念的误解或混淆。 第2章 文档组成元素——词汇 点评： 禁止滥用或误用代词“它” 和“it”。 “它” 和“it”经常指代不清，容易引起概念的误解或混淆。 该案例中，“它”建议改为“该业务”。 维护阶段的文档，“销售性”的语句不再必要，例如“灵活的”、“先进的”。 错误案例中应去掉“应用广泛”、“为了方便起见”、“后者的优点是可 以由局方大批量集中维护”等语句。 “不但可以……也可以…….”转变为无序列表。 避免“前者”、“后者”、“the former”、“the latter”等词，使用完整称呼。 当文档内容较多时，“前者”、“后者”、“the former”、“the latter”的指代方式容易引起混淆，造成误解，请给出完整称呼。

第2章 文档组成元素——词汇 记录合作伙伴所在行业信息，例如制造业、食品类、互联网类。 Steps 第2章 文档组成元素——词汇 记录合作伙伴所在行业信息，例如制造业、食品类、互联网类。 Steps 在［Partner Industry］页面，单击<New>新增合作伙伴行业信息，输入合作伙伴所在的行业名称，例如“Internet”。 Note：有些词语在句中没有实际意义，但往往习惯性夹带，该类词慎重使用，例如信息、支持、主要、可以、就、到、了、对于、关于、这时。

第2章 文档组成元素——句子 句子的写作要求： 使用简单句和并列句，避免使用复杂句。 简单句是指采用主谓宾清晰的句式结构。 第2章 文档组成元素——句子 句子的写作要求： 使用简单句和并列句，避免使用复杂句。 简单句是指采用主谓宾清晰的句式结构。 复杂句型多半带有一定的感情色彩，会产生理解歧义，不建议使用。 复杂句型的常见模式是带有很多的修饰成分（定语、状语等），句子结构不清晰， 无法快速定位句子的主谓宾。

第2章 文档组成元素——段落 段落的写作要求： 段落开头无需空格。 1个段落只能有1个主题，或1个中心句子。 每段控制在51行以内。 第2章 文档组成元素——段落 段落的写作要求： 段落开头无需空格。 1个段落只能有1个主题，或1个中心句子。 每段控制在51行以内。 段落的中心句子放在句首，以便读者读完段落首句即可把握段落的中心内容。 首句对全段内容进行概括。后续陈述的句子作为说明、展开、论据等为中心句 子服务。 Note：“每段控制在51行以内”不是要求内容必须在51行之内编写完成，而是把内容分段，或者改变内容的表达形式。

第2章 文档组成元素——句子和段落 修改前： 用户在指定时间周期内消费超过一定的限额，限额分为运营商根据用户的特性设 定（系统限额）和用户自己设定（用户限额）。运营商设定的限额可以进行欺诈 预防，用户设定可以对消费行为进行提醒以避免透支。系统目前只支持运营商设定 限额。 用户在指定时间周期内消费超过一定的限额，运营商根据用户的特性设定限额。运 营商可以通过ZSmart的高额告警模块设定多种类型的高额告警规则，对应阀值及对 应的限额动作。然后系统对发生高额事件的用户根据最初的设定采取相应的限额动 作。另一方面系统提供多种过滤条件便于你查询用户的高额告警计录。 阅读这样的段落，是不是感觉读第一遍的时候段落的中心思想不突出？

第2章 文档组成元素——句子和段落 修改后： 用户在指定周期内的消费限额分为系统限额和用户限额。 系统限额：由运营商根据用户特性而设定。 第2章 文档组成元素——句子和段落 修改后： 用户在指定周期内的消费限额分为系统限额和用户限额。 系统限额：由运营商根据用户特性而设定。 用户限额：由用户自行设定。 系统限额可以预防欺诈，用户限额则提醒合理消费、避免透支。目前仅支持系统限额。 运营商在ZSmart的高额告警模块设定高额告警规则：阀值和限额动作。 ZSmart根据阀值对发生高额告警的用户采取限额动作。 ZSmart提供多种过滤条件，方便用户查询高额告警记录。 修改之后，段落的中心思想一目了然，可快速定位主谓宾！

第2章 文档组成元素——列表 有序列表用于描述一系列有顺序关系的列表项。 无序列表用于描述一系列并列关系的列表项。 第2章 文档组成元素——列表 有序列表用于描述一系列有顺序关系的列表项。 修改订户限制类型： 1.选择一条订户限制类型记录。 2.单击<编辑>，根据实际需要，修改详情信息。 3.单击<确定>，保存修改信息。 无序列表用于描述一系列并列关系的列表项。 OCS（OCS-Online Charging System，在线计费系统）支持实时合账与批量合账。 实时合账是在实时计费时，对用户总账进行实时累计。实时计费又称联机计费。 批量合账是一个账务周期批量处理一次。批量合账又称脱机合账。

第2章 文档组成元素——列表 修改前： 批价包括用户资料的查找，与用户资料对应的资费计划的查找，费率计划的查找， 资费的查找及资费的计算。该过程通过话单数据查找用户资料；查找用户资料对应 的资费计划；查找费率计划；通过费率计划查找资费过程；然后计算资费。 该段有2个中心思想：批价内容和批价过程。

第2章 文档组成元素——列表 修改后： 批价是查找资费和计算费用的过程。 批价包括如下内容。 分段后，每段一个中心思想。 第2章 文档组成元素——列表 修改后： 批价是查找资费和计算费用的过程。 批价包括如下内容。 用户资料的查找 与用户资料对应的资费计划的查找 费率计划的查找 资费的查找 资费的计算 批价过程，如下所示。 通过话单数据查找用户资料。 查找用户资料对应的资费计划。 查找费率计划。 通过费率计划查找资费过程。 计算资费。 分段后，每段一个中心思想。 根据内容的无序和有序关系，分别采用无序列表和有序列表进行表达。

第2章 文档组成元素——表格 表格由表名、标题行、内容行、单元格、表注组成。

第2章 文档组成元素——表格 原文： 各参数项内容混在一起，不能让读者一目了然看到各参数项的解释。

第2章 文档组成元素——表格 修改后： 一系列相关的数据、或者某一内容的分类采用表格进行描述。 第2章 文档组成元素——表格 修改后： 一系列相关的数据、或者某一内容的分类采用表格进行描述。 表格中的参数顺序与正文中参数顺序保持一致，方便读者前后对比。

第3章 行文规范——大小写规则 大小写规则是指英文文档中需要使用大写字母的情况。 大小写应用有两种场景。 第3章 行文规范——大小写规则 大小写规则是指英文文档中需要使用大写字母的情况。 大小写应用有两种场景。 标题大小写（Title Capitalization） 句子大小写（Sentence Capitalization） 标题大小写的适用场景： 文档名、文档类型（例如，Product Description）、章节标题、图名、表名、 表格的标题行、缩略语的全称。

第3章 行文规范——大小写规则 标题中需要首字母大写的单词： 介词和冠词无需首字母大写，除非位于标题的首个或最后一个单词。 第3章 行文规范——大小写规则 标题中需要首字母大写的单词： 介词和冠词无需首字母大写，除非位于标题的首个或最后一个单词。 首个单词、最后一个单词。 实词类：名词、代词、形容词、动词、副词。 复合词中的实词：复合词中除开冠词、介词或并列连词（a word such as “and” or “but” that joins two parts of a sentence that are of equal importance）以外的其他单词。 标题中无需首字母大写的单词： 虚词类：冠词、介词、并列连词。 动词不定式中的to（不定式to其后的动词需要首字母大写，例如to Connect。）。

第3章 行文规范——大小写规则 句子大小写的适用场景： 正文中的句子、表格单元格中的句子、图形中的句子和列表中的句子。 第3章 行文规范——大小写规则 句子大小写的适用场景： 正文中的句子、表格单元格中的句子、图形中的句子和列表中的句子。 句子需要首字母大写的情况： 正文中句子、单元格中句子、图形中句子、列表中句子：第一个单词的首字母大写，其他小写。 专有名词或缩略语除外。

第3章 行文规范——人称 人称在技术文档中的使用规则： 第一人称（在技术文档中不建议使用） 第二人称（在操作类文档中使用） 第3章 行文规范——人称 人称在技术文档中的使用规则： 第一人称（在技术文档中不建议使用） 第二人称（在操作类文档中使用） 第三人称（在描述性的技术文档中使用） Note：不能使用带有性别特征的第三人称代词，例如他、她、他的、她的。 使用定冠词“the”，或以第二人称you、复数形式重新改写句子。 【修改前】 A user can change his default settings. 【修改后】 A user can change the default settings. You can change the default settings. 

第3章 行文规范——语态和动词时态 语态： 技术文档中尽可能使用主动语态（Active Voice），直接说明某人或某物执行某个动作。 第3章 行文规范——语态和动词时态 语态： 技术文档中尽可能使用主动语态（Active Voice），直接说明某人或某物执行某个动作。 技术文档中尽量避免使用被动语态（Passive Voice）。 例外：需要避免冗词或繁琐文字结构，或主语未知，或主语不是句子的重要内 容时。 【举例】主语未知的情况： Status reports are produced daily. 动词时态： 技术文档中使用一般现在时陈述内容和描述步骤。因为一般现在时态比过去时和将来时易读。

第5章 文档结构——缩略语 文档第一次出现的缩略语，必须对缩略语展开进行解释。 以下情况例外： 章节标题中的缩略语。 图名和表名中的缩略语。 第5章 文档结构——缩略语 文档第一次出现的缩略语，必须对缩略语展开进行解释。 以下情况例外： 章节标题中的缩略语。 图名和表名中的缩略语。 表格标题行中的缩略语。 对于一些约定的速率、接口标准、单位等，无需对缩略语进行解释，例如SMS、IBM、CPU。 全文对于缩略语使用应统一。

第8章 文档结构——缩略语 以下情况下，避免使用缩略语而尽可能使用全称。 对于业界不常使用的缩略语，尽可能地使用全称而不使用缩略语。 第8章 文档结构——缩略语 以下情况下，避免使用缩略语而尽可能使用全称。 对于业界不常使用的缩略语，尽可能地使用全称而不使用缩略语。 同一节中存在同一个缩略语有多个含义，例如FE表示Front End和Fast Ethernet。 缩略语的含义与目标用户所熟知的含义不同，且使用的场合容易造成误解。例如IP作为“智能网外设”时的缩写。 文档中极少出现。 缩略语的大小写必须准确，例如OCS、cvBS、eTOM、iCS。

Q1 表程度、强调的语气副词是否需要？ 技术类文档避免使用模糊 表示程度、强度语气的词。 中文 英文 绝对地 absolutely 事实上 actually 大约地 approximately 基本上 basically 当然 certainly 完全地、彻底地 completely 决定性地 definitively 本质上地、根本地 essentially 非常地 extremely 通常地 generally 在很大程度上地 hugely 刚好地、正好地 just 主要地 mainly 最低程度地 minimally 显然地 obviously 特别是、尤其 particularly 或许 perhaps 相当 pretty quite 显着地、重大地 significantly （强调简单）仅仅，只，不过 simply 稍微、有些 somewhat 强烈地 strongly 非常 very 事实上、实际上 virtually 技术类文档避免使用模糊 表示程度、强度语气的词。

Q1 表程度、强调的语气副词是否需要？ 不需要！ 这类副词的存在没有实际意义，可尝试把这类副词删除，看看是否对原文意思造成影响。 修改前： 出账实际上是形成用户账单数据的过程。 修改后： 出账是形成用户账单数据的过程。 这类副词的存在会造成歧义： 例如，通常情况下，XXX。那读者会有疑问，“非通常”情况又是如何呢？ 所以，直接去掉这类词汇。如果存在“非通常”情况，另外加个Note说明即可。

Q2 “尽量”在规范中的含义 规范中的某些要求，不是“刚性”要求，只能给出“建议”的方法。 例如，“尽量”避免使用单一的段落表达方式。 对于“标题中不带标点符号，不解释缩略语”、“标题不能换行”这样的“刚性”要求，我们不使用“尽量”。 是否有“尽量”即是： “建议”如何操作和“必须”如何操作的区别。 建议是optional，而必须是mandatory。

Q3 账 or 帐？ 合帐处理指的是把对于用户使用费用、周期性费用及一次性费用（订购费）的计费 结果中相同的帐目进行合并。它是针对同一帐户在同一帐务周期内的同一帐目类型 做的合并。这个过程是累计费用的过程，也是累计积分量的过程。合帐时也要将出 帐前调帐的费用合进去。 OCS支持实时合帐与批量合帐。实时合帐就是在实时计费的时候就对用户的总帐进 行实时的累计，批量合帐是一个帐务周期批量处理一次。实时计费我们以前又叫做 联机计费，所以批量合帐也被称为脱机合帐。 账 or 帐？

Q3 账 or 帐？ 帐： 用布或其他材料等做成的遮蔽用的东西：帐子、帐幕、帐篷、蚊帐、青纱帐。 同“账”。 账： 关于货币、货物出入的记载：～本、～簿、～号。 指“账簿”：一本～。 债：～主。欠～。还（huán ）～。

Q3 账 or 帐？ 《现代汉语词典》（2002年增补本）只有“账户”词条，而无“帐户”词条，对“账户”的解释是：会计上指账簿中对各种资金运用、来源和周转过程等设置的分类。 经国家语委等修改而成的《图书编校质量差错认定细则》中的第七条列举了“常见的较难界定的别字”，其中有“欠账（帐）、账（帐）簿”等，并特别说明“括号里的字是错的”。 新华社2002年印发的《新华社采编人员手册》“新闻报道中容易用错的字词”这部分内容中，也明确说明，表示“财物出入的记载”和“债”的义项时，不能写作“帐”。 财务 账本，应该一致！ So… 我们的技术文档里面统一用“账”！ Q4：不能随便在字典里查某字或某词有某种含义，就直接放在技术文档中使用，而应该选择对应该意义的常用词！

Thank you