软件设计流程

1. 功能列表

首先我们需要理解软件应该做什么，然后列出功能列表

架构三问

a. 它是系统本质的一部分么

个人总结：就是这个部分是系统必须需要的么，如果没有该怎么办

b. 这到底是什么意思

总结：如果你不知道该功能的描述是什么意思，把注意力放在该功能上就很重要

c. 我到底该如何做

总结：找到你觉得你不能实现的部分，就是某个特定问题你无法处理，仔细思考

2. 用例图

用例简单介绍

1. 用例图需要我们思考软件将如何被使用，不需要深入
2. 用例反映使用性，功能反映功能性
3. 重点是我们需要理解用例和功能之间的区别和相互关系
4. 用例需要根据真实世界做出改变，因为程序运行在真实世界

用例能做什么

1. 用例中的名词大部分转换成类
2. 用例中的动词转换成方法

用例是什么

用例是你考虑问题的流程。用例能帮助我们了解需求

用例需要什么

主要路径

1. 主要路径是解决问题逻辑的主要步骤
2. 主要路径可以有替换路径。

可选路径

可选路径是主要路径下的细化

替换路径

包含一个或多个步骤的，类似于Plan B

场景

场景是从第一步到最后一步通过用例的完整路径

场景能做什么

场景能帮助收集需求，帮助确定用例完整，减少架构中的风险，减少混乱和疑惑，澄清特定模块或程序代码做什么

总结

场景就是对系统进行举例，比如策略类游戏，移动某个人物到棋盘某个位置，场景帮助我们理解却不必深入细节。

3. 问题分解

x. 了解问题

4. 需求

针对需求的方法

需求列表

文本分析

查看用例里的名词与动词以整理出类和方法的动作叫文本分析
个人理解：从用例描述中找出系统需要的类和方法

如何获得需求

通过用例来获得需求，每当用例改变就该检查是否有新需求或者旧需求需要更改

5. 领域分析

用一种以客户能真正理解的方式把游戏系统的一切组合起来

6. 初步设计

7. 实现

8. 交付

接下来的是在软件开发中需要用到的一些知识

迭代

介绍

先针对整体轮廓操作，接着迭代应用程序的每个片段。

开始和结束

从第4步需求开始，到第7步实现结束。在这几步之间不断循环

方式

1. 功能驱动开发

选择应用程序的特定功能，并且规划、分析及开发该功能

2. 用例驱动开发

选择用例的场景，并且编写程序代码以支持通过该用例的完整场景

总结

1. 2种迭代都由良好的需求所驱动
2. 2种迭代都聚焦在交付客户要的东西上

OO原则

1. 简单原则

1. 将变化之物封装起来
2. 对接口编码，而不是对实现编码
3. 应用程序中的每一个类只有一个改变的理由
4. 类是关于行为与功能的

2. OCP(Open-Closed Principle) 开闭原则

类应该为扩展而开放，禁止为修改而关闭

个人总结

就是方法可以被继承后重写。当然该方法在父类中是写好的。继承是一个简单实现OCP 的例子和方法。合成也可以实现OCP 原则。

例子

如果你有许多private 方法，可以增加一些以不同方式调用这些private 方法的public 方法

3. DRY(Don’t Repeat Yourself Principle)不自我重复原则

将共同之物抽取出来单一地方来避免重复代码

个人总结

这个原则也可以应用到需求分析中，保证需求的单一性。让系统中的每一个信息与行为都保存在单一合理的地方

4. SRP(Single Responsibility Principle)单一职责原则

系统里的每一个对象应该具有单一职责，所有

检查是否使用SRP 方法

The 类名 类内方法 itselfs。通过该方法检查该类内的类方法是否是应该由该类
调用的，当方法有参数时，把参数放在类内方法后面，之间可以加个量词之类的

个人总结

对象的服务都聚焦在实现该职责上，又代表内聚力，内聚力高就是指SRP 应用的好。SRP 通常会让类更大，使得你的程序类很少让程序在管理与维护上简单很多

5. LSP(Liskov Substitution Principle)替换原则

子类型必须能够替换其基类型。如果你继承了父类，但是该子类的方法与父类完全不同，那么子类无法替换父类，这将违反LSP 原则

个人总结

委托是继承的几个代替方法之一。委托或聚合是修正不符合LSP 继承树的好方法。LSP 的良好运用与委托、组合、聚合相辅相成