从这个列表中，我们列出了通过了问题检查的词，也就是下面列出的分析类：
啊哈!在总共得30多个候选中，现在我们只需要面对选出的8个分析类。前面的四个问题帮助我们缩小了搜索范围，是个很有效的工具。
但是我们有没有犯错呢?有没有漏过某个真正的类，或者把一个不该作为类的词加进来了?这并不重要。RUP的迭代特性，会逐渐暴露出我们犯过的错误，并允许我们用尽量小的代价来修正它们。分析和设计的目标不是先把一切事情设计的很完美，而是当你需要确认这些事情的时候，才去确认这些。开始阶段往往是最困难的，我们现在实现了对象(或者说类)从无到有的突破!重要的是我们已经起步了，而且我们能够按照面向对象的方法一步一步的取得进展。
我们现在完成了RUP的用例分析活动中的前三步：
对每个用例
建立一个用例实现
补充用例描述(如果需要的话)
从用例行为中，找出分析类
如果我们严格按照RUP过程进行，下一步应该是：
把行为分配给分析类
基于以下理由，这一次，我又会对RUP过程做一点小的改动：回顾一下我们的进展。我们刚刚找到了8个实体类，我们认为这些都是我们系统中的类。在我们做下一步之前，我们需要给这8个实体类增加一些内容，来确认他们是类。
有三种基本的方法来充实我们的分析类：
数据驱动的方法
行为驱动的方法，和
职责驱动的方法。
数据驱动的方法对于从事数据库工作，或者从事过程语言编程的人员来说很常见。他们就是用数据和数据之间的关系来认识、描述世界的，因此会首先去寻找类中的数据-一般没有什么标准的方法去寻找类的函数或功能。这看起来不错，但是数据只是工作的一半。实际上， 类的准确定义，包括了数据和对数据进行的操作。
文章来源于领测软件测试网 https://www.ltesting.net/
