保证书

软件序列号: 特服号: 签名: 每次大约发送: 条

公司网址： 短信发送对象均为本单位的客户或员工，短信样本如下： 1、 2、 3、 除此类短信之外，不发送其它任何内容。如果有短信接收者投诉，所造成的一切后果由本单位承担！

特此证明！

负责人：

承诺单位：

日期：

 

第二篇：短信平台系统

短信平台系统

概要设计系统说明系统五．总体设计

1． 总体结构

2． 模块设计

（1）。计费管理子系统

用户入费

错单处理

用户费率管理

费率管理

用户分析

（2）。系统维护子系统

管理员登录、管理员管理、数据库设置等

（3）。计费引擎子系统

六．接口设计

（一）.界面设计

1. 计费管理子系统

用户入费管理窗口

错单处理窗口

用户费率管理窗口

费率管理窗口

用户分析窗口

要求：

美观，实用，易用，结构清晰。

2. 系统维护子系统

管理员登录窗口

管理员管理窗口 数据库设置窗口

要求： 美观，实用，易用，结构清晰。

3. 计费引擎子系统

设计成数据库触发器，实时扣除用户预付费。

（二）.模块接口设计

1． 计费管理子系统

2． 系统维护子系统

3． 计费引擎子系统

（三）.对外接口设计

1． 客户端费用检测接口

七．数据库设计

见：《轩辕短信计费系统数据库设计》

八．逻辑结构设计

十.出错处理

1． 系统提供强大的容错处理，数据处理在提交时如果发生错误，将取消此次提交任务，

并反馈错误信息，提示重新输入。

2．对于用户入费充值统记录了管理员的每一次的操作记录，以备出现问题时查阅。

华软网_源码中心提供 [url][/url]

轩辕短信计费系统详细设计

一．引言

本详细设计是在概要设计之后，为明确程序具体实现功能以及指导编程人员以后的编

程工作而而编写的，它的依据是《轩辕短信计费系统总体设计》与《需求分析》 读者是后期的编程人员。

二．项目背景 经过需求分析之后以及总体设计工作之后，系统的功能模块，框架结构已经基本明确。详细设计工作主要明确如何完成这些功能的实现。基本要求是：界面大方，易操作；操作流程控制清晰；功能完善，容错处理完备；主要模块封装独立，便于以后升级。

三．定义与说明

1．入费单

用户预付费后，由管理员录入计费系统的用户缴费记录。

2．费率

用户发送短信后，从预付费帐户中扣除金额的规则。

3．计费方式

按费率的计费时间单位，分为单条方式和包月方式。

四．参考资料

1．《轩辕短信计费系统开发计划和需求说明》

2．《轩辕短信计费系统总体设计》

3．《轩辕短信计费系统数据库设计》

4．《Microsoft Visual Basic 6编程规范》

五．功能模块结构

1. 计费管理子系统

用户入费管理窗口

错单处理窗口 用户费率管理窗口

费率管理窗口

用户分析窗口

要求：

美观，实用，易用，结构清晰。

2. 系统维护子系统

管理员登录窗口

管理员管理窗口

数据库设置窗口 要求：

美观，实用，易用，结构清晰。

3. 计费引擎子系统

采用数据库触发器的方式，实现与短信控制台的接口，实时扣除用户预付费。

六．界面设计 1． 系统维护子系统

1.1管理员登录

【模块名称】

管理员登录

【模块功能说明】

管理员登录。

【模块的界面设计】

用户名称：

密码：

【各栏目说明及有效性】

必填项：

用户名：char (20)

密码：char（20）

【模块的主要处理】

1． 2． 取消：取消重新登陆

【接口】

管理员管理

【限制条件】

1.2管理员管理

【模块名称】 管理员管理

【模块功能说明】

管理员管理。

【模块的界面设计】

浏览界面：

工具栏

管理员ID 管理员名称

编辑界面：

【各栏目说明及有效性】

必填项：

管理员ID：char (20)

密码：char (20)

确认密码：char（20）

管理员姓名：char (20)

【模块的主要处理】

工具栏按钮：

1． 新增： 新增一个管理员

2． 修改：修改管理员资料

3． 删除：已经使用的管理员不能被删除。

4． 关闭：关闭窗口

【接口】

管理员登录

【限制条件】

1． 每管理员只能修改自己的资料。

2． 已经使用的管理员不能删除。

