移动营销管理系统概要设计分析说明书模板

文档编号：
移动营销管理系统
概要设计说明书
文档变更记录
目录
1引言 (1)
1.1术语定义 (1)
1.2参考资料 (1)
1.3文档结构 (1)
2系统目标 (4)
2.1系统描述 (4)
2.2系统接口图 (System Context) (4)
2.2.1营业前端 (5)
2.2.2营销管理后台 (5)
2.2.3BOSS系统 (5)
2.2.4BOSS系统管理员 (6)
2.3系统功能性需求概述 (7)
2.4系统非功能性需求概述 (7)
2.4.1性能要求： (8)
2.4.2备份要求： (8)
3设计前提和假设 (9)
4系统核心模型 (10)
4.1营销方案配置概念模型 (10)
4.2营销资料概念模型 (10)
5系统架构设计 (11)
5.1总体架构设计 (11)
5.2硬件体系结构 (14)
5.3软件设计方法 (14)
5.4软件体系结构 (17)
5.5软件组件和应用设计 (22)
5.5.1软件组件设计 (22)
5.5.2告警采集应用设计 (31)
6数据库设计 (34)
6.1用户模式 (34)
6.2数据库表逻辑视图 (34)
6.2.1营销配置 (34)
6.2.2营销资料信息 (35)
6.2.3营销物品 (37)
6.2.4营销预警与提醒 (37)
6.2.5营销黑名单 (39)
7BOSS系统改造设计 (40)
7.1品牌互转相关功能改造 (40)
7.2专有帐户相关功能改造 (40)
7.3付款方式变更、申请销户、过户功能改造 (40)
7.4冷号回收功能改造 (40)
7.5查询功能改造 (40)
8系统出错处理设计 (42)
8.1出错处理总体原则 (42)
8.2后台服务进程出错处理 (42)
8.3数据库联接出错处理 (42)
8.4登录出错处理 (42)
9结论综述 (44)
9.1优势 (44)
1引言
1.1术语定义
BOSS BUSINESS & OPERATION SUPPORT SYSTEM
MMS Marketing Management System (营销管理系统)
HLD High-Level Design （概要设计）
OO Object Oriented （面向对象）
OOA Object Oriented Analysis（面向对象分析）
OOD Object Oriented Design（面向对象设计）
UML Unified Modeling Language （统一建模语言）
OLTP Online Transaction Processing （联机事务处理）
TMS Transaction Management System （事务管理系统）
WTC Weblogic Tuxedo Connector （Weblogic与Tuexdo连接技术）
WS Workstation （Tuxedo客户端与服务的连接方式）
1.2参考资料
《中国移动通信业务运营支撑系统（BOSS）业务技术规范（征求意见稿）》《中国移动通信业务运营支撑系统（BOSS）业务技术规范－接口分册（征求意见稿）》
1.3文档结构
本文的其他部分是按照以下方式组织的：
系统目标
该章节指明我们所要实现的系统以及与此系统有交互关系的所有外部
Actors。

此外还概括描述了系统的主要功能。

设计前提及假设
该章节说明概要设计所依赖的前提及假设。

系统核心概念模型
该章节描述MMS各子系统中涉及的主要核心概念模型。

系统架构设计
该章节主要包括：概要设计方法论、系统硬件体系结构、系统软件体系架构、软件组件和应用设计。

数据库设计
该章节说明对数据库的要求和相关ER模型
系统出错处理考量
该章节针对系统主要的出错情况提出相应的处理原则。

结论
总结以上设计的优势及未来展望。

附录
概要设计附录包括：
1.高层组件与需求对照表
2.UML模型（附件）
2系统目标
建设移动营销管理系统设计和实施包括以下目标：
建立一个统一的营销管理系统，以支持各地的个性化营销政策管理。

集中各分公司营销数据，建立同一的视图，为省公司提供及时的营销管理和营销分析。

统一各分公司的营销报表统计，为报表数据提供统一的统计口径。

2.1系统描述
MMS系统设计和开发按照集团公司要求和移动的要求，在满足系统需求的前提下，其逻辑结构、软件架构和BOSS基本保持一致，尽量减少对在线BOSS系统的影响。

