一.市场分析
随互联网的不断发展,人们对于通信需求不断增加,通信服务的需求日益增长。 用户对于个性化、灵活的通信套餐有更高的要求,希望能够根据自己的使用习惯和需求定制服务。嗖嗖移动业务大厅的目标用户可能包括学生、上班族、商务人士等不同群体,他们对通信服务的需求各有侧重。
二.用户需求分析(市场需求分析)
用户核心需求:手机卡号办理功能,手机充值功能,余额查询功能,套餐办理与更换功能。
三.系统设计
1.用户登录:用户登录需要判断账户的账户密码是否正确
如果正确查询它的状态:如果处于欠费冻结状态,则无法登录
登录后进入二级系统
2.用户注册:注册时输入注册名
查询未注册的电话号码,打印出来让顾客选择
选择注册账户后
打印套餐,让顾客选择套餐
选择套餐后进行充值 注:充值的金额不能小于套餐金额
充值后扣除套餐金额。
录入充值系统使其有一个充值记录,并把此手机号变为无法注册的状态
3.使用嗖嗖:模拟使用场景
1).输入使用的号码,先判断是否被冻结,如果被冻结则无法使用该功能
2).模拟现实使用状态:使用的功能:1.通话 2.短信 3.上网
根据使用的功能不同进行不同的数据传输修改
3)模拟对象:请选择你要打电话的人:1.客户 2.妈妈
4)根据顾客要使用的场景查找模拟场景的内容,提供消费时长与消费类型
5)添加消费记录:判断是否有月消费记录,没有则新增月消费记录,有则修改消费记录。
6)计算是否超过套餐数据如果超过则扣钱
7)打印场景内容
4.话费充值:可以给别人充值:
1)输入充值账号 与充值金额
2)调用充值方法,判断是否充值成功
5.资费说明:查询相关套餐
品牌套餐 | 话痨套餐 | 网虫套餐 | 超人套餐 |
---|---|---|---|
通话时长(分钟) | 600 | 0 | 300 |
上网流量 | 0 | 20 | 10 |
短信条数(条) | 100 | 0 | 50 |
费用(元/月) | 58 | 68 | 78 |
6.本月账单查询: 1)查询套餐的资费
2)根据查询超出套餐所花的钱
3)把1和2合计展示出来
3)查询套餐的账户余额
注:查时要根据顾客现有的套餐类型进行查询
7.套餐余量查询: 1)查询套餐,与月消费记录
2)进行比较
3)如果超额打印超额的,如果剩余打印剩余的
8.打印消费详单 1)根据月份且在本年内进行查询消费详单
2)如果没有打印没有记录,有就打印出来
3)把相关的记录放入文件中
9.套餐变更 1)查询所有套餐,打印套餐内容
2)顾客选择套餐后进行判断如果是本来的套餐就不需要更改,如果不是就可以继续更改
3)更改前查询卡中余额是否足够更改为现有套餐,如果不够,先进行充值,余额足够后进行更改
4)更改套餐后新增一个月消费账单
10.办理退网 1)再次确认是否退网
2)查询当前余额,如果余额<0则需要补交话费
3)余额>0后开始删除相关数据
4)删除嗖嗖卡的数据
删除消费记录
删除月消费记录
5)把号码变为可选状态
四.根据设计分析设计数据库表
Tb_Card(选电话号码表)
要求 | 备注 | ||||||
1 | Id | Int | 否 | 无 | 主键,自增 | 主键 | |
1 | CardNumber | char | 11 | 否 | 无 | 唯一,关联 | 电话号码 |
2 | status | Int | 2 | 否 | 默认0 | 0可选1不可选 | 状态 |
tb_serpackage_type(套餐类型)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 11 | 否 | 主键,自增 | Id | |
2 | name | varchar | 50 | 否 | NULL | 套餐类型名称 | |
3 | type | Int(2) | 6 | 否 | NULL | 套餐类型 |
tb_serpackage(套餐)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | talk_time | Int | 6 | 否 | NULL | 通话时长 | |
3 | sms_count | Int | 6 | 否 | NULL | 短信条数 | |
5 | flow | Int | 6 | 否 | NULL | 上网流量 | |
4 | price | Double | 7,2 | 否 | NULL | 套餐月资费 | |
6 | type | Int(2) | 6 | 否 | NULL | 套餐类型 |
Tb_Mobole_Card(嗖嗖移动卡表)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | card_number | char | 11 | 否 | 外键,关联,唯一 | 手机号码 | |
3 | ser_package | Int | 2 | 否 | 外键,关联tb_serpackage | 所属套餐 | |
4 | Username | Vachar | 11 | 否 | 用户名 | ||
5 | Password | Vachar | 12 | 否 | 密码 | ||
7 | Money | double | 7,2 | 否 | 0 | 账户余额 | |
8 | status | Int | 1 | 否 | 0 | 0-正常,1-冻结 | 状态 |
Tb_monthly_consumption_records(月消费记录表)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | card_number | char | 11 | 否 | 外键,关联,唯一 | 手机号码 | |
3 | Consum_Amount | Int | 2 | 否 | 0 | 所属套餐 | |
4 | Real_Talk_Time | int | 6 | 0 | 当月实际通话时长 | ||
5 | Real_SMSCount | int | 6 | 0 | 当月实际发送短信条数 | ||
6 | Real_Flow | Int | 6 | 0 | 当月实际上网流量 | ||
7 | ConsumeDate | Date | 否 | 消费日期 |
tb_recharge_record(充值记录)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | card_number | char | 11 | 否 | 外键,关联,唯一 | 手机号码 | |
3 | amount | double | 7,2 | 否 | 充值金额 | ||
4 | recharge_date | date | 6 | NULL | 充值时间 |
tb_consuminfo(消费记录)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | card_number | char | 11 | 否 | 关联,唯一 | 手机号码 | |
3 | type | varchar | 50 | 否 | Null | 消费类型 | |
4 | consum_data | int | 6 | NULL | 消费数据 | ||
5 | consume_date | date | Null | 消费日期 |
tb_scene(模拟场景)
序号 | 字段名 | 数据类型 | 长度 | 是否为null | 默认值 | 要求 | 备注 |
1 | Id | Int | 否 | 主键,自增 | Id | ||
2 | type | char | 30 | 否 | NULL | 场景类型 | |
3 | data | Int | 6 | 否 | NULL | 场景类型序号 | |
4 | description | Double | 7,2 | 否 | NULL | 场景描述 |
五.系统开发设计
1.使用三层架构
方法设计,数据传输设计,表示层表示。项目使用 Java 语言开发,通过JDBC操作 MySQL 数据库对数据“增、删、改、查”。项目代码结构清晰,功能完善,能够满足用户的基本需求。
五.项目展示试用,改bug,完善系统
由于篇幅原因,略
六.总结
三层架构的理解:三层架构是一种软件设计模式,它将应用程序分解为三个主要部分,每部分都有其特定的职责和功能。表示层是用户与程序所交互的界面,它负责用户的输入,显示数据给用户,处理用户界面的逻辑。业务逻辑层,首先它是一个中间层,用于接收,传输表示层与数据访问层的数据,进行数据处理,进行计算、验证和转换,确保数据的准确性和一致性。数据访问层通过条件查询数据发送数据,三个部分各分其职,能使系统设计完善,数据不那么冗余。
目前设计的缺陷:1业务逻辑层没有任何数据处理方法,反而放到了用户表示层,使此层许多代码冗余,不利于修改完善。2系统不太贯通,应该让设计的系统连贯起来。