1.3数据库设置

【模块名称】 数据库设置

【模块功能说明】

设置计费系统的数据库运午环境（和短信控制台，Web统一）。

【模块的界面设计】

【各栏目说明及有效性】

必填项：

服务器：char

数据库：char

用户名：char

密码：char

【模块的主要处理】

【接口】

【限制条件】

2． 计费管理子系统

2.1用户入费

【模块名称】

用户入费

【模块功能说明】

给预付费用户的帐户充值。

【模块的界面设计】

浏览界面： 工具栏

用户ID 用户名称 当前余额 状态 地址 联系电话 电子邮箱

入费界面：

查询用户界面：

【各栏目说明及有效性】

【模块的主要处理】

入费：给选定用户充值。

查询：查询符合指定条件的用户。

全部：列出所有用户。

刷新：刷新用户的状态。

关闭

【接口】

错单处理

用户费率

【限制条件】

1． 开始、结束日期是对于包月用户才需设置。

2． 对于包月用户，本次入费即为一个包月单位的费额，管理员无法改变。

2.2错单处理

【模块名称】

错单处理

【模块功能说明】

错误或重复的入费单的处理。

【模块的界面设计】

浏览界面：

工具栏

入费单ID 用户ID 用户名称 入费金额 入费时间 费率 开始日期 结束日期 状态

错单更正界面：

用户选择界面：

【各栏目说明及有效性】

用户选择：需更正所选单的用户时，单击按钮调出用户选择界面，选择更正后的用户。

【模块的主要处理】

错单：对指定入费单进行错单更正。

记录：查阅每一入费单的入费操作记录。

查询：查询符合指定条件的入费单。

全部：列出所有入费单。

关闭

【接口】

用户入费

用户费率管理

【限制条件】

1． 开始和结束日期是对于包月用户才需设置。

2． 对于包月用户，本次入费即为一个包月单位的费额，管理员无法改变。

2.3用户费率管理

【模块名称】 用户费率管理

【模块功能说明】

用户费率管理。

【模块的界面设计】

浏览界面：

工具栏

用户ID 用户名称 当前费率

费率选择界面： 查询用户的界面：

【各栏目说明及有效性】

【模块的主要处理】 设置：对指定用户进行费率设置。

默认：设置系统的默认费率。

查询：查询符合指定条件的用户。

全部：列出所有用户。

关闭

【接口】

用户入费管理

费率管理

【限制条件】

2.3费率管理

【模块名称】

费率管理

【模块功能说明】

费率管理。

【模块的界面设计】

浏览界面：

工具栏

ID 费率名称 计费单位 费额 状态

编辑界面：

各栏目说明及有效性】

必填项：

费率ID：int，系统自动生成。

费率名称：char (20)，不允许为空。

计费方式：smallint，0：单条；1：包朋。 计费单位：int，系统缺省为1，不可更改。 计费额：numeric (9,2)，不允许为空。

【模块的主要处理】

新增：增加新的费率设置。

修改：修改已有的费率设置。

删除：删除已有的费率设置。

关闭

【接口】

用户费率管理

费率管理

【限制条件】

1．已经使用的费率不能删除。 2.3用户分析

【模块名称】

用户分析

【模块功能说明】

用户计费信息的统计分析。

【模块的界面设计】

用户分析设置界面：

用户计费信息统计界面：

用户ID 用户名称 当前余额 本期消费金额 已消费总金额 本期已发送条数 已发送总条数 可发送条数

【各栏目说明及有效性】

【模块的主要处理】

【接口】

【限制条件】

3． 计费引擎子系统

计费引擎采用触发器的方式实现，具体实现以下功能

短信平台架构概要设计简述

短信平台架构概要设计简述

信息平台架构概要设计（草案）

架构概要设计

一、 系统概述

系统概述为配合信息公司业务开展， 我们需要一个安全、 稳定、 高效、 强壮且可扩展的平台系统。 系统架构如下；

所有业务基于统一的业务、 数据中心

中心保存了所有数据和关键性服务 中心。 （如 中心 招标信息分发系统等） ，各站点保存各自业务数据和功能。