2.2系统接口图 (System Context)
本节列出所有与移动营销管理系统交互的外部角色(Actor), 以明确定义系统边界。

外部角色包含如下图所示的几类，具体的角色会在以下几小节中详细说明。

图2-1: 营销管理系统系统边界示意图
2.2.1营业前端
营业厅的营销受理人员通过前台受理PC或终端来使用MMS提供的功能，进行营销方案的受理。

2.2.2营销管理后台
营销系统管理员通过营销管理后台来执行MMS提供的管理功能，维护MMS系统。

营销配置人员通过营销管理后台来执行MMS提供的营销方案配置功能。

2.2.3BOSS系统
BOSS系统在进行相关业务受理时，需要同营销管理系统交互，以维护营销数据和业务的完整性。

2.2.4BOSS系统管理员
BOSS系统管理员通过对操作员角色的分配，使不同操作员在使用系统时可以扮演营销系统管理员、营销配置人员、营销受理人员等。

2.3系统功能性需求概述
下面概括给出MMS系统功能性需求, 关于具体细节, 请参见《移动营销管理系统需求规格说明书》。

营销管理系统需要具有营销方案配置（个人和临时集团）的管理功能；
营销管理系统需要具有营销方案受理的功能，可以在前台营业厅受理，也可以通过后台受理；
营销管理系统应具有物品赠送功能，支持在业务受理和协议到期后的物品领取；
营销管理系统应具有根据营销方案配置自动释放信用金或专有帐户配置的功能；
营销管理系统应支持个人营销方案和临时集团营销方案的受理；
营销管理系统应具有根据营销方案配置进行预警和提醒的功能；
营销管理系统应具有营销黑名单的控制功能，以限制黑名单用户的营销受理；
营销管理系统应具有对品牌不满足营销方案要求的用户提供预约受理的功能；
营销管理系统应具有营销预警的处理和限制用户生成营销预警的功能；
营销管理系统应具有营销方案受理、预约的撤销和中断功能；
营销管理系统应提供对营销物品的管理维护功能；
2.4系统非功能性需求概述
下面概括给出影响概要设计的MMS系统功能性需求, 关于具体细节, 请参见《移动营销管理系统需求规格说明书》
2.4.1性能要求：
营销管理系统的性能要能够满足到2006年6月的业务需求。

营销管理系统的用户界面应提供帮助功能，对陌生术语、流程提供解释。

营销管理系统在每月出帐处理结束后应完成相应的配置释放和最低消费补齐操作。

营销管理系统在每月出帐处理结束后应保证对协议已正常结束的用户进行相应处理,如：发出物品、信用金领取的提醒。

2.4.2备份要求：
营销管理系统在线存储可查询服务使用记录为2个月。

营销管理系统在线保存相关营业、帐务及客户服务交易12个月。

3设计前提和假设
本文档设计方案基于如下设计前提和假设:
该设计是基于BOSS现有系统，如果BOSS系统发生大的变化，将对系统设计造成直接影响；
1.5节中所列的参考资料版本是此设计的依据。

如果其中任一文档的版
本发生变更，此设计应做相应的修正。

由于营销管理系统需要实现的功能有的需要BOSS现有系统提供支持，因此需要对BOSS现有系统作相应修改。

4系统核心模型
以下各小节概要阐明系统体系结构涉及的MMS系统的核心概念模型。

4.1营销方案配置概念模型
营销方案配置概念模型主要包含了营销方案(个人和临时集团)配置基本信息和对应的释放、赠送配置以及营销渠道相关信息；
图4-1 营销方案配置概念模型
图4-2 营销渠道信息概念模型
4.2营销资料概念模型
营销资料概念模型主要包含了营销基本信息(个人和临时集团)和对应的担保、信用金、预约、赠送信息；
图4-3 营销信息概念模型
5系统架构设计
5.1总体架构设计
营销管理系统是对原BOSS系统的功能扩充和升级，系统的总体框架与BOSS 系统相同，如下图所示：
图5-1 营销管理系统总体架构图营销管理系统软件架构如下图所示：
图5-2 营销管理系统软件架构图
图中虚线部分表示对于BOSS统一版本改造的支持方案，在方案中通过替换JavaBean调用的“参数打包、服务调用、结果读取”三个方法的实现，将其由FML格式改为XML格式，服务调用改为调用CGI服务；新增业务流程调度服务(CGI),实现业务流程的可配置。

