如何利用面向植物大战僵尸的游戏
如何利用面向对象开始制作
面向对象的技术流程可以简要概括为：
需求模型（明确需求）
——> 邻域模型（基于需求模型，提炼出邻域相关的概念）
——> 设计模型（以领域模型为基础综合面向对象技巧完成类的设计）
——> 实现模型（以设计模型为基础翻译成具体的语言实现，完成编码）
我们的需求是什么
在面向对象的需求模型中，我们需要区分两个概念：
- 需求：对客户来说有价值的事情
- 功能：系统为了实现客户价值而提供的能力。
我们总的要求是：制作一个像市面上一样的植物大战僵尸游戏。
那市面上的植物大战僵尸游戏是什么样的？他是什么类型的游戏？他是怎么玩的？因而我们需要明确我们的需求。
一般来说，需求分析有三重境界，分为”记录员“、”分析员“、”引导员“三个级别，以这三个级别来分析”我们要制作一个植物大战僵尸“这个需求：
-第一重：记录员，记录客户的需求(简单记录客户的需求)：
”制作植物大战僵尸的游戏“
-第二重：分析员，和客户一起分析问题，完善需求（调整细化需求)：
”待补充“
-第三重：引导员，能够引导客户需求
引导员一般会发现更多潜在的问题或需求，引导客户内在的需求，并将他自身的需求调整到更为合理和全面的需求
”待补充“
需求分析518方法：5W1H8C!
5w
- When
这是和时间相关的环境信息。对于这个游戏来说，可能when是无所谓的，你可以早上、下午、晚上、凌晨玩这个游戏。 - Where
这是和地点相关的环境信息。在此案例中比较无所谓的 - What
what反映客户最终想要的输出，那应该是这个游戏的输赢。 - Who
这是和参与者相关的信息。此案例 指的是游戏玩家。 - Why
这个指的是客户遇到的问题、困呐、阻碍等，也是客户提出需求的驱动力。在此案例上可能是因为你无聊了
1H
需求分析阶段的How不是指如何实现需求，而是需求本身的流程，如何实现需求那是设计阶段的事情！其实际上是需求分析上最工作量最大的一部分，How分析的结果是需求分析的主要输出，而却How分析的质量直接影响最后需求实现的质量。
而对于该案例（植物大战僵尸）的流程：
8C
8C指的是约束和限制
（1）性能
性能指的系统提供的相应服务的效率。一般包括相时间、吞吐量。
（2)成本
成本也是实现系统而需要付出的代价
（3）时间
时间是指客户需要什么时候交付
（4）可靠性
可靠性指系统长时间正确运行的能力
（5）安全性
安全性是指信息安全的保护能力
（6）合规性
合规性是指满足各种行业标准、法律法规、规范等
（7）技术性
有的客户可能要求我们采用某种技术。例如客户现在使用的是Wondow及其，那么就可能要求我们基于Window频台开发。
（8）兼容性
兼容性指我们的产品或系统与客户已有的产品或系统的兼容能力。
用例方法
NEA方法：
（1）正常处理：通过和客户沟通，分析需求的正常流程
（2）异常处理：在正常处理流程的步骤上，分析每一步的异情况和对应的处理。
（3）替代处理:在正常处理流程的步骤上，分析每一步是否有其他替代方法，以及替代方法如何做。
用例的具体方法
【用例名称】
【场景】：Where、Who、When
【用例描述】:What、How
【用例价值】:Why
【约束和限制】：8C
第一步 正常处理:
[用例名称]
植物大战僵尸
[场景]
Who：玩家
Where；
When；
[用例描述]：
1.玩家点击入口可以进入游戏界面
2.游戏会自动随机生成太阳掉落
3.玩家点击掉落的太阳，实现收集太阳
4.玩家点击选择植物卡片，消耗太阳数量
5.拖拽种植植物
6.植物与僵尸相互攻击
7.所有僵尸死亡，游戏胜利
[用例价值]：
所有僵尸死亡，游戏胜利
[约束和限制]：
【待定】
**第二步 异常处理 **
[用例描述]：
1.玩家点击入口可以进入游戏界面
2.游戏会自动随机生成太阳掉落
3.玩家点击掉落的太阳，实现收集太阳
3.1 玩家没来得及点击，则太阳在停下5秒后自动销毁
3.2 玩家不想种植该植物，再次点击对应卡片可取消操作
4.玩家点击选择植物卡片，消耗太阳数量
4.1 玩家太阳数量不够，无法种植
5.拖拽种植植物
5.1 玩家将植物种植在错误的空土地位置，使用铁楸铲除
5.2 玩家所种植位置已有植物，无法种植。
6.植物与僵尸相互攻击
7.所有僵尸死亡，游戏胜利
第三步 替代处理
在第二步的基础上，可增加替代处理，即有的步骤可以换一种方式来实现。
【待补充】
提取功能！
我们需要将用例中需要系统完成的事情（动词）提取出来，这样就成为系统的功能了。
我们以斜体字标注出我们从用例提取出来的功能：
[用例描述]：
1.玩家点击入口可以进入游戏界面
2.游戏会自动随机生成太阳掉落
3.玩家点击掉落的太阳，实现收集太阳
3.1 玩家没来得及点击，则太阳在停下5秒后自动销毁
3.2 玩家不想种植该植物，再次点击对应卡片可取消操作
4.玩家点击选择植物卡片，消耗太阳数量**
4.1 玩家太阳数量不够，无法种植
5.拖拽种植植物
5.1 玩家将植物种植在错误的空土地位置，使用铁楸铲除
5.2 玩家所种植位置已有植物，无法种植。
6.植物与僵尸相互攻击
7.所有僵尸死亡，游戏胜利
我们将提取的功能列成表格：
| 功能编号 | 功能描述 | 备注 |
|---|---|---|
| 001 | 点击进入界面 | （现阶段）实现任意位置点击进入 |
| 002 | 自动随机生成太阳掉落 | NA |
| 003 | 采集太阳 | NA |
| 004 | 自动销毁 | 太阳在停止下降5秒后自动销毁 |
| 005 | 取消选卡片 | NA |
| 006 | 选择植物卡片 | NA |
| 007 | 消耗太阳数量 | NA |
| 008 | 拖拽种植植物 | NA |
| 009 | 铁楸铲除 | NA |
| 010 | 相互攻击 | NA |
除了统一用例中某些功能需要合并外，不同的用例中相同的功能也需要合并。可重新整理为一下列表:
| 功能编号 | 功能描述 | 涉及用例 |
|---|---|---|
| 001 | 显示游戏页面 | 图片显示、点击进入 |
| 002 | 采集太阳 | 点击太阳、显示太阳余额 |
| 003 | 生产太阳 | 自动随机生成太阳掉落、太阳自动销毁、太阳花生成太阳 |
| 004 | 种植植物 | 显示植物卡片、选择植物卡片、消耗太阳、拖拽种植植物 |
| 005 | 生成僵尸 | 自动生成僵尸、显示僵尸、移动僵尸 |
| 006 | 战斗过程 | 植物攻击僵尸、僵尸攻击植物、植物死亡、僵尸死亡 |
画一个用来描述系统的用例图！
用例图的主要内容为用例，但是是用来描述系统的。其组成为：
- Actor:系统外的用户，对应到5W的who，包括但不限于用户、外系统；
- Use Case：用例
- System：系统，所有的用例的集合就是系统了
从上可得，用例图可以简单理解为系统用例的集合，而不是详细描述每个用例的具体步骤和流程。这也是为什么使用“用例”来分析需求而不是“用例图”来分析需求的原因。
加之画一个SSD图？
SSD，中文翻译为“系统顺序图”，主要用域描述在某个用例的分支场景下，外部参与者与系统的交互过程。简单来说就是一个用例的可视化描述。
- SSD不是标准的UML图形，其只有两类对象：系统和与系统交互的对象。
- SSD是用来描述某个用例的某个分支，而不是描述系统的结构；
- 在SSD中，系统被当作一个黑盒，不涉及系统的分解。
- 不需要为每个用例的每个分支都画一个SSD，挑出关键的用例和分支即可，并且关键的用例没有严明规定，只要你觉得重要即可。
真正开始面向对象的工作：邻域模型
邻域模型是对邻域内的概念类或现实世界中对象的可视化表示，又称概念模型、邻域对象模型、分析对象模型。它专注于分析问题邻域本身，发掘重要的业务邻域概念，并建立业务邻域概念之间的关系。
其两个主要作用：
- 发掘重要的业务邻域概念
- 建立业务邻域概念之间的关系
其方法概括为：
找名词——加属性——连关系
找名词！
首先我们将用例中的所有名词挑出来：
[用例描述]：
1.玩家点击入口可以进入游戏界面
2.游戏会自动随机生成太阳掉落
3.玩家点击掉落的太阳，实现收集太阳
3.1 玩家没来得及点击，则太阳在停下5秒后自动销毁
3.2 玩家不想种植该植物，再次点击对应植物卡片可取消操作
4.玩家点击选择植物卡片，消耗太阳数量
4.1 玩家太阳数量不够，无法种植**
5.拖拽种植植物
5.1 玩家将植物种植在错误的空土地位置，使用铁楸铲除
5.2 玩家所种植位置（土地） 已有植物，无法种植。
6.植物与僵尸相互攻击
7.所有僵尸死亡，游戏胜利
识别名词后还需进行提炼筛选；
名词列表：游戏界面、太阳、植物/植物卡片、铁楸、种植位置（土地）、僵尸
加属性！
加属性于找名词有些许差别：有的属性并没有在用例中明确给出，需要我们二外添加
| 名词 | 属性 |
|---|---|
| 游戏界面 | 设置位置、界面长宽 |
| 太阳 | 数量、下降范围、停留时间 |
| 植物/植物卡片 | 阳光消耗数、生命力、攻击力 |
| 铁楸 | 显示位置 |
| 种植位置（土地） | 位置、占用面积 |
| 僵尸 | 移动范围、生命力、攻击力、数量 |
连关系
邻域关系图：（待修改）
设计模型
经过邻域模型的分析后，面向对象已经初具雏形，单邻域类并不能指导我们进行编码工作，因而我们需要完成邻域类到软件类的转换，这就是面向对象邻域设计阶段的主要任务——设计模型。
设计模型主要包含两部分：静态模型和动态模型。
静态模型又称为”类模型“，主要关注系统的”静态“结构，描述系统包含的类，以及类的名称、职责、属性、方法、类与类之间的关系。
动态系统关注系统的”动态“行为，描述系统本身的一些动作或者状态变化，以及类之间如何配合以完成最终的业务功能。
静态模型主要用于指导类的声明，包括类名称、属性名、方法名；
而动态模型主要用于指导类的实现，主要就是每个方法内部的具体实现过程。
动态模型必须在静态模型的基础上设计，静态模型的变化同样会影响动态模型。
类模型
“类模型”是整个面向对象设计的核心，是面向对象设计阶段的主要输出。
第一步：邻域类映射
- 类从哪里来：邻域模型中的“邻域类”是设计模型中“软件类”最好的来源。
注意：不可将邻域类全盘拷贝到软件类，还需要进行【类筛选】 - 名称映射：在筛选后，我们开始将邻域类转换为软件类，名称可都保持一致。
- 提炼方法：从“用例模型”中提炼出方法——找动词
[用例描述]：
1.玩家点击入口可以进入游戏界面
2.游戏会自动随机生成太阳掉落
3.玩家点击掉落的太阳，实现收集太阳
3.1 玩家没来得及点击，则太阳在停下5秒后自动销毁
3.2 玩家不想种植该植物，再次点击对应植物卡片可取消操作
4.玩家点击选择植物卡片，消耗太阳数量
4.1 玩家太阳数量不够，无法种植
5.拖拽种植植物
5.1 玩家将植物种植在错误的空土地位置，使用铁楸铲除
5.2 玩家所种植位置（土地）已有植物，无法种植。
6.植物与僵尸相互攻击
7.所有僵尸死亡，游戏胜利。
识别动词后还需进行提炼筛选以及根据实际情况推断判断，以下是所获得的动词：
- 点击进入
- 生成太阳
- 掉落太阳
- 收集太阳（点击太阳）
- 显示太阳余额
- 销毁太阳
- 种植植物
- 消耗太阳
- 取消选取
- 铲除植物
- 攻击僵尸
- 生成僵尸
- 攻击植物
- 死亡（僵尸&植物）
在识别出有效的动词后便是将动词分配给已有属性的软件类。
| 名词 | 动词 |
|---|---|
| 游戏界面 | 点击进入、生成太阳、显示太阳余额、种植植物、取消选取、生成僵尸 |
| 太阳 | 掉落、收集、销毁 |
| 植物/植物卡片 | 消耗、攻击僵尸、死亡 |
| 铁楸 | 铲除植物 |
| 种植位置（土地） | 放置植物 |
| 僵尸 | 移动、攻击植物、死亡 |
经过上面的处理步骤后，我们将得到如下图所示的类图
（待改进）
第二步：应用设计原则和设计模式
目前为止，我们暂时实现了“满足用户需求”的最基本要求，但不是一个“好设计”的评判标准。
那么什么才是“好设计”呢？我们可以用面向对象最具代表性的“设计原则”和“设计模式”来进行评价。
【设计原则】
当我们在讨论面向对象邻域的设计原则时，其实都是在讨论Robert C·Martin的SOLID原则。而设计原则的根本目的是为了保证可扩展性。
SOLID设计原则如下：
