在游戏设计中进行需求分析并提取概念原型

一．前言

　　在最近的高级软件工程课程中，学习到了一种敏捷统一过程的基本建模方法，从需求分析到软件设计的基本方法。为什么如此注重需求分析和用例建模呢？正所谓“不重视需求过程的项目团队将自食其果”。需求分析是产品研发前期的铺垫工作，也是重要的基础工作之一。需求工作中的缺陷将给项目成果带来极大风险，在推出产品时，体现在质量、功能、场景等情境下影响着用户的满意度和期望值。那么我们又为何要进行用例建模呢？因为用例建模很容易成为开发人员之间交流和沟通的媒介，用例模型可以精确地定义软件需求，出现歧义的可能性很小，这可以保证用户和开发人员对需求理解的一致性，并且用例模型可以成为我们评估压法工作量的一个标准，特别是对于迭代式开发言。迭代式开发模型里，通常依据用例模型来划分软件的开发周期：优先级别高的用例会在早期的迭代周期中实现，而优先级别低的用例则被安排在后续的迭代周期中完成。可以通过限制每个迭代周期中的用例个数来保证迭代周期长度的合理性。其次用例模型在整个开发过程中都扮演着非常重要的角色，它可以驱动软件的分析和设计逐步细化。最重要的是测试过程中使用的测试用例，特别是那些关注软件功能的测试用例，也是根据用例模型来确定的。

　　本文将结合我的工程实践项目，进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。将所学知识运用到实践中，更好的理解这种软件开发过程。我的工程实践项目是基于物理仿真的游戏实践。物理仿真是指用游戏中的一些技术实现现实生活中的一些效果，比如：流体模拟，非四轮载具模拟，如摩托车、坦克、直升机，物理破坏，如地形／建筑爆破、刚体破碎、衣服／防具破裂，物体燃烧传播、扑熄，异常时间玩法，异常空间玩法等使用UE4 游戏引擎作为工具；使用物理仿真的方法来实现游戏中的特殊效果；并且结合技术和创意游戏玩法；实现物理仿真技术项目。下面就让我们开始吧！

参考文献：https://gitee.com/mengning997/se/blob/master/README.md

二．需求分析

2.1 什么是需求分析

　　在进行需求分析之前我们应该了解什么是需求分析。需求分析指的是在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作，其中包括考虑来自不同利益相关者的需求，确认是否冲突，在冲突的需求之间进行取舍，并针对软件需求及系统需求进行分析、记录、确认以及管理。需求分析是软件项目或系统项目中的关键过程，关系项目的成败。理想的需求要整理成文件、可以运行、可以量测、可以测试、可以追踪、和识别到的商业的需求或机会有关，而且要有系统设计的相关设计细节。

　　简单的来说需求就是对用户期望的软件行为的表述；获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作；需求分析是在获取需求的基础上进一步对软件涉及的对象或实体的状态、特征和行为进行准确描述或建模的工作。

2.2 需求分析的必要性

　　为什么在软件开发中大家总是如此的强调需求分析呢？在软件工程中，需求分析指的是在建立一个新的或改变一个现存的电脑系统时描写新系统的目的、范围、定义和功能时所要做的所有的工作。需求分析是软件工程中的一个关键过程。在这个过程中，系统分析员和软件工程师确定顾客的需要。只有在确定了这些需要后他们才能够分析和寻求新系统的解决方法。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中最简单的一个步骤，但在过去十年中越来越多的人认识到它是整个过程中最关键的一个过程。假如在需求分析时分析者们未能正确地认识到顾客的需要的话，那么最后的软件实际上不可能达到顾客的需要，或者软件无法在规定的时间里完工。

　　需求分析是产品研发前期的铺垫工作，也是重要的基础工作之一。需求工作中的缺陷将给项目成果带来极大风险，在推出产品时，体现在质量、功能、场景等情境下影响着用户的满意度和期望值。前期没有任何一项站得住脚的用户需求分析，领导经常不明白为什么收集和确保需求质量需要花费那么多时间。开发人员可能也不重视用户的参与。大部分情况下，开发人员感觉与用户接触不如埋头写代码、推出新功能代替不足来得效率。某些情况下是因为条件和环境因素而无法获取来自终端用户、典型用户的需求分析，以至于无法预计产品最终上线时的应用情景，方向容易走偏，习惯上线后才根据真实用户的主动反馈进行被动变更，似是减轻前期成本投入，其实隐形成本已尽透支，这时除了不断的用更多的成本填补之前的漏缺也别无他法。应尽早让具有代表性的用户在项目早起用户的期望值也在逐步减少。

