中国移动业务运营业务支撑系统（BOSS）概要设计书－总体设计

1、南京联创系统集成股份有限公司 总体设计概要设计书中国移动业务运营业务支撑系统（boss）概要设计书总体设计版本号： 3.0密级：机密编写： 年月日审核： 年月日批准： 年月日联创科技目 录1.引言31.1软件名称31.2文档说明31.3文档密级31.4参考资料32.概述32.1系统概述32.1.1设计目标32.1.2实现功能42.1.3设计约定52.2系统总体结构52.2.1系统总体设计结构52.2.2系统总体软件结构72.2.3系统运行平台结构122.2.4应用程序结构153.规范与规则153.1编程工具153.1.1工具说明153.1.2编码规范163.2文件命名规范163.2.1pl/s

2、ql源文件命名规范163.2.2应用层文件命名规范163.2.3终端层开发文件命名规范173.2.4终端层运行文件命名规范203.3文件结构规范213.3.1域定义文件结构规范213.3.2组件配置文件结构规范213.3.3终端日志文件结构规范223.3.4终端配置文件结构规范233.3.5tuxedo交易终端调试文件243.3.6应用层日志文件结构规范243.3.7应用层调试文件结构规范244.系统实体模型分析254.1基本实体模型254.2基本实体定义254.3基本实体关系275.系统可靠性设计285.1硬件可靠性285.2软件可靠性286.系统安全性设计286.1操作系统安全286.2应

3、用管理安全296.3应用软件安全296.4数据库管理安全291. 引言1.1 软件名称1.2 文档说明1.3 文档密级1.4 参考资料 boss业务规范 boss系统技术规范 移动boss系统需求规格书营收管理v1_0 移动boss系统需求规格书查询统计v1_0 移动boss系统需求规格书帐务管理v1_0 移动boss系统需求规格书资源管理v1_0 移动boss系统需求规格书辅助管理v1_0 移动boss系统需求规格书代理商管理v1_0 移动boss系统需求规格书增补需求汇编1v1_0 移动boss系统需求规格书移动计费（漫游）v1_0 移动boss系统需求规格书移动计费（数据）v1_0 移动

4、boss系统需求规格书移动计费（语音）v1_0 移动boss系统需求规格书移动计费（语音）附件3_预处理校验规则 移动boss系统需求规格书移动计费（语音）附件4_字段检验标准 移动boss系统需求规格书移动计费（语音）附件6_统计要素 移动boss系统需求规格书移动计费v1_0 移动boss系统需求规格书联机指令v1_0 移动boss系统需求规格书数据采集v1_02. 概述2.1 系统概述2.1.1 设计目标本3g系统充分考虑中国移动的boss系统规范要求，建设成为多业务综合营业与综合帐务体系，实现客户服务“一台清”、“一单清”，为客户提供良好服务；实现综合业务的帐务交叉优惠，提高服务水平和

5、市场竞争能力，为发挥综合业务优势提供条件；形成跨业务的综合用户资料，为综合数据分析与决策支持打下基础，以便为业务单元提供良好支撑；实现综合营帐系统一致的体系结构，便于管理维护，提高效率。另外系统的良好设计，适应快速发展的新业务和新优惠的实现，为从事移动业务的运营商在激烈的竞争中获取创造条件。2.1.2 实现功能从中国移动的角度出发，3g系统要实现的功能主要包括（不考虑计费）： 综合营业：所有的业务办理，包括普通gsm业务，神州行业务，165上网业务和193长途业务等等，在综合营业中间，又包括统一客户资料管理和统一资源管理。 信用管理：高额控制，防欺诈和欠费管理。 综合帐务：不管帐务的数据来源如

