基于UML短信息计费系统设计
某移动公司短消息计费系统建议方案

某移动公司短消息计费系统建议方案随着移动通信技术的发展和普及,短消息已经成为了用户与用户之间进行即时沟通的主要方式之一。
然而,随着用户数量的增加和短消息的使用量不断攀升,移动公司的短消息计费系统面临着越来越大的压力和挑战。
为了更好地应对这些问题,本文将提出一些关于某移动公司短消息计费系统建议方案。
一、方案背景与现状分析本次建议方案针对的是某移动公司的短消息计费系统。
该公司的短消息计费系统目前存在以下问题:1. 计费不够精准目前,某移动公司的短消息计费系统采用的是按条计费的方式,但是这种计费方式并不能保证计费的精准性。
在用户发送短消息时,如果消息因为某些原因发送失败了,但是被计费了,就会导致用户的不满和抱怨。
2. 计费流程复杂某移动公司的短消息计费系统,目前需要经过多次计费和审核流程,这不仅增加了计费的周期和复杂度,还容易导致计费过程中的出现错误。
3. 无法满足用户的个性化需求目前,某移动公司的短消息计费系统无法提供用户个性化的计费方案,例如只收取用户所发送的文字短消息费用等。
二、建议方案针对以上问题,我们提出以下建议方案:1. 建立起精准的计费模式针对当前的问题,我们建议某移动公司可以采用精确计费模式,即采用实际成功发送的短消息来计费。
这样,就可以避免因短信发送失败而产生的计费问题,提高用户的满意度和信任度。
2. 简化计费流程我们建议某移动公司可以优化其计费流程,并简化计费审批程序。
例如,直接对用户所发送的短消息进行计费,无需经过多次审核和计费流程,可以减少计费过程中的错误和延误。
3. 提供个性化的计费服务为了让用户更加满意,我们建议某移动公司可以提供个性化的计费服务。
例如,通过允许用户选择只发送文字短消息而不收取图片或语音短消息的费用等,来满足用户的个性化需求。
三、实施计划在实施该建议方案时,我们建议某移动公司可以以下步骤:1. 收集用户反馈某移动公司应该收集用户的反馈和意见,了解用户的需求和期望,为制定更加符合用户需求的计费方案提供依据。
基于UML的外卖订餐系统需求分析

基于UML的外卖订餐系统需求分析目录1. 系统概况 (3)2. 系统需求 (4)2.1. 功能性需求 (4)2.2. 非功能性需求 (4)3. 系统开发时间管理 (5)4. 系统开发可行性分析 (5)4.1. 技术的可行性: (6)4.2. 经济的可行性: (6)4.3. 操作的可行性: (6)5. 系统开发项目人员安排 (6)6. 基于UML的系统分析 (7)6.1. 用户用例图 (7)6.2. 系统主要用例 (11)7 总结 (29)图表目录表格 1 项目人员安排表 (7)表格 2 顾客管理账户用例描述 (11)表格 3 找回密码用例描述 (12)表格 4 顾客订餐用例描述 (15)表格 5 送货员送餐用例描述 (16)表格 6 顾客查看历史订单用例描述 (16)表格 7 主管查看历史订单用例描述 (17)表格 8 菜品评论与主管查看用例描述 (21)表格 9 主管管理菜品描述 (24)表格 10 系统管理员用例描述 (26)图 1 外卖订餐系统结构图1 3图 2 外卖订餐系统结构图2 4 图 3 系统开发甘特图 5 图 4 外卖订餐系统用户用例图8 图 5 顾客用例图9 图 6 主管用例图10 图 7 送餐员用例图10 图 8 系统员用例图11 图 9 账户管理活动图13 图 10 顾客注册顺序图14 图 11 顾客登录管理账户顺序14 图 12 顾客订餐活动图18 图 13 送餐员送餐活动图19 图 14 主管查看历史订单活动图20 图 15 顾客订餐顺序图20 图 16 送餐员送餐顺序图21 图 17 顾客评论活动图22 图 18 主管查看评论活动图23 图 19 顾客评论顺序图23 图 20 主管管理菜品活动图25 图 21 主管管理菜品顺序图26 图 22 系统管理员活动图28 图 23 系统管理员顺序图291.系统概况外卖订单系统是服务于餐馆外卖活动的一个简单的信息系统,开发该系统主要希望实现扩大本餐馆宣传、缩短顾客订餐时间、减少订餐错误、便于订单统计分析等,最终达到扩大餐馆影响力、提高餐馆外卖业务效率、实现一定程度的决策支持的目的。
基于UML的分类信息系统研究与设计

