工程实践需求分析与概念原型——世界多同屏游戏后台云原生实践
前言
本文结合软件工程课堂上学习到的需求分析与建模知识针对工程实践项目进行概念原型设计,主要包括用例建模、业务领域建模、数据建模等内容。
一、工程实践项目背景
本人的工程实践项目是设计并实现一款多人在线同屏游戏的后台服务器,要求在包含登录注册、数据存储等核心功能的基础上要实现多玩家间的实时交互。需要使用Kubernetes平台进行云环境的容器化部署,保证无单点故障与容灾备份。
二、用例建模
什么是用例?用例(use case)是软件工程或系统工程中对系统如何反应外界请求的描述,是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其它系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标。
什么是好的用例?标准的用例应该含有以下要素:
- 用例应该由业务内的某个参与者所触发
- 用例必须能为特定的参与者完成一个特定的业务任务
- 用例必须终止于某个特定参与者,也就是特定参与者明确地或者隐含地得到了业务任务完成的结果。
- 描述了满足业务目标的业务活动
- 没有涉及特定的实现语言
- 要求合适的细节级别
- 足够短,使得在一次发布中能够被一个软件开发人员实现
怎样设计好的用例?
- 从需求表述中找出用例,往往是动名词短语表示的抽象用例;
- 描述用例开始和结束的状态,用TUCBW和TUCEW表示的高层用例;
- 对用例按照子系统或不同的方面进行分类,描述用例与用例、用例与参与者之间的上下文关系,并画出用例图;
- 分析用例与参与者的详细交互过程,完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
下面开始结合工程实践项目进行用例建模:
2.1 抓取用例
结合项目背景与项目描述,分析出用例如下:
- (账号注册、登录、登出、充值)
- (游戏房间创建、匹配加入、游戏战斗)
- (同服聊天、断线重连)
- (游戏记录保存、账号信息保存)
2.2 用例图绘制
2.3 用例交互流程
| 用户:玩家 | 系统:游戏服务器 |
|---|---|
| 发出账号注册请求,传递账号、昵称、密码 | 返回注册结果(成功、失败) |
| 发出账号登录请求 | 返回登录结果、角色信息 |
| 返回心跳消息包 | 发出断线重连检测 |
| 发出/接收聊天信息 | 推送/接收聊天信息 |
| 发出创建房间请求 | 返回创建结果 |
| 接收游戏实时数据 | 推送游戏实时数据 |
三、业务领域建模
什么事业务领域建模?业务建模(Domain Modeling)是以软件模型方式描述企业管理和业务所涉及的对象和要素、以及它们的属性、行为和彼此关系,业务建模强调以体系的方式来理解、设计和构架企业信息系统。业务中的名词术语或者短语可能是类或者类的属性,要学会准确的识别他们的定位以及处理他们之间的关系。类与类之间可以有继承、组合、关联等关系。
下面结合工程实践项目来进行业务领域建模:
3.1 收集游戏中的业务信息
通过搜寻互联网信息与进行游戏体验,得到基本的游戏中的元素有:账号、角色、充值信息、游戏房间、地图等。
3.2 业务信息具体化
进一步对搜集到的业务信息进行进一步的设计,识别哪些是类(class)哪些是属性(attribute),并设计出类中必要的属性,使得游戏系统更加具体。
账号(标识id、账号名、密码、加密算法、渠道方、充值信息、绑定角色id、注册时间、最近登录时间、最近登录地点...)
充值信息(订单号、充值类型、充值渠道、充值金额、生效角色id...)
角色(角色id、角色昵称、角色状态、角色余额...)
房间(房间id,角色集合,创建时间、开始时间、销毁时间...)
地图(角色集合、怪物刷新坐标、怪物刷新时间、道具刷新坐标、道具刷新时间...)
3.3 UML类图绘制
四、数据建模
账号登录模块
账号
| 属性名 | 类型 | 唯一标识 | 备注说明 |
|---|---|---|---|
| accountId | long | yes | 账号标识id |
| account | size_128 | no | 账号名 |
| pwd | size_128 | no | 密码 |
| appId | size_128 | no | 所属渠道标识id |
| chargeInfos | chargeInfo* | no | 充值信息 |
角色
| 属性名 | 类型 | 唯一标识 | 备注说明 |
|---|---|---|---|
| roleId | long | yes | 角色标识id |
| name | size_128 | no | 角色昵称 |
| state | int | no | 角色状态(在线、离线、封禁) |
| moneyCnt | double | no | 角色游戏币余额 |
战斗模块
游戏房间
| 属性名 | 类型 | 唯一标识 | 备注说明 |
|---|---|---|---|
| chamberId | long | yes | 游戏房间标识id |
| roles | vector |
no | 房间内玩家集合 |
| createTime | time_info | no | 房间创建时间 |
| destroyTime | time_info | no | 房间销毁时间 |
战斗模块函数
| 函数名 | 参数列表(类型+名称) | 返回值 | 备注说明 |
|---|---|---|---|
| createChamber | long roleId | int result | 传入房主id,返回创建结果 |
| rolesInfoSync | null | vector |
房间内玩家状态信息同步(位置同步、状态同步等) |
| accountChamber | null | null | 房间内对战结算 |
地图
| 属性名 | 类型 | 唯一标识 | 备注说明 |
|---|---|---|---|
| mapId | long | yes | 地图标识id |
| roles | vector |
no | 地图内玩家集合 |
| pveRefreshInfo | PveInfo | no | 怪物刷新信息 |
| itemRefreshInfo | Item_info | no | 道具刷新信息 |
五、概念原型及工作过程
概念原型是一种虚拟的、理想化的软件产品形式,就像一个建一栋房子要进行框架设计、造型设计、受力分析等等一系列抽象的设计才开始动工一样,软件设计的概念原型亦是如此,用例+数据模型=概念原型。经过上述一系列的概念原型设计以后,下面简述一下本项目概念原型的工作过程:
用户可以通过各个渠道方直接创建角色或者先创建账号再创建角色,将角色绑定到账号以后就可以进行游戏登陆了,登录后能够拉取到自己的角色信息(等级、物品、对战记录等),
可以在角色当前地图中查看其它玩家的状态并可以通过私聊与公聊的方式交流。除此之外能够创建对战房间,通过邀请或者匹配玩家的方式开始游戏,游戏中玩家能够看到其它玩家的
对局状态信息(位置、血量、速度等),游戏结束后会进行结算,对局记录会保存到服务器端供玩家回看。游戏过程中出现网络波动会自动重连,游戏结束玩家点击登出即可下线。
总结
本文通过软件工程课堂上学习的知识进行用例建模和业务领域建模,以及数据建模,最终形成概念原型,提升了自己的需求分析和概念原型设计的能力与软件工程专业素养。通过这次课程,让我能够更加抽象的对工程实践项目进行规范的设计而不是随意的堆叠,对工程实践项目的推动很有帮助。

浙公网安备 33010602011771号