6、何，统一出帐，统一帐务处理。 缴费服务：多业务融合的统一缴费。 综合接口：分为内部接口和外部接口。中国移动在具体实现时，将系统划分为几个独立的模块，包括综合营业，综合帐务，综合缴费和信用管理，这几个独立模块之间的接口，称之为内部接口；与计费系统的接口，与客服的接口，与其他外接系统的接口等等，都统称为外部接口。从中国移动的角度出发，3g系统要实现的功能主要包括（不考虑计费）： 帐务处理和管理：主要完成帐务的综合处理以及帐务相关的管理，如销帐与反销帐，欠费管理，帐单定制等等，类似于移动的综合帐务。 客户服务：包括所有的用户业务办理，用户缴费、查询等等，它包含了移动的综合业务部分（剔除资料管理和资源

7、管理）和移动的综合缴费。 业务管理：包括所有的资源管理，客户管理，信用控制和资费管理等，它包含了移动的综合业务部分和信用控制。 统一接入：中国移动将内部接口都认为是系统之间的数据交换，而外部接口则通过统一接入平台解决。两种功能的划分方法要实现的功能的目标是一致的，只是划分的角度有所不同，3g系统既要适合中国移动的业务开办，又要适合中国移动的业务开办，所以综合两种功能划分的优缺点，将系统划分为五大功能，每个功能又通过各个子系统来实现，关于系统整个的软件结构的详细内容参见下面章节的描述。1 帐务服务子系统：完成所有的帐务处理和帐务管理。2 客户服务子系统：完成所有的业务办理，缴费和业务查询。3 业

8、务管理子系统：完成所有的资源管理，客户资料管理，大客户等管理，信用控制在客户管理中实现。4 系统管理子系统：完成系统安全，监控，版本控制和数据库的管理。同时系统的综合接口在该子系统中实现。5 统计决策子系统：完成数据的统计和分析，为营销决策提供依据。2.1.3 设计约定本系统的设计主要基于以下假定和约束：l 业务模式：本次设计采用全省集中的模式，在地州不设数据库，各地州的营业终端通过中间件于省中心唯一的数据库连接。l 中间件：中间件均以tuxedo作为中间件平台，所有关于中间件的设计都是从实现tuxedo的最佳效能出发。l 营业终端：以普通pc机为主，采用中文windows平台和图形化用户界面

9、，方便营业员使用。l 数据库：以8。1。6以上版本的oracle数据库为主。l 可靠性：主要通过采用双主机热备份的主机平台，来达到系统的高可靠性要求；同时应用软件具有一定的障碍处理和异常恢复能力。l 安全性：安全系统由系统管理员对系统进行实时监控，特别是网络设计中要设置防火墙；同时软件部分提供严密的操作权限控制和安全管理措施。l 可管理性：软件设计尽量采用参数化设计，使系统能够便于随着主要业务需求的变化作出相应的调整。2.2 系统总体结构2.2.1 系统总体设计结构客户，包括普通客户和银行邮政等客户在内，他们面对的是一个统一的客户服务层，由客户服务层提供完备的客户服务，客户服务层的通过业务支撑

10、层来具体实现，业务支撑层在实现过程中，会使用到一系列的资源性的数据，同时要通过统一的网关对网元设备进行操作，这个工作由资源层来完成。在接入平台，界面逻辑的构成，为客户或设备提供多样化的接入；在业务平台，通过对服务子层原子服务的调用访问业务数据，实现不同的功能模块，以满足不同的业务需求。业务平台由业务函数和业务过程组成；在数据平台，实现系统数据的统一存储、组织、集中管理和共享，并对业务平台提供规范、高效的基本数据操作。数据平台分为数据子层和服务子层。2.2.2 系统总体软件结构boss系统和综合营帐系统由五大系统组成，每个系统又划分为若干子系统，每个子系统又有若干功能，参见下表：帐务服务系统ac

11、countservice（as）帐务处理accountserviceprocess（asp）出帐aspbc（billcomputer）帐务管理accountservicemanager（asm）销帐asmbc（billclear）调帐asmba（billadjust）对帐asmbk（billcheck）结算asmbb（billbalance）欠费管理asmobm（owebillmanager）呆坏帐管理asmdbm（deadbillmanager）帐单打印asmbps（billprintservice）帐单寄送asmbss（billsenderservice）帐单查询asmbqs（billqu