随着 网络信 息技 术不 断发展 , 网络信息 服务 逐步 融入 到 人们 的 日常 生活 中 , 们 的衣 、 、 、 人 食 住 行都 通 过 网络信 息 系
层 次 间的调 用接 口体 现 了相互 间调用 关系 :
1浏览 器访 问 : . l为 JvE aa E及 We 件提 供 的属 性 、 b组 方 法、 件 ; 事
分类信息系统以信息分类、 分类检索、 息 信 发布、 信息交易 作为主要的功能 , 实现信 息 服务。具体功能图如下图 1 所示。
1分 类信 息系统 架构 .
1 系统 架 构 . 1
留在 We b容器的程序, 负责接受来 自浏览器的请求, 珐 并i用 J
业务 规则组 件 , 将处理 结果返 回给浏览 器程 序 。数 据服 务 并
层 由关 系数 据库 系 统 、 存储 过 程组 成 , 业务 规则 处 理程 序通 过调用存 储过 程或执 行 S L来存 储或 查询数 据 。 Q
第 l 9卷 3期 2l 0 2年 9月
长 沙 民政 职 业技 术 学 院学 报
Junlo C agh oi r o ee ora f hn sa Sc lWo C lg a k l
…
vo I N( 3 1 9 I .
塑 三l 【 )
基 于 UM L的分 类 信 息 系统 研 究 与设 计
的数据 同步则 缺乏 有效 手段 。
能模块中。应用服务器层程序分为 We 请求与响应服务程 b
序 、 务规 则组 件 、 业 数据访 问组件 。 b We 请求 与响应 程序 为驻
某省移动短消息计费系统技术建议方案

某省移动短消息计费系统技术建议方案1. 引言随着移动通信技术的发展和普及,短消息成为了人们日常沟通的重要方式之一。
为了实现对短消息的计费和管理,某省计划建设一套移动短消息计费系统。
本文将提出该系统的技术建议方案,旨在满足计费系统稳定高效运行的需求。
2. 系统架构2.1 架构概述某省移动短消息计费系统采用分布式架构,由前端、后台计费处理、数据库和监听器等核心模块组成。
2.2 前端前端模块负责用户的登录、注册、短消息发送和接收等功能。
建议采用Web界面开发,用户界面友好、操作简单。
2.3 后台计费处理后台计费处理模块是整个系统的核心模块,负责对发送和接收的短消息进行计费。
建议采用分布式架构,通过消息队列来实现任务的异步处理,提高系统的计费效率。
2.4 数据库数据库模块负责存储用户信息、短消息记录和计费信息等数据。
建议采用关系型数据库,如MySQL或Oracle,保证数据的安全和一致性。
2.5 监听器监听器模块负责监听短消息的发送和接收情况,并实时更新相关的计费信息。
建议使用消息中间件来实现消息的监听和分发。
3. 技术选型3.1 开发语言建议使用Java作为系统的开发语言,Java具有良好的跨平台性和稳定性,适合大规模分布式系统的开发。
3.2 框架和中间件•前端开发框架:建议使用React或Vue.js等现代化前端开发框架,提高用户界面的开发效率和交互体验。
•后台计费处理框架:建议使用Spring Boot框架,简化后台逻辑的开发和部署工作。
•消息中间件:建议使用ActiveMQ或RabbitMQ等可靠消息中间件,确保消息的可靠传递和异步处理能力。
•数据库:建议使用MySQL或Oracle等关系型数据库。
3.3 安全性为保证数据的安全,建议在系统中使用SSL/TLS进行数据加密,并采用防火墙等网络安全设施对系统进行保护。
4. 系统流程本节将介绍某省移动短消息计费系统主要功能的流程。
4.1 用户注册和登录流程1.用户通过前端界面进行注册,输入手机号码、密码等信息。
基于UML话费批价系统的分析与设计