　　产品和开发人员在实践过程中也能感觉到，在前期若无足够的用户参与，产品人员获得的需求是片面的，不完整的。而开发人员意识到这样的程序在开发之初就埋下了风险，因为随着市场和用户的需求不断增加，在开发中若不断补充需求，项目就越变越庞大以致超过其预算范围。计划就不足以对项目的规模和复杂性、风险、开发周期及需求变更进行合理预估，这使得问题更难解决。产品开发中不断延续的变更会使其结构日见紊乱，补丁代码也使得整个程序难以理解和维护。如果你尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。

2.3 获取需求的方法

　　既然需求分析如此重要，那么我们该通过什么方法来获取项目的需求呢？下面将列举几个获取需求的主要方法：

```
与客户积极主动的沟通与交流
```
```
查看可用的文档
```

查看市面上有相似的系统，进行吸收和改变

与用户一起学习以更详细地了解用户的任务

```
分别与客户和用户进行交流
```

使用特定于领域的策略，例如联合应用程序设计

与现有和潜在用户进行头脑风暴

2.4 游戏项目中的需求分析

　　一款游戏项目的确立是建立在各种各样的需求上面的，这种需求往往来自于玩家的实际需求，玩家的实际需求也就是说市场需求最为重要。面对对游戏拥有不同知识和理解层面的玩家，项目的负责人(或者游戏制作人)对玩家需求的理解程度，在很大程度上决定了此类游戏开发项目的成败。因此如何更好地的了解、分析、明确玩家需求，并且能够准确、清晰以文档的形式表达给参与项目开发的每个成员，保证开发过程按照满足玩家需求为目的正确项目开发方向进行，是每个游戏开发项目管理者需要面对的问题。考虑到性能要求，不使用传统的基于力的物理模拟技术，而是直接计算位置（PBD，物理模拟精度会有一定程度下降，但表现效果不会差太多）。预计上述技术可用于模拟蛇和水人（考虑到水具有张力，或许模拟水人的效果比沙人更好）

　　那么我们应该完成一款什么样的游戏呢？游戏功能描述主要包括以下内容：

游戏背景，类型，基本功能：以蛇或者沙人的物理仿真为主，游戏性可以在完成主要的物理仿真之后再完成。
游戏玩家主界面（初步）：实现3D蛇的爬行以及物理场景（如森林）的模拟。
游戏运行的软硬件环境：通过Unreal4游戏引擎进行开发，可以实现电脑与手机的同时开发。
游戏系统机制的定义：以物理仿真技术为主，最大程度上复现真实世界上的蛇类爬行。
游戏系统的创新特性：市面上比较少有真实的蛇类模拟游戏，可以在物理仿真的基础上，最大限度实现真实的蛇类模拟。
确定游戏运营维护的要求：随着项目的进展，不断完善游戏的功能。完成蛇的物理仿真之后，可以加入沙人或水人等其他游戏线。
确定游戏服务器架设和带宽要求：使用physx物理引擎，和Ue4进行游戏开发。
游戏总体风格及美术效果标准：偏向真实世界模拟。
游戏等级及技能，物品，任务，场景等的大概数量：可以实现3D的贪吃蛇游戏，玩家通过移动角色到指定位置来不断提高等级。
开发管理及任务分配：目前准备物理仿真方面每个人都能参加，其他场景的渲染可以分类分工合作。
各种游戏特殊效果及其数量：关键点在于实现游戏中的物理模拟，了解物理模拟技术复现现实生活中的场景。

三. 用例建模

3.1 用例的概念

　　我们在完成了需求分析之后就可以进行用例建模了。要进行用例建模我们首先需要了解什么是用例。用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。用例的信息流特征：从待开发软件外部到待开发软件内部，然后又到待开发软件外部，这从最高层级抽象地为我们提供一个信息流特征的视角，用来从整体上把握待开发软件的内外关系。

用例模型主要由以下模型组成：

参与者(Actor)：参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。
用例(Use Case)：用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
通讯关联(Communication Association)：通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。
系统边界(System Boundary)：为了使得各个用例与子系统之间的关系更加明确，通常会使用一个系统边界来表达一个子系统所包围的用例范围。

在准确理解用例概念的基础上，我们可以进一步将用例划分为三个抽象层级：

抽象用例（Abstract use case）。只要用一个干什么、做什么或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
高层用例（High level use case）。需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么时候什么地方结束；
扩展用例（Expanded use case）。需要将参与者和待开发软件系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

3.2 如何进行用例建模

　　了解了什么是用例模型之后，我们就可以进一步学习如何进行用例建模了：

第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态，用TUCBW和TUCEW表示的高层用例；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。
其中第一步到第三步是计划阶段，第四步是增量实现阶段。

　　我们如何准确的提取用例呢？