该方案对营销管理系统本身的变更很小，易于实现。

5.2硬件体系结构
硬件体系结构主要描述各应用主机之间的逻辑连接和功能划分情况，如下图所示：
图5-2 营销管理系统硬件结构图
5.3软件设计方法
营销管理系统的软件设计采用了面向对象和组件、自顶向下逐步迭代的软件工程技术；整个设计方法是基于一个分层的软件体系结构。

这种方法的出发点是需求规格说明书和按此开发的系统用例。

这种设计方法首先定义了各种不同功能组的概念模型。

随后定义并且描述一个分层的体系结构。

它将各个功能作了逻辑划分，并给以后的系统和组件的分解提供了指导方法。

基于这种已定义的分层的体系结构，可将系统进一步划分成多个子系统，划分的主要依据是如系统功能规格说明书中陈述的功能需求的特征。

这些子系统可能在系统结构中只占一个层面或者跨越多个层面，取决于它所需要完成的功能需求。

各个子系统由属于以下类别中的高级软件组件构成：
接入组件 (Interface Component)
系统组件 (System Component)
业务组件 (Business Component)
在系统用例描述中可以发现这些组件。

这些组件的发现、分解和设计是通过迭代的方法完成的，各个子系统的关键用例被选出并转换成系统流程，其中软件组件与一系列按时间顺序出现的命令相互作用来实现相应的用例。

通过在各个子系统的系统流程中使用这些组件，新的组件可以被定义，现存的组件可以合并成单个组件，或者分解成多个组件。

另外，由于涉及到更多的系统场景，组件接口也会越来越丰富和清晰。

在这一阶段中关于设计方面的问题和考虑会出现，并应该在它们出现时被迅速提出。

设计的考虑应该主要在以下的范围中：
功能
本地化
可用性
性能
扩展能力
总体架构和与标准化的兼容性
实现可行性
这些设计的考虑、理论基础和决定都应该记录在设计文档中。

迭代周期应该较短，确保设计的问题能够尽早出现并提出，使更多的迭代能够执行。

当覆盖了大多数的关键用例，并在应用一些额外用例时，组件只有很少或者几乎没有变化时,迭代周期将会停止。

随后设计任务包括数据设计（对应于数据组件）和记录所有的设计过程中的中间输出和信息来创建设计文档。

同时，为了标明执行风险，将成立专门的小组进行原型设计的工作，来验证设计原则和在实践中将采用的方法。

5.4软件体系结构
5.4.1.1系统层次架构图
与BOSS系统的体系架构相同，MMS系统分为数据核心层、业务逻辑层和接入层三层。

图 5-3系统层次架构图
5.4.1.2数据核心层
5.4.1.2.1数据核心层的定义
数据核心层是MMS系统对业务数据进行统一组织、集中管理的平台，它为业务逻辑层提供规范、高效的数据服务，实现业务数据的充分共享，是整个MMS系统的基础。

数据核心层分为数据子层和服务子层。

5.4.1.2.2数据子层
1)数据子层的定义
数据子层是指在MMS系统运行时，系统记录或存储的业务运营数据、业务统计数据及系统运行辅助数据等。

它包含了业务逻辑层所需的数据资料，是MMS系统运行的基础和运行结果的具体体现。

2)数据子层的内容
数据子层是业务数据的集合，包括营销方案配置、营销资料信息、营销物品、营销预警与提醒、营销黑名单等数据。

5.4.1.2.3服务子层
1)服务子层的定义
服务子层是对数据子层的操作访问层，它以统一、规范的接口形式为业务逻辑层提供对业务数据的直接访问和控制(原子服务)，是业务逻辑层访问数据子层的纽带。

2)原子服务的定义
原子服务定义为数据子层上的一个或一组功能，是对业务数据最基本的操作。

原子服务屏蔽业务数据的存储、组织和访问的细节，使得业务逻辑的实现更为简单和统一。

3)原子服务的分类
根据对数据子层中数据操作的类型，将原子服务分为增加、删除、修改、查
询等几个大类。