第
二
=
一
话 单 文件按 文 件生成 时 间命名 .如在 20 0 2年 6
月 2 日 1 : : 生 成 的 文 件 。 其 文 件 名 为 1 20 3 00
图 l 话费 批价 系统 的用 况图
克 期
v
MD NC PT 7 o OE O U R晰. R M E2
’ 过对批价 基本原理 和相关 话 费批价 系统分 析 , 通 并参考 电信业 务相关 规范 , 可得 出话费 批价 系统 的用
况 图如图 1 示 。 所
1 系统 分 析
( ) 价 的 基 本 原 理 1批
话 费 批 价 的 依 据 是 用 户 的 通 话 记 录 ( a Cl l rer ) 户 的 通 话 记 录 来 自于 数 据 采 集 系 统 。话 费 eo ̄ 。用
进 行 了 系 统 的 分 析 和 设 计 , 给 出 了 系统 的 具 体 实 现 。 并
关键词 : UML;话 费 批 价 ;用 况 图 ;序 列 图
引 言
电话 话 费批 价 系统不 仅 是 电信运 营商 运 营支 撑
系 统 ( O S 的 主 要 组 成 部 分 , 是 宾 馆 、 校 、 中 B S) 也 学 大
维普资讯
开 发 案 椤I l
各用况 uec s) 明如表 1 示 。 s ae说 所
表 1
蠢 托 蔫 避 0
…
T 邕 F o r m I
/ / /
T :t B J u t o n
I /
.
人工 入库 管 理 员选 择特 定文 件 . 进行 入库 入库 操 作 。 可单 个 或 批量 地 选 择 原 始话 单 文 件 进 行批 价 入库 处 理 , 价 中显 示 批
基于UML的计费网关的设计与实现