应用客户（如：自维系统等）和 网站客户通过服务接口和系统进行数据交互（如：登陆、上传电子货架数据等） ，中心数据 和站点通过过滤、同步保证一致性。考虑将来全国扩展，中心应租借双线机房。总站和分站 可以构建于同一机房，也可是异地机房。同时建议所有异地机房以及公司通过 VPN 打通后 台连接，这样既保证安全又方便维护。 软件架构遵循 SOA 架构设计，将独立应用做成服务供其他应用使用（如短信、用户管 理等） 。搭建松耦合、分布式应用方便系统扩展和发布。同时网站利用模板、动态页面转静 态页面提高整体访问速度和系统负载。 VPN/Intranet/Internet 数据同步 VPN/Intranet/Internet 中心架构概述

二、 中心架构概述初期只需中心就可满足需求，随着业务扩展可在相应地域设立分机房建立分站点。 中心、总站架构图如下： 数据同步 交 互 图片 服务器 负载均衡web服务器 历史库归档库 磁盘阵列 数据库服务器（群） Ftp等服务器 M2平台前台服务器群 中心应用服务器(群) M2平台后台服务器群 客户 Internet 电信光纤100M 客户 网通光纤100M (根据业务发展 设定) 路由器 防火墙 服务器 Web 服务器(群) 应用服务器(群) 大致配置 2 路 1u 服务器 4~6G 内存 4 路 1u(2u)服务器 6G 以上 功能说明 负责 web 服务。为提高性能、访问速度 将负载较大的图片等分服务器加载。 提供前台、后台业务处理服务。通过 WebService 等提供对外接口。如：接收 和处理自维工具上传数据；处理材料招 投标软件上传信息；短信服务等。 备注 可先购置 1 台到 2 台。后根据业务调整。 根据根据需要开发 blog、论坛等功能。 可先购置 1 台。后根据业务调整。该服务 器负载较大。 数据库服务器(群) 4 路 1u(2u)服务器 8G 以上越 大越好 根据具体情况 根据具体情况， 建议用 radi1+0 根据具体情况 负责数据处理，数据同步等 可先购 1 台；也可先购两台建立双机热备 份；或作数据库群集。后根据业务调整。 Ftp 等服务器 磁盘阵列 归档历史库 提供特定服务。如 Ftp、mail 等 提供数据存储服务 备份历史数据 历史数据、文档等资料的归档 考虑到中心须提供不受地域限制的畅通的信息服务，故租用双线机房，现阶段电信接 入，以后根据业务扩展双线接入。 具体服务器架构、负载均衡、异常处理、容错处理等根据业务推进细化。

二、 系统架构概述整体设计目标是，搭建高效的基于服务、松耦合、分布式架

构。

开发运行环境如下：对象 服务器操作系统 服务器程序开发主要语言 环境或开发语言 Win2003 Server（Win2000Server） C# Delphi 或 VB（建议 Delphi） 后台业务处理、接口实现等。如有性能需要可用其他高效语言(如 vc)实 现功能，.net 封装接口。 客户端软件 通过 200 多份客户调查问卷，发现客户硬件情况较差，故选用 Delphi 等实现。 数据库 Sql Server2005 先用 Sql Server05 建立基础业务库。以后根据业务需要调整。 说明 整体部署图大致如下： ws、ftp、rss等 Web App WS接口等 Wap App (O/Rmapping) WS接口等 (SSO) WS接口等 技术要点描述： 技术要点描述： 1）角色、权限管理使用统一服务管理 ）角色、权限管理使用统一服务管理 使用 整个系统将会是由多套应用系统组成，期间的身份验证、会员管理等相对较为复杂。如 果每个应用独立实现、独立管理，后期的调整维护将会非常复杂。所以系统引入单点登陆 (SSO)概念，设计统一的用户、认证、权限等管理服务，各系统通过该服务（不一定是单一 认证服务器）统一认证，并提供如积分等服务。 2）中心网站设计要点 ） 2.1）URL 重写隐藏后台实现 重写隐藏后台 隐藏后台实现 ） 前台访问通过

ISAPI_Rewrite、URLRewriter 等实现 Url 重写，这样一、可以对外屏蔽后 台实现，二、便于搜索引擎分析。Url 重写可将 news.asp?id=234 的映射成 news/234.html， 只需设置 RewriteRule /news/(\d+)\.html

/news\.asp\?id=$1 [N,I] ， 这样就把 /news/234.html 这 样的请求映射成了 /news.asp?id=234。另外，在适当修改代码后可实现域名的重定向。如将

/news/index.html 定向为 /abc/news/index.html。