12、eryservice）统计归纳asmbs（billstatistic）客户服务系统customerservice（cs）业务受理customerservicebusiness（csb）开户csb服务类型uri（userregisterin）如csbgsmrui退网csb服务类型uro（userregisterout）变更csb服务类型【业务说明】如csbgsmcun（changeusername）缴费customerservicefee（csf）缴费csfgf（getfee）调帐csfaf（adjustfee）清退csfgm（givemoney）转帐csftm（transfermoney）滞纳

13、金csflf（latefee）其他csfofp（otherfeeprocess）查询customerservicequery（csq）用户查询csqc（customer）员工查询csqe（employee）用户投诉customerserviecothers（cso）用户建议终端维修信息发布移动商务业务管理系统businessmanager（bm）资源管理businessmanagerresource（bmr）卡资源管理businessresourcesimcard（brs）号资源管理businessresourcenumber（brn）票据资源管理businessresourceinvoice

14、（bri）充值卡管理businessresourcecard（brc）终端配件管理businessresourcedevice（brd）其他资源管理businessresourceothers（bro）资费管理businessmanagerfeerate（bmf）业务资费管理bmfb（business）帐务资费管理bmfa（account）套餐管理bmfp（policy）客户管理businessmanagergod（brg）大客户管理businessmanagerbiggod（bmb）集团用户管理businessmanagerspecialgroup（bms）代理商管理businessmana

15、geragent（bma）统计决策系统statisticanddecision（sd）系统管理系统systemmanger（sm）参数管理systemmanagerparameter（smp）系统定制smpsd（systemdefine）系统参数smps（system）业务参数smpb（business）帐务参数smpa（account）安全管理systemmanagersafe（sms）员工管理smse（employee）权限管理smsr（right）日志管理smsl（log）版本管理systemmanagerversion（smv）系统监控systemmanagermonitor（smm）

16、后台监控smmb（background）前台监控smmf（front）数据库监控smmd（database）数据库管理systemmanagerdatabase（smd）通过以上的说明，我们可以看出，整个系统是由众多子系统组成的，从逻辑上划分，可以按照上面原则进行，但为了版本管理（版本管理是基于子系统的）的方便，和员工使用的方便，引入独立子系统的概念。所谓独立子系统，指可以完成一组相对独立而且稳定的系统功能。独立子系统可以是五大系统中的一个，也可以是各子系统中的一个。举例来说，帐务服务子系统可以成为一个独立子系统，因为如果将帐务处理或帐务管理作为独立子系统，显然不能满足对整个帐务的管理；又比如

17、客户服务子系统，可以作为一个独立子系统，如果单独将缴费作为一个独立子系统，不能满足要求，因为缴费服务往往是与业务服务在一起的。在以后的文档说明中，凡没有特别说明的，提到的子系统，就认为是独立子系统。2.2.3 系统运行平台结构本系统运行的体系结构在原来两层client/server结构的客户端和数据库服务器之间增加了一个中间层-应用服务层，将业务逻辑从客户端挪到应用服务器端，从客户端上取消了业务和应用逻辑。应用程序集中放置在中间层即商用逻辑层上，由所有用户共享，当事务逻辑发生变化时，只需更新服务器上相应的应用程序组件，之后所有的客户就可以使用新的事务处理逻辑，避免了客户端应用程序版本控制和更新

18、的困难。客户端上只需安装具有用户界面和简单的数据处理功能的应用程序，它负责处理与用户的交互和与应用服务器的交互；应用服务器负责处理业务与应用逻辑，负责响应客户端的请求、实现和数据库服务器的连接、操作；数据库服务器软件根据应用服务器发送的请求进行数据库操作，并将操作结果传送给应用服务器。这样一来，客户端就不再和数据库建立连接了，仅负责显示用户界面和处理用户的输入输出，客户端把用户的请求送往应用服务器，由应用服务器从数据库服务器获取数据并进行计算，计算结果再返回客户端进行显示。具体处理流程描述：用户请求操作客户端响应客户端简单处理向应用服务器发送请求应用服务器接受客户端请求根据业务和应用逻辑，将这