第一步，从需求中寻找业务领域相关的动名词和动名词短语，比如做什么事、什么事情必须被完成，或者执行某任务等；
第二步，验证这些业务领域相关的动名词和动名词短语到底是不是用例。验证业务领域相关的动名词或动名词短语是不是用例的标准是满足四个必要条件：
• 必要条件一：它是不是一个业务过程？
• 必要条件二：它是不是由某个参与者触发开始？
• 必要条件三：它是不是显式地或隐式地终止于某个参与者？
• 必要条件四：它是不是为某个参与者完成了有用的业务工作？
如果以上四个必要条件都满足的话，那么该业务领域相关的动名词或动名词短语就是一个用例。
第三步：在需求中识别出参与者、系统或子系统。
• 参与者会触发某个用例开始，用例也会显式地或隐式地终止于某个参与者；
• 用例会属于系统或子系统。

3.3 游戏开发中的用例建模

　　既然知道了什么是用例模型，以及如果进行用例建模。那么我们就能够将所学知识运用到实践中了。下面是用例图展示：

图1 主菜单用例图

图2 游戏内用例设计

图3 游戏场景渲染与角色控制

四. 业务领域建模

4.1 业务领域建模的概念

　　什么是业务领域建模呢？这是我在高级软件工程课程上学习到的新知识。业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。

　　因此业务领域建模有助于开发团队获取业务领域知识形成统一的业务认知。开发团队获取业务领域知识的过程一般包括收集业务领域相关信息、执行团队头脑风暴、对业务领域相关的知识概念进行分类，最后用UML类图将业务领域知识图形化展示。

　　经过头脑风暴按照识别规则将业务领域内的信息提取出来之后，我们需要进一步对这些信息进行面向对象分析，将其归类为类、属性，以及类之间的关系。业务领域概念分类的方法如下：

名词和名词短语（nouns / noun phrases）可能是类或者属性；
Y 的 X（X of Y）表达方法，可能X是Y的属性，也可能X是关联关系中的一个参与者，比如中国科学技术大学的小王同学；
及物动词（transitive verbs）往往意味着关联关系；
形容词（adjectives）一般是属性值；
数量词（numeric）往往意味着属性或者属性值； •
所有关系的表达方法（possession expressions）很可能是聚合关系，也可能是属性；
构成关系的表达方法（constituents / “part of" expressions）一般是聚合关系；
包含关系的表达方法（containment / containing expressions）一般表示关联关系或者聚合关系；
•”X 是一种/类 Y“（X is a Y）表达方法一般是继承关系；

4.2 如何进行业务领域建模

进行业务领域建模的步骤通常如下：

第一步，收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
第二步，头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
第三步，给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
第四步，将结果用 UML 类图画出来。第一步更多地在获取需求的阶段已经完成，这里不做赘述；

　　在第二步中我们提到了头脑风暴，那么我们如何在头脑风暴中提取业务领域相关的概念呢？团队成员聚在一起执行头脑风暴从收集的应用业务领域的信息中按规则识别业务领域相关的概念，并分别列出。需要识别的规则如下：

名词和名词短语（nouns / noun phrases）；
“Y 的 X”（X of Y）表达方法，比如汽车的颜色；
及物动词（transitive verbs）；
形容词（adjectives）；
数量词（numeric）；
所有关系的表达方法（possession expressions），比如具有、拥有等；
构成关系的表达方法（constituents / “part of" expressions）；
包含关系的表达方法（containment / containing expressions）；
”X 是一种/类 Y“（X is a Y）表达方法，比如汽车是一种车辆；

4.3 游戏项目中的UML类图

　　在完成业务领域建模之后，我们就可以进行UML类图的绘制了。下面是基于物理引擎为基础的游戏项目类图：

图4 UML类图

每个类的含义如下：

Collisiondetection：碰撞检测接口类。碰撞检测技术以及碰撞检测的处理方式是物理游戏模拟中最关键的技术。
SnakeCollision：用于检测蛇与环境的监测，通过时间和蛇的对象来实现isCrash方法，返回是否发生了碰撞。
CircumstancesCollision：用于检测环境与其他物体是否发生了检测，其中包含时间属性，并实现了Collisiondetection的方法。
Snake：蛇的对象，包含蛇的基本属性等。
Circumstances：环境对象，包含环境的大小，图像，样式，灯光，位置等属性。
Light：光线属性，用于描述环境。
Positon：坐标类。
Muscle：肌肉类，用于模拟蛇的肌肉实现。

五. 数据模型的建立

5.1 数据模型的概念

　　什么是数据模型呢？数据模型是定义数据如何输入和与输出的一种模型。其主要作用是为信息系统提供数据的定义和格式。数据模型是数据库系统的核心和基础，现有的数据库系统都是基于某种数据模型而创建起来的。数据模型所描述的内容包括三个部分：数据结构、数据操作、数据约束。