2.2）网站内容通过内容发布系统发布信息 ）网站内容通过内容发布系统发布信息 内容通过内容发布系统发布 网站每天每时要发布大量的信息，如果全部通过程序动态处理，一则可控性差，二则 服务器负载大。所以考虑通过内容发布系

统管理发布信息。其主要功能，提供信息统一发布 平台；提供用户处理接口。 考虑业务的快速实现和技术的持续发展，考虑将技术框架和业务实现分开实现 将技术框架和业务实现分开实现， 考虑业务的快速实现和技术的持续发展，考虑将技术框架和业务实现分开实现，首先 实现内容发布平台，然后再实现业务模块 模块。 实现内容发布平台，然后再实现业务模块。 网页用到技术 a） 通过内容发布系统将动态页面转静态页面 考虑如果所有页面都可以用动态页面显示，当访问量上来后，服务器负载将会非常 大。 所以考虑将那些信息不常变动的页面 （如新闻等） 转成静态页面， 减轻服务器负载， 加快用户加载速度。 （如果页面信息会变化如论坛等，可定期或触发式生成静态页面） 如图内容发布动转静服务通过模板（用 html 嵌入 nvelocity 等脚本实现） 、数据库以及 生成配置和规则生成静态页面(html、 shtml)。 其中内容发布有客户端系统用于维护网站内容。 b）静态页面、Ajax、后台处理实现动态效果 有些页面虽然可以做成静态页面(如报价页)，但考虑到数据安全性等其他原因，不建议 直接做成静态页面。我们可以通过 静态页面+Ajax 在服务端验证身份后获得数据，刷新页 面。 另外，动态页面也可以通过静态页面加 Ajax 实现。用户首先从加载 HTML 页面，然后 通过异步调用服务端请求（可在应用服务器上实现）加载数据。这样既加快了页面的加载， 也降低了 web 服务器负载。 前台 Ajax 通过 protoryp.js、 等实现， ext 后台服务端通过 Castle 的 MonoRail 或 Web Service 来实现。 这样，可以保证 web 访问的高效性。同时由于页面主体基于静态页面，将来如果要作 系统迁移，也可平滑过渡。 3）客户端软件 ）客户端软件 3.1）客户端软件独立成体系 ） 整个系统客户端独立成体系。其前期功能相对较简单，但随着业务的推进，其功能将 是一个逐步丰富的过程。 所以第一期主要是搭建架构的过程。 考虑到一个客户可能有多种身 份，如果每个单独应用都做成一个独立程序，将来客户可能会要装多套软件，这会非常不方 便，所以考虑将客户端做成统一平台，当用户登录后根据其注册信息，开放功能，服务端也 根据用户注册信息开发其可调用功能。同时客户端软件通过在线升级模块获取最新版本。 另外，客户端软件可嵌入 web 浏览器，直接访问网站。 3.2）客户端软件和服务端通讯 ）客户端软件和服务端通讯 客户端软件负责收集客户信息上传中心；接收中心发出的信息；完成客户需要的功能。 客户端通过 FTP 等将服务断接口将收集的信息上传中心，由中心统一处理；调用服务端提 供的 WebService 触发服务端处理、获取信息；通过轮询获取 RSS 信息，获得网站发布信息。 4）数据库处理 ） 数据处理流程 服务端 洗切、处理数据 原始接收数据集 业务数据集 归档数据集在当前应用中存在海量的各类数据， 收集来的信息如果直接当业务数据处理， 将会限制 业务的扩展。 再者海量业务数据下查询和更新的策略是不同的。 所以将原始接收数据集和各 业务数据集分开。 如上图，原始基础数据集接收原始业务数据，作为数据仓库的基础数据； 再通过若干规则的洗切、处理成各业务所需的数据。MSSQLSERVER2005 自带数据抽取工 具 SSIS。运用 SSIS 的智能化，可以实现全自动智能数据提取。这样更容易数据拓展，以后 无论是跨区域还是跨时差，对于数据的获取，都变得非常容易。 海量数保存 业务中存在海量数据量的业务需求。如供应商、材料等信息。考虑首先根据其业务特 性（如材料的类别等）将其分表保存，通过视图将其组合，如果单表数据量还是太大的话， 用表分区来提高性能。数据分区简化了对大表的维护，且允许为每个分区创建独立的索引， 表分区可以将负载扩展到磁盘上去，这大大提高了以后数据查询的效率