19、个请求转化为数据库请求应用服务器向数据库服务器发送请求数据库服务器接收请求执行相应的处理操作将与数据库服务器交互的结果传送给客户端应用程序应用服务器根据业务和应用逻辑，将这个结果转化为客户端数据发送回客户端客户端简单处理转交给客户。这种三层结构在针对营业帐务系统有以下优势： 业务逻辑、商业规则集中，可很好地实现对多业务、多服务、多接入口的支持。三层模型中，程序中所包含的商业规则原则上不再分布在客户端及数据库端，而是集中在中间层。中间层可以安放在数据库主服务器同一局域网内的一台或多台服务器上。这样可达到对含有商业规则的关键运行程序的集中管理、维护，便于新业务、新服务的扩展。 减少数据库用户数，解

20、决大接入量问题。在“集中营业”的模式下，省计费中心将有大量的联机操作终端接入系统，若大量购买数据库用户数，将大幅度增加投资；若联机操作终端向数据库作具体操作前再建立数据库连接, 数据库用户数固然减少,但牺牲了操作响应时间。三层模型下，客户端不直接面对数据库操作，而是将操作请求信息包发送给中间层，再由中间层实施联机操作。由于同一时间下，同时发起操作的终端数不会太高，而中间层与数据库保持一定数量的常连接,故采用三层模型可以将数据库用户数减至联机操作终端的10% - 15%,操作响应时间仍能保持在较高指标上。 事务均衡，解决大联机事务处理量问题。若前台联机操作终端在某一时刻有超出数据库所能承受的联机

21、事务发生，则中间层将会自动进行联机事务调度、排队，以确保数据库不会因为大量联机事务的并发而造成效率大幅度下降。系统负荷分担，提高系统并发性，解决大数据量问题。因含有商业规则的运行程序可存放于不同于主数据库服务器的另一台或多台主机上，系统运行负荷得以分担。利用中间件的消息队列机制，可实现多进程对多队列的并发服务，提高系统并发能力。降低网络负担。客户端与应用服务器之间仅传送业务处理请求和执行结果及用户的输入信息，数据传输集中在应用服务器和数据库服务器之间，降低了网络负担，同时也增加了应用的分布手段。配合其他安全机制，提高安全控制。三层模型中，客户端不再直接面向数据库做insert、delete、u

22、pdate一类的关键操作，而是转交给中间层完成。所以，数据库对客户端至多只授以查询的权力，从而从应用层的角度降低系统安全隐患。客户端可采用不同的开发工具，满足多接口环境的需求。由于客户端向中间层发信息包，故在中间层应用不变的情况下，客户端可采用delphi、c+ builder、pb等不同种编程方式适应实现环境的需求。综合以上技术，在黑龙江移动营业帐务系统的设计中采用三层结构较采用二层结构具有高效率、可扩展性、高安全性、易维护性等突出优点。2.2.4 应用程序结构2.2.4.1 营业程序结构示意图应用程序在发布时，只发布一个主体程序和一组dll文件，主体程序调用dll中的功能。每个dll都会发

23、布一个权限功能列表，主体程序具有自己组装运行菜单的能力，当每个菜单被点击时，系统通过在数据库中维护的菜单项与权限功能的对应关系表，来获取具体应当执行的功能。2.2.4.2 权限编码的编码规定在系统中，一个权限编码对应一个具体的业务功能，为了权限编码能具体反应功能的内容，所以统一规定权限编码采用子系统编码有意义的英文说明的格式，如员工管理对应的权限编码可以定义为smsstaffmanage，代表属于安全管理子系统的员工信息管理。3. 规范与规则3.1 编程工具3.1.1 工具说明在3g系统中用到的编程工具主要是cbuilder5。0以上版本，unix c/c，pl/sql。3.1.2 编码规范本