5.4.1.3业务逻辑层
5.4.1.3.1业务逻辑层定义
业务逻辑层是MMS系统业务处理的逻辑平台，它通过对数据核心层服务子层原子服务的调用访问业务数据，实现不同的功能模块，满足不同的业务需求。

业务逻辑层由若干业务函数和业务过程组成，为接入层提供业务服务，实现业务逻辑的共享，完成相应的业务功能。

5.4.1.3.2业务函数
业务函数是业务功能逻辑的基本处理单元，实现业务功能的某个特定环节的功能。

业务函数处于原子服务和业务过程之间。

5.4.1.3.3业务过程
业务过程是实现业务功能的处理流程，由业务函数加上控制逻辑组合而成。

业务过程可由业务过程和业务函数组合而成。

5.4.1.4接入层
5.4.1.4.1接入层的定义
接入层是MMS系统与外部进行数据交换的平台，由接入逻辑构成。

接入逻辑分为界面逻辑和接口服务。

对于系统使用者，提供多样化的界面逻辑，实现对业务逻辑的共享；对于与MMS系统相联的外部系统，向业务逻辑层提供一组接口服务，业务逻辑层通过接口服务完成与外部系统的数据交换。

5.4.1.4.2接入逻辑
接入逻辑是MMS系统与系统使用者之间的一个或一组数据交换过程，分为界面逻辑和接口服务。

5.4.1.4.3界面逻辑
界面逻辑由交互界面、界面控制逻辑和业务过程调用构成。

交互界面负责系统使用者的数据输入以及系统输出数据的表示；界面控制逻辑负责交互界面间的逻辑控制；业务过程调用负责调用业务逻辑层中的业务过程，完成相应的业务功能。

多个界面逻辑可以重新组合成新的界面逻辑。

5.4.1.4.4接口服务
接口服务是MMS系统完成与外部系统的数据交换的一组功能单元。

业务逻辑层中的业务过程通过接入层中的接口服务实现与外部系统的数据交换。

5.4.1.5M MS系统三层之间的关系
数据核心层的服务子层向业务逻辑层提供统一、规范的原子服务，屏蔽业务数据的存储、组织和访问的细节，实现业务数据的充分共享。

业务逻辑层必须通过原子服务访问业务数据。

业务逻辑层的业务函数通过数据核心层的原子服务访问业务数据。

业务过程通过调用业务函数完成基本业务功能，一组业务过程实现具体的业务功能。

业务逻辑层通过向接入层提供统一的业务过程实现业务逻辑的共享。

接入层实现MMS系统与外部的数据交换。

对于系统使用者，接入层接收使用
者的数据输入，通过调用业务逻辑层的业务过程实现具体的业务功能，并将处理结果返回接入层，利用交互界面进行表示。

对于外部系统，业务过程通过接入层的接口服务完成与外部系统的数据交换。

5.5软件组件和应用设计
此部分重点描述为了保障同步的正确性，保证在指定时间内完成系统的切换与回切，营销管理系统自己特有的功能。

5.5.1软件组件设计
5.5.1.1数据类型（DT）
数据类型定义了BC、SC需要使用到的自定义数据类型，其定义来自概念模型，并经过了筛选和合并，最终设计出如下的数据类型：
DT列表：
5.5.1.2业务组件（BC）
业务组件直接与数据库打交道，用于完成对应的Business Type的管理功能，供SC的方法使用；其定义来自概念模型中需要存入数据库的实体，并经过了细化、抽象、合并。

业务组件关系图如下：
图5-1 营销方案配置BC图
图5-2 营销资料信息BC图
图5-3 营销物品定义BC图
图5-4 营销预警与提醒BC图
图5-5 营销黑名单BC图业务组件列表：
BT名称
5.5.1.3系统组件（SC）
系统组件来源于用例和需求，用于封装和对外提供用例描述的功能；
系统组件关系图如下：
图5-6 营销方案配置SC图
图5-7 营销受理SC图
图5-8 营销释放SC图
图5-9 营销物品管理SC图
图5-10 营销预警与提醒SC图
图5-10 营销黑名单SC图
系统组件列表：
描述说明
5.5.2告警采集应用设计5.5.2.1功能描述
5.5.2.2逻辑设计
5.5.2.2.1关键流程设计
5.5.2.3应用结构设计 程序名称：
功能：
组成：
部署：
生产中心主机上
5.5.2.4接口设计
5.5.2.4.1应用与外部接口
应用与外部接口即是客户端应用的启动参数，其定义如下: 客户端应用启动命令行参数:
参数描述：
5.5.2.4.2应用配置文件文件类型：
文件名称：
文件内容：
6数据库设计
数据库设计是指营销管理系统需要使用的数据库对象的设计，包括用户模式、库表逻辑视图等。

