1.7.2 上下文视图

分类鸢尾花应用的上下文时涉及两个参与者：

• 植物学家（Botanist）提供预先分类好的训据集和测试集。植物学家也要运行测试用例以确定分类器的一些参数。在简单的KNN示例中，它们要决定k的值。

• 用户（User）需要给未知的数据分类。用户先仔细地测量数据，然后用测量好的数据向分类器系统发起请求，获得分类结果。“用户”这个名称有点儿模糊，但是我们暂时想不到更好的名称。我们就暂时先用它，遇到问题时再去修改。

下面用一个UML上下文图说明我们将探索的两个参与者和三个场景，如图1.12所示。

图1.12 UML上下文图

整个系统被描绘为一个矩形。它用椭圆形表示用户故事（User Story）[9]。在UML中，特定的形状是有意义的，我们预留矩形用来表示对象。椭圆（和圆形）用来表示用户故事，它们是系统的对外接口。

我们需要正确分类的训练数据，才能进行任何有用的处理。每组数据集都有两部分：训练集和测试集。下面我们将整个数据集称为“训练数据”，而不是使用更长（但更精确）的“训练和测试数据”。

植物学家负责调整和设置参数，他们必须检查测试结果以确保分类器正常工作。有两个参数可以调整：

• 计算距离的算法（Distance Computation Algorithm）。

• 参与投票的邻居的个数，也就是k值（kfactor）。

我们将在本章后面的过程视图部分详细了解这些参数。我们还将在随后的案例学习章节中重新审视这些想法。距离算法是一个有趣的问题。

我们可以将一组实验定义为由不同候选方案组成的网格，并用测试集结果有条理地填充网格。植物学家将推荐使用测试结果与真相最接近的组合（最佳拟合）的参数。在我们的案例中共有两个参数（计算距离的算法和k值），因此可以用下面这种二维表。在更复杂的算法中，可能需要使用多维的空间。

测试完成后，用户可以提出请求。他们提供未知数据给分类器，接收分类的结果。从长远来看，这个“用户”也许不是一个人，他们可能是某个购物网站或搜索引擎发给我们的基于分类器智能推荐引擎的网络请求。

我们可以用一个用例或用户故事来总结这些场景：

• 作为植物学家，我想为这个系统提供正确分类的训练和测试数据，以便用户正确识别植物。

• 作为植物学家，我想检查分类器的测试结果，以确保新样本被更好地正确分类。

• 作为用户，我想向这个分类器系统提供关键的测量数据，以便获得正确的鸢尾花种类。

有了用户故事中的名词和动词，我们可以使用这些信息来创建应用需要处理的数据的逻辑视图。