24、次系统开发，使用下列编码规范：1）cbuilder编码规范2）c编码规范3）unix c编码规范4）pl/sql编码规范5）tuxedo应用服务层软件编写规范3.2 文件命名规范3.2.1 pl/sql源文件命名规范3.2.1.1 编译文件各子系统的编译文件命名格式：子系统编码_build。sql。整个系统的编译文件命名为：3g_build。sql。3.2.1.2 单个源文件单个源文件以存储过程或函数的名字命名。3.2.2 应用层文件命名规范3.2.2.1 源文件应用层所有相关文件名都以“tux”开头，具体如下： 中间件配置文件定义为：tux_ubb 中间件头文件定义为：tux_trade.h

25、 中间件与文件定义为：tux_fml 中间件公共函数文件名定义为：tux_pubfn 中间件总控服务程序文件名统一定义为：tuxcorl _子系统名称tuxcorl_as：帐务服务系统accountservice（as）总控进程tuxcorl _ca： 客户服务系统customerservice（cs）总控进程tuxcorl _bm：业务管理系统businessmanager（bm）总控进程tuxcorl _sd： 统计决策系统statisticanddecision（sd）总控进程tuxcorl _sm： 系统管理系统systemmanger（sm）总控进程tuxcorl _pub： 公共总

26、控进程（各个子系统都可能调用的服务，如某些参数查询）tuxcorl _other：其它总控进程 中间件非总控服务程序文件名统一定义为：tuxserv_子系统名称+英文说明tuxserv_as英文说明：帐务服务系统accountservice（as）tuxserv _cs英文说明：客户服务系统customerservice（cs）tuxserv _bm英文说明：业务管理系统businessmanager（bm）tuxserv _sd英文说明：统计决策系统statisticanddecision（sd）tuxserv _sm英文说明：系统管理系统systemmanger（sm）tuxserv _p

27、ub英文说明：公共服务进程（各个子系统都可能调用的服务，如某些参数查询）tuxserv _conv英文说明：会话进程tuxserv _other英文说明：其它执行进程3.2.2.2 日志文件应用层日志文件由中间件自动产生，文件名格式如下：ulog。年月日，年用两位表示，如ulog.101101表示2001-10-11的日志3.2.2.3 调试文件应用层的调试文件同样由中间件自动产生，文件格式如下：调试说明月日年。trc，年用四位表示，如xa_null10162001.trc表示2001-10-16产生的trace文件。3.2.3 终端层开发文件命名规范3.2.3.1 源文件文件名 =文件归属代

28、码 _服务类型含义缩写文件内容标识(单词首字母大写)文件归属代码定义（按适用范围由大到小依次排列）： pub：公用文件（如：公用基类文件） 子系统编码：适用于整个子系统的文件 子系统编码 一级子系统操作代码 子系统编码 二级子系统操作代码 按子系统类型及子系统编码子系统操作代码做基本划分（红色字体为子系统一级操作代码，蓝色字体为子系统二级操作代码）：as：帐务服务系统accountservice asp：帐务处理（accountserviceprocess）asm：帐务管理（accountservicemanager）cs：客户服务系统customerservicecsb：普通业务受理（cus

29、tomerservicebusiness）csf：帐务费用缴费（customerservicefee）csq：查询（customerservicequery）cso：其它业务（customerserviecothers）bm：业务管理系统businessmanagerbmr：资源管理（businessmanagerresource） brs：卡资源管理（businessresourcesimcard） brn：号资源管理（businessresourcenumber） bri：票据资源管理（businessresourceinvoice） brc：充值卡管理（businessresourcec

30、ard） brd：终端配件管理（businessresourcedevice） bro：其他资源管理（businessresourceothers）bmf：资费管理（businessmanagerfeerate） bfb：业务资费管理（bmfb（business） bfa：帐务资费管理（bmfa（account） bfp：套餐管理（bmfp（policy）brg：客户管理（businessmanagergod）bmb：大客户管理（businessmanagerbiggod）bms：集团用户管理（businessmanagerspecialgroup）bma：代理商管理（businessmana