数据结构：储存在数据库中对象类型的集合，作用是描述数据库组成对象以及对象之间的联系。
数据操作：指对数据库中各种对象实例允许执行的操作的集合，包括操作及其相关的操作规则。
数据完整性约束条件：指在给定的数据模型中，数据及其联系所遵守的一组通用的完整性规则，它能保证数据的正确性和一致性。

　　数据模型按不同的应用层次分成三种类型：分别是概念数据模型、逻辑数据模型、物理数据模型。

　　概念数据模型：概念数据模型（Conceptual Data Model），是一种面向用户、面向客观世界的模型，主要用来描述世界的概念化结构，它是数据库的设计人员在设计的初始阶段，摆脱计算机系统及DBMS的具体技术问题，集中精力分析数据以及数据之间的联系等，与具体的数据管理系统（Database Management System，简称DBMS）无关。概念数据模型必须换成逻辑数据模型，才能在DBMS中实现。

　　逻辑数据模型：逻辑数据模型（Logical Data Model），是一种面向数据库系统的模型，是具体的DBMS所支持的数据模型，如网状数据模型(Network Data Model)、层次数据模型(Hierarchical Data Model)等等。此模型既要面向用户，又要面向系统，主要用于数据库管理系统（DBMS）的实现。

　　物理数据模型：物理数据模型（Physical Data Model），是一种面向计算机物理表示的模型，描述了数据在储存介质上的组织结构，它不但与具体的DBMS有关，而且还与操作系统和硬件有关。每一种逻辑数据模型在实现时都有其对应的物理数据模型。DBMS为了保证其独立性与可移植性，大部分物理数据模型的实现工作由系统自动完成，而设计者只设计索引、聚集等特殊结构。

5.2 游戏设计中的数据模型

　　了解了数据模型之后，我们来在实际项目中分析一下吧！在这个工程实践项目中，数据模型该如何建立呢？

概念数据模型：

数据模型设计
序号	表名	名称	功能
1	user	用户数据模型	存储用户ID和密码
2	Snake	角色数据模型	用于存储游戏角色的基本数据
3	circustances	环境数据模型	存储环境的一些基本信息

物理数据模型：

Snake数据模型
字段名	名称	类型	长度	是否主键	允许空值
Snake_id	属性编号	int	20	是	否
Snake_name	名称	Varchar	100	否	否
Snake_length	蛇身长度	float	20	否	否
Snake_image	图层	string	100	否	是
Snake_crash	是否碰撞	bool	4	否	是

环境数据模型
字段名	名称	类型	长度	是否主键	允许空值
id	环境编号	int	20	是	否
name	名称	Varchar	100	否	否
width	宽度	float	20	否	是
length	长度	float	20	否	是
color	颜色编号	int	20	否	是
position	位置编号	int	20	否	否
texture	图层	string	100	否	是
iscrash	是否碰撞	bool	4	否	是

用户
字段名	名称	类型	长度	主键	允许空值
User_id	用户编号	int	11	是	否
User_name	用户名	Varchar	10	否	否
User_password	用户密码	Varchar	10	否	否
User_sex	用户性别	Varchar	2	否	是
User_tel	联系方式	Varchar	11	否	是
User_mail	用户邮箱	Varchar	20	否	是
User_update	用户注册日期	date		否	否

六. 总结

　　经过上面的学习之后，我们应该大致明白了软件的开发过程：需求分析---用例建模---业务领域建模---数据建模---项目维护。需求分析指的是在创建一个新的或改变一个现存的系统或产品时，确定新系统的目的、范围、定义和功能时所要做的所有工作，其中包括考虑来自不同利益相关者的需求，确认是否冲突，在冲突的需求之间进行取舍，并针对软件需求及系统需求进行分析、记录、确认以及管理。。用例（Use Case）的核心概念中首先它是一个业务过程（business process），经过逻辑整理抽象出来的一个业务过程，这是用例的实质。什么是业务过程？在待开发软件所处的业务领域内完成特定业务任务（business task）的一系列活动就是业务过程。业务领域建模是开发团队用于获取业务领域知识的过程。因为软件工程师往往需要工作在不同的业务领域或者不同项目中，他们需要业务领域知识来开发软件系统。软件工程师往往来自不同的专业背景，这可能会影响他们对业务领域的认知。数据模型是定义数据如何输入和与输出的一种模型。其主要作用是为信息系统提供数据的定义和格式。数据模型是数据库系统的核心和基础，现有的数据库系统都是基于某种数据模型而创建起来的。

　　正所谓“实践出真知”。在学习了高级软件工程课程的从需求分析到软件设计这一小节的课程后，虽然大致明白了如何进行用例建模和业务领域建模，以及数据建模，最终形成概念原型。但是还是有许多细节方面无法掌握，在对自己的工程实践项目使用相同的方法进行分析之后，思路明确了很多。在今后的工作及学习生活中也会给我带来很多有益的影响。