r t e o k d v c , a d i i e p n i l o o l ci g c a gn aa r c r o d fe e tc a gn o e , a l a i e e tp e a en t r e ie w n sr s o s e f rc l t h i g d t e o d f m i r n h i g n d s t b e n r r r swe l s d f r n r - p o e st h c i e a u h a l r c n oi a i n d s i u i n a dta se t . An ec ag n t l b u mi e e r c s t er ev d d t s c sf t , o s l to , it b t n n f r c o e a i e d r o r e d t h i g d awi es b r d t t h r a l oh
bln ytm rh n l iig iigs se f ef a l n .Th e oktp lgc l tu tr fh o i lc mm u iainc r e oki smpi e n e l o t i b l en t r oo ia rcu eo te bl t eo w o s m ee n c t o e t r i l da dt o nw s i f h
b r e f h i i g s se i d c e s d u d n o t eb l n y t m e r a e . l s
Ke r s c a gn o e c ag n ae y b l n y t m; c a g n a c r ; mo i lc m ywo d : h i gn d ; h i gg t wa ; i i g s se r r l h i gd t r o d r a e bl t e o ee
某移动公司短消息计费系统建议方案
系统实施的关键步骤
01
系统设计
02 根据需求调研结果,设计系统架构、功能模块和 数据库结构。
03 设计用户界面和操作流程,确保用户体验友好。
系统实施的关键步骤
01
系统开发与测试
02
按照系统设计文档进行开发。
进行单元测试、集成测试和系统测试,确保系统稳定和功能完
ቤተ መጻሕፍቲ ባይዱ
03
备。
系统实施的关键步骤
01 系统上线与部署
01
实时计费通知
为用户提供实时的短消息计费通 知,让用户随时了解费用情况, 增强用户信任度。
02
03
智能客服支持
个性化服务
集成智能客服系统,快速响应用 户咨询,解决用户疑问,提升用 户满意度。
根据用户需求和偏好,提供定制 化的短消息服务,如个性化推送 、提醒等。
降低运营成本
资源优化
合理配置硬件和软件资源,降低系统建设和维 护成本。
系统应具备用户通知功能,及时向用户发送计费通知和账单信 息。
新系统的技术实现
分布式架构
采用分布式架构,提高系统的 可扩展性和处理能力。
数据库优化
合理设计数据库结构,使用索 引、分区等技术优化数据库性 能。
缓存机制
引入缓存机制,减少对数据库 的频繁访问,提高系统响应速 度。
负载均衡
采用负载均衡技术,将请求分 发到多个服务器上,平衡负载
02 完成数据迁移和系统部署工作。
03
进行系统上线前的最后测试,确保系统能够正常运营
。
系统实施的关键步骤
培训与推广 组织培训课程,提高员工对短消息计费系统的操作技能。 通过各种渠道宣传推广新系统,提高用户的使用率。
基于UML的电话计费系统分析与设计
我们也可 以按照从 不同 的角度 为系统架构来 将这 9 图划分 为 5 种
种视图 :
第一类是用 例图 (s cs d ga , Ue ae i r a m)它通 常用于 表示客 户需求 。 从 用户需求 角度描述 系统功能 , 并指出各功 能的操作者 。
其 中 :e 为话 费 ; lr 主叫号码 ; l 为被叫 号码 |a a Fe cl 为 ae cl ae d srDt tt e
Tm 为通话开始时间 ;u t n ie dr i 为通话 时长 。 ao
对于 一个营业 区内的所 有电话 , 基本话费标 准批价是一致 的 , 上面
公 式可 以简化为 :
U L 统一建模语 言 。n e oe n nug) M( U i d dlg agae是一种标准化 的面 i f M i L 向对象 的图形化 建模语言 。它由图与元模型组成 , 中 的图通 常表示 其 U L的语法部分 , M 而元模型是 U L的语义部分 。 M 它通常起到解释图的含 义的作用。 图形化表示 系统各 阶段 的元素是 U L的特 色所在 。M M U L提供 了9 种不 同的图 。 按其行为特 征可以分为 两大类 , 一类是静 态图 , 包括用 例图 、 图、 类 对象 图、 组件图 、 配置 图。 另一类是 动态图 , 包括序列图 、 协作
电话计费系统不仅是电信运营商运营支撑系统(O S主要组成部 B S)
分, 也是宾馆 、 学校 、 中型企业必备的管理系统之一 。灵活性 、 大 准确性 、 实 时性是它的生命 。 U L 为面向对象分析与设计的一种标准表示 。 而 M 作 其最终用途是为不同领域的人们提供统一的交流标准 。 电话计费系统 在 中运用 U L M 有助于解决 系统开发过程中各类人员( 系统架构师 , 软件设 计人员 、 开发人员 、 客户 、 用户 ) 之间相互交流困难的难题 , 从而建立起一 个具有灵活性、 准确性 、 时性 的系统 。 实 电话计费系统按 照电信业务规范 可 以划分为数据采集 、 话费批 价 、 账务处理 3 个主要系统 , 而每一个系统 又可以分若干个 子系统 。笔者主要论述基于 U L的电话计费系统的分 M 析与设计 。
机房收费系统的UML建模设计
机房收费系统的UML建模设计机房收费系统的UML建模设计1、需求分析描述a)机房收费系统是使⽤计算机实现学⽣上下机以及收费⼤量信息处理的电⼦收费系统。
在本系统中主要满⾜上机学⽣、⼀般⽤户、操作员和系统管理员4个⽅⾯的需求。
对于上机学⽣来说主要是上机、下机、查询个⼈信息;⼀般⽤户负责学⽣上下机的操作和学⽣余额查看、学⽣上机记录查询、学⽣上机状态查询、学⽣充值记录查询以及修改密码;操作员负责注册、充值、退卡、收取⾦额查询、⾦额退还查询、学⽣基本信息维护、学⽣上机统计信息查询、操作员⼯作记录查询和⼀般⽤户的所有操作;对于系统管理员主要负责结账、添加删除⽤户、系统的基本数据设定、正在值班教师查询、⽇结周结账单、⼀般⽤户的所有操作、收取⾦额查询、⾦额退还信息查询、学⽣基本信息维护、学⽣上机统计信息查询、操作员⼯记录查询和系统状态维护等。
2、模型建⽴a)⽤例模型的建⽴本系统共设置了五个活动者,分别是JF_People 、JF_SystemRegistrar、JF_Student、 JF_CommonRegistrar 和JF_Database。
其中JF_People泛指与系统发⽣关系的⼈;JF_SystemRegistrar为系统管理员,负责添加删除⽤户等;JF_Student为所有来上机的学⽣;JF_CommonRegistrar为普通管理员,负责学⽣注册、充值和退卡等操作;JF_Database为存储各种信息的数据库对象。
另:考虑到现实机房中还存在“⼀般⽤户”这⼀⾓⾊,但其所起的作⽤仅为替上下机学⽣完成各种系统操作,故没有设置此活动者。
本系统共有⼆⼗个⽤例:(上机)、DownLine(下机)、CheckStuMoney(查看学⽣余额)、(查看学⽣上机记录)、(学⽣上机状态查询)、(学⽣充值记录)、(修改⽤户密码)、(注册)、ReCharge(充值)、(退卡)、ChkCollectMoney(收取⾦额查询)、(⾦额退还信息查询)、(学⽣基本信息维护)、StudentOnLineChk(学⽣上机统计信息查询)、WorkerLogChk(操作员⼯作记录查询)、Reckoning(结账)、(添加删除⽤户)、SetBasicData(基本数据设定)、OnWorkTeacher(正在值班的教师)、(⽇结和周结账单)。
预订机票系统用例说明UML
(1)旅客登录航班预订系统(2)系统提示输入姓名性别电话身份证号出发站和到达站、出发时间(3)旅客输人姓名性别电话身份证号出发站和到达站、出发时。
(4)系统显示航班清单及预订费用和全额票价。
A 1:没有这个肮班(5)旅客选择要订的航斑。
(6)系统显示这个航斑的所有票价选项以及机票信息。
A2 :没有自己想要适宜机票(7)旅客选择要订的票价选项。
(8)系统确认预订费用和票价以及机票信息。
(9)旅客确认预订费用和票价以及机票信息(10)系统提示输入信用卡类型、密码、姓名和有效期。
(11)旅客输人信用卡类型、号码、姓名和有效期。
(12)系统提交信用卡购买机票。
A3 :账号找不到A4 :资金不足E1:无法访问信用系统(13)系统收取预订费用,并为该用旅客预订机票。
(14)系统打印取票通知和机票账单。
(15)旅客确认收到取票通知和机票账单。
(16)旅客在有效期里,登录预订机票系统,并提交取票通知信息(系统会提前一天以短信的形式通知取票)A5 :航空公司更改航班A9 :航空公司取消航班A10 :旅客更改机票??A??:旅客未在有效期里领取机票(17)系统提交取票通知信息A11 :取票通知信息错误(18)系统确认取票通知信息,并显示机票账单(19)旅客确认账单信息(20)系统提示输入信用卡类型、密码、姓名和有效期。
(21)旅客输人信用卡类型、号码、姓名和有效期。
(22)系统提交信用卡购买机票。
A3 :账号找不到A4 :资金不足E1:无法访问信用系统(23)系统收取及机票费用,并打印取票通知和机票账单。
(24)旅客取票,用例结束!AI:没有这个航班(1)系统显示信息,没有所输入出发站和到达站、出发时间的航班。
(2)旅客确认消息。
(3)返回二仁事件流第2步A2:没有自己想要适宜机票(1)旅客查看机票信息,没有适宜机票(2)返回主事件流第4步A3:账号找不到(1)系统显示账号找不到的消息。
(2)返回主事件流第10步。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
接下 来对 主要用 例进 行描 述 如表 1所示 。
表 1 各 用 例 描 述 表
艟僧息数撮采囊 崔舟l 户 的琏信发送并接牧硪功后 相 鞋的 件设备就畲特娘侮的发进时间、来濠、目
的毒碑疆其体内 孰 硪藤始话蕈 也赣走所请的疆佰 “ 场 ”{ 8 囊。 计蕾期价镬块的工作方贰燕宾时的 它丰 囊 撂童诲幕境 中韵当户德急.确定窨户的胀户氽
5 %. 1 0 %. 另一个 是 满足 每人 每小 时 4 O个 立方 米 。 在 网络 中心机 房 系统 建设 完 成后 , 应 当做好 工 程 的 验 收工 作 。 医 院 的有关 信息 管理 部 门要组 织信 息化 方 面 的专 业 人员 和 专家 , 或者 本单 位 的专 业技 术 职 工进行 技 术 评价 和评 估 . 根 据 系统 的设 计 要求 和标 准 认 真 的核实 其 各项 技 术指 标 。对 于 和工 程有 关 的各 种施 工 图 、 设 计 书、 设 备 说 明书 等 医院要 组 织专 门的人 员 给予 保存 和管 理. 方 便 以后 系统 的维 护 和检查 工作 。
通 过计 费 划价 处 理 , 就 能得 出客户 本 次短 信 的费 用
【 下转第 8 5页 】
信 息 安全 与技 术 ・ 2 0 1 3年 8月 ・ 7 9・
网 络 通信 ・ 信 息技 术 ・ I n f o r m a t i o n T e c h n o l o g y
的 除尘 能 力 , 当 机 房温 度 增 加 时 , 其 备 份 机 能够 自动 的 进行 工作 , 满 足机 房 温度 控制 的要 求 。同时机 房 年 的通 风 系统 也非 常 的重 要 . 通 风 系统 可 以保证 并且 提 高机 房 里的清洁 , 使 机 房 能 够保 证 正 常 的 大气 压 力 , 提供 新 鲜 医 院 的正常运 行 和工作 提供 支 持 。 在对 医院 网络 中心机
, 搴 业秀供囱 靠 分析资赞暮餐瑶善的具体埔 提供相楚I 靛 据,笄对用户定崩的瓷赞喜
磕德患业务辐震 餐疑毒譬羹用发生慵况的散豫避行摄取.怖避,儿而晒啦瞒式化的嗡出文件 , Y - 、对用 户定啊的套餐进忭分析疑分解,得到暂午账舜处理蟪则,拣后撤据擐殚I } l 蝴执行的峨牟
饿次进行啡舟处理・
3 . 2系统用例图
曼 一
蕞 缡 避 墟 人 受
图 3
( = )
t 谨 墨
一
撼f l诺 ●文 件
户
图 4
-
H
l l甩 卢
童诲辩 蟪
图 2 短 信 息 系 统 用 单 , 除 了以上 之 外 , 该模 块 处 理 的信 息 还
能 提 供 给账 务 处 理 、 查 询等 模 块 使用 , 从 而 达 到 资源 共 享、 减 少 系统 开销 的 目的 。
房 工程 建设 时 要进 行精 密 的设 计 ,精心 的 准备 和安 排 ,
高 质 量 的安 装 , 提 高 网络 设 备 的运 行 安 全 和效 率 , 减 少 故 障 的发 生 ,避免 因 为设 备损 坏等 而 带来 应用 的 风险 ,
的空气 . 减 少 机房 卫 生条 件对 人 健康 的影 响。通 风 的设 备应 当满足 两个 条 件 , 一 个是 应 当 占空调 系统 总风量 的
系 大 多 为扩 展 关 系 。信 息 采 集 可进 一 步 细 分 为信 息 中
心 话 单 、互 联 网短信 网关 话 单 采集 和短 信 话单 文 件 三
个 子用 例 。
3 . 4类图关系
3 . 5短消息计费系统的模块结构实现
以上 就是 我们 构 建 的一个 短 信 息计 费系 统 。 在 此基 础上 . 我 们 可 以将 该 系 统分 为 以七 大 模 块 , 具体如图 3 所示 , 主要模 块 的功 能可 以见前 文 的分析 。
通过 上 面 的用 例 图我 们可 以看 到 , 运维 、 业 务 管理 、
一
般 短信 客户 、 市 场 拓 展都 属 于 系统 执 行 者 , 而短 信 话
单 来源 和 GS M 计 费 系统 也包 涵 其 中 。而系 统 的功 能需 求主要是信息采集 、 计 费 划价 、 账 务等 , 它 们 之 间 的关
软硬 件・ 信息技术 ・ I n f o r m a t i o n T e c h n o l o g y
短 消息 业务 运 营模 型 , 我 们重 点 要完 成短 消 息业 务 以及
增值 业 务等 多种 业务 模式 的综 合计 费 功能 。 而 原来 的短
信 系 计 费 系统 存 在 的 问题 : 计 费 功 能 简单 、 对 系 统 的实 时 性 要 求低 、 无 法 适 应 多格 式 话 单 、 数 据量 剧 增 带来 的 数 据压 力 。 基 于 以上 问题 , 对 系统 提 出了新 的需 求 : ( 1 ) 计 费数 据 格式 需要 统 一 ; ( 2 ) 在 同一计 费平 台实 现 多种 业务 多 种 计 费 的整 合 ; ( 3 ) 实现 对 预付 费用户 的实 时扣 费 。
艟僖惠计葛划价 鞭 ( 臻付费方式)或德用龋鹿 ( 剧 舞方式),按照远酾 j | I 定的相*舞鞭 短僖的鼻 体情况 ( 如桶 大小)采计算用户的随借息盘用,^ L l i 可 彤硪详捆账单. 完硪对霉蠹详瓣 簟者捷 述鞭旁・封计糟划价后产生的费闱信息捷隐电子账单鲍黟
~ 蟊
琏 值 息 雠 务
4 结束语
3 . 3业务流程描述
后 台操 作 人 员启 动计 费 划价 处 理 , 其 工作 流程 如 图 3所 示 。
目 前全球每个月的短信息数量已 达到1 5 0 亿条。 而在
短信息 服务 开通较 早 的欧洲 ,每天发 送 的短 信息 数量 是 2 0 0 0万条 , GS M 运 营商 8 %~2 0 %的收入来 自短信息 。
嚣
冀
一 钎 ~ 一 一
短健 急管 理配基 包 括了: 0罔 络监 控} 蛮臂 勰能 避掇, 0告 警管 瑗l 固蔡 境自舟 管理, 国用 户 榱鼹疑 安
盒f理J固目寒l 阿 j 0连行雏护_ 理。
翘 伯 息 计 墨 错 l
一
篙 是 嚣 镯
、
嚣 嚣
娥
图 5 短消 息计 费结 算 系统模 块关 系 图