31、geragent）sd：统计决策系统statisticanddecisionsm：系统管理系统systemmangersmp：参数管理（systemmanagerparameter）sms：安全管理（systemmanagersafe）smv：版本管理（systemmanagerversion）smm：系统监控（systemmanagermonitor）smd：数据库管理（systemmanagerdatabase） 按服务类型划分（红色字体代表一级服务类型，蓝色字体代表二级服务类型）：移动服务：mobgsm服务：gsmcdma服务：cdm寻呼服务：bp193服务：193数字服务（上网）：ne

32、tip服务： ip其它服务：osv例如：移动业务中的普通开户业务程序文件命名为：csb_mobnormalopen说明：对程序中控件的命名规则采用前面定义的命名规则，对于窗体或对话框控件的标题要设置成其具体含义的中文名称。例如：gsm业务中的普通开户业务的form的caption应为：gsm普通开户3.2.3.2 dll文件文件名 =文件归属代码 _服务类型含义缩写dll+dll序号说明：文件归属编码、服务类型含义缩写参照源文件命名规则，dll序号为dll的划分序号将一组源程序编译在一个dll里为改dll取一个一位数的数字序号。例如：csb_mobdll1.dll csb_mobdll2.dl

33、l3.2.3.3 应用程序发布应用主程序统一命名为3g。exe。3.2.4 终端层运行文件命名规范3.2.4.1 域定义文件域定义文件指定名为：tux_fml。包含了所以tuxedo使用的fml域类型变量，在运行时刻需要使用。3.2.4.2 组件配置文件txd组件的配置文件扩展名为“.xml”，以交易来划分组件配置文件，一个交易使用一个组件配置文件，组件配置文件的主文件名就使用交易编码，大小写不限制。例如：接收通知的交易，交易编码为getstaffnotice，对应的txd组件配置文件的文件名位getstaffnotice.xml。3.2.4.3 终端日志文件终端日志文件的文件名按照以下的规则

34、进行命名：以天为单位创建不同的错误日志文件，主文件名为“err”+当天的日期字符串（格式为yyyymmdd），扩展名为“.log”。例如：2001-10-8产生的终端日志文件名为：err20011008.log。对于终端日志文件按照系统模块日志和业务模块日志分类两类，其日志文件分别存放在相应的目录中，如下表所示，其中为客户端程序的安装路径：目录说明logssystem客户端系统模块的日志logstrade客户端业务模块的日志例如2001-10-8系统模块产生的终端日志文件的全路径为：logssystem err20011008.log。3.2.4.4 终端配置文件每个终端系统运行时，使用一个配

35、置文件：3g_config。ini。3.2.4.5 终端临时文件文件名 =文件含义说明当天的日期字符串（格式为yyyymmdd）扩展名（根据需要确定）临时文件存放在目录： temp说明：临时文件原则上不做长期存放，当使用完毕后就将其删除。3.2.4.6 tuxedo交易终端调试文件文件名txd当天的日期字符串（格式为yyyymmdd）。log3.3 文件结构规范3.3.1 域定义文件结构规范。备注信息*base 。序号的基数字段名序号变量类型变量说明3.3.2 组件配置文件结构规范以下为test.xml配置文件的内容（中为解释，非实际内容）：配置文件根节点 开始一项服务的配置定义 servic

36、e1 服务名称，可多次定义，表示一次定义多个服务 synchronous 通讯方式：同步 fml 传输类型：fml 开始一个业务的定义 01业务编码，可多次定义，表示一次定义多个业务 02 03 开始定义输入 输入参数定义,参数列表开始 一个参数定义 age参数名称，可多次使用，表示一次定义多个 integer 参数类型：整数 开始定义输出 输出字段定义 一个字段定义 id 字段名称，可多次使用，表示一次定义多个 integer 字段类型：整数 name string 20 字符串类型字段最大长度 desc string 500 sign string 10 y 这是一个记录改变标记字段 关于