6.1用户模式
为了便于对客服数据的直接访问，以及避免不必要的全局事务，决定直接使用custcare用户模式。

6.2数据库表逻辑视图
6.2.1营销配置
图6-1 营销配置表逻辑视图6.2.2营销资料信息
图6-2 营销资料信息表逻辑视图
6.2.3营销物品
图6-3 营销物品表逻辑视图6.2.4营销预警与提醒
图6-4 营销预警与提醒表逻辑视图
6.2.5营销黑名单
图6-5 营销黑名单表逻辑视图
7BOSS系统改造设计
在BOSS系统中，已经实现了专有帐户的相关业务功能，营销管理系统兼容了BOSS 系统中原有的专有帐户功能，并对原专有帐户进行了相应的功能升级，所以BOSS系统中涉及到专有帐户的相关业务都需要进行相应的改造升级；营销管理系统对于参与营销活动的用户需要进行一些业务限制和检查，因此也需要BOSS系统进行相应的改造。

由于相关改造在BOSS系统进行，这里只列出需要改造的功能点。

7.1品牌互转相关功能改造
CUI－品牌互转功能改造
CUI－品牌互转撤销功能改造
BossView－批量品牌互转功能改造
BossView－品牌互转批量撤销功能改造
7.2专有帐户相关功能改造
CUI－专有帐户申请功能改造
BossView－专有帐户批量申请功能改造
屏蔽BossView－专有帐户查询功能
BOSS系统每月专有帐户返还功能改造
BOSS出帐专有帐户返还功能改造
7.3付款方式变更、申请销户、过户功能改造
CUI－付款方式变更功能改造
CUI－申请销户功能改造
CUI－过户功能改造
7.4冷号回收功能改造
B OSS系统冷号回收用户数据清理进程改造
7.5查询功能改造
BossView－用户资料查询功能改造BOSS系统的短信查话费功能改造
8系统出错处理设计
8.1出错处理总体原则
总体上，所有系统出错均应被记入系统出错日志，其日志信息应包括时间、出错代码所在位置、出错信息。

系统统一定义一套错误码。

原则上，所有的API都应返回错误码，而数据的传递由参数的形式完成。

用户界面对错误码作最后的处理，应提供风格统一的出错提示窗口来显示错误信息。

对命令行操作, 正常操作应返回0以标志成功；否则，应有出错信息提示，返回码非0。

如果通讯中断, 出错返回至请求方以表明通讯出错。

8.2后台服务进程出错处理
由系统管理的应用软件状态监控模块负责监控，系统管理的应用软件状态监控模块检测到某一系统服务异常，它将自动记录该事件, 并能自动重启相应系统服务。

8.3数据库联接出错处理
数据库联接出错，系统应提供重试机制。

重试次数可配置。

多次重试失败后，系统发出告警信息提示。

8.4登录出错处理
对登录出错，系统应提供重试机制。

重试次数可配置。

重试失败后，系统显示错误信息提示。

9结论综述
针对集团公司规范的要求和JMCC的实际需求, 本文详细描述了对移动营销管理系统的概要设计.。

它采用了先进的面向对象和组件的软件工程方法论, 涵盖了对所有移动营销管理系统需求的高层设计及考虑, 为后期开展系统详细设计工作打下了坚实的基础。

9.1优势
营销管理系统逻辑结构、软件架构和BOSS基本保持一致，减少系统开发和维护工作量。

采用面向对象的分析和设计
充分考虑系统负载均衡
易于操作、管理和故障分析、软件自动化高
项目使用成熟的需求分析及开发设计技术和工具（OOA，OOD，UML，Rose 等），项目组成员遵循软件开发过程，有助于建立稳定、高质量的产品。