37、上述有关定义的可能取值如下：n 通讯方式communicate同步synchronous异步asynchronous会话sessionn 传输类型transfer目前只支持fmln 参数、字段数据类型type字符串 string 字符char整数short/int/integer/long浮点数float/double3.3.3 终端日志文件结构规范系统错误日志中一条记录的内容包括：记录开始行标记，操作员工编码，错误时间，错误发生处模块名称、函数名称（包括方法的类名称），错误时函数的输入参数名称、值列表（可选），引起错误的相关变量名称、值列表（可选），错误描述。错误记录之间用两个空行隔开。系统

38、错误日志文件的具体格式采用类似于ini文件的文本文件，每条错误记录作为一个logrec节，该节下记录本错误记录的相关数据。格式的具体形式描述如下（括号中为格式说明）：logrec 2001-10-8 13:01:23.123 （节名为logrec加上时间字符串）staffid=0100235（操作员工编码）time=2001-10-8 13:01:23.123（错误时间，格式为：yyyy-mm-dd hh:nn:ss.lll）module=operman.dll（模块名称）function=toperhistorysender:commitoperhistory（发生错误处带类名的函数名称）i

39、nputparams=int imaxrecord 200（输入参数类型、名称、值列表，多个参数用“;”隔开，可选）reasonvars=（引起错误的变量类型、名称、值列表，多个变量用“;”隔开，可选）desc=调用tuxedo服务提交操作历史记录时服务失败返回（错误描述）需要特别说明的是：以上输入参数列表、错误原因变量列表、错误描述文本，无论值字符串有多长，均不换行；文本中的换行和回车符分别被替换成“r”和“n”。另外，输入参数列表和错误原因变量列表作为可选项，可以为空。3.3.4 终端配置文件结构规范终端配置文件的结构采用传统的ini文件的结构，划分为以下几个重要的section： log

40、inparameter 登陆主程序相关本地配置参数： login：记录上次登录信息 option：记录应用程序配置信息 tuxedo：记录tuxedo的配置信息 update：记录备份配置信息 operman：记录操作监控信息 asparameter 帐务服务系统相关本地配置参数 csparameter 客户服务系统相关本地配置参数 bmparameter 业务管理系统相关本地配置参数 sdparameter 统计决策系统相关本地配置参数 smparameter 系统管理系统相关本地配置参数3.3.5 tuxedo交易终端调试文件调试文件的内容为：2001-11-19 19:51:20.970

41、 freecall()执行之前执行时间fml input buffer:输入域标题 fldname fldid occ type value = = = = =。fml output buffer:输出域标题 fldname fldid occ type value = = = = =3.3.6 应用层日志文件结构规范日志文件内容格式为：时间（时分秒）.主机名！进程名.程序员写入信息举例如下：152331.cjy!simpserv.936.1488.0: gtrid x0 x3bcb9cdb x24:参数存在152331.cjy!simpserv.936.1488.0: gtrid x0 x3

42、bcb9cdb x24:service in transaction!3.3.7 应用层调试文件结构规范调试文件内容格式：所调用的xa服务器；产生的时间等；oracle的错误信息举例如下：oracle xa: version 8.1.7.0.0. rm name = oracle_xa.100721.1276:1244.0:ora-01017: invalid username/password; logon denied4. 系统实体模型分析4.1 基本实体定义客户：享受服务的消费者或者潜在的消费者，在系统中主要维护的服务消费者，维护部分潜在的消费者，在满足一定条件后，潜在的客户会转换为真正的服务消费者。用户/服务：用户是服务的定购者，服务是移动公司提供的一系列服务。用户定购主体服务，所以用户与主体服务一一对应。一个主体服务可以附加一系列子服务。大客户：有一部分用户是较为特殊的用户群，他们的消费量大或使用的服务多，或者有特别的社会身份因而需要差别服务，系统将这部分用户定义为大客户，一个用户只能成为一个大客户。集团用户：出于营销的考虑，将一部分具有特殊特征用户群给予特别的服务和优惠，这部分用户群定义为集团用户。集团用户一般有诸如：使用vpmn服务，或者在某一小区或基站，或者同属于某个大型工地，或者有某种亲情关系等等的特征。帐户：为用户承担付费关