1.7.4 过程视图

现在有3个独立的用户故事，但这不意味着必须创建3个过程图。对于复杂的处理，可能会有比用户故事更多的过程图。在某些情况下，用户故事太简单了，可能不需要精心设计的过程图。

在我们的应用中，看起来至少涉及3个独特的过程：

• 上传包含TrainingData的初始样本。

• 设置特定的k值，运行分类测试。

• 给一个新的Sample对象做分类。

我们将为这些用例绘制活动图。活动图总结了许多状态变化。处理从起始节点开始，一步步进行，直至到达结束节点。在基于事务的应用（如Web服务）中，通常会省略整个Web服务器引擎。这样我们就不用画出HTTP的Header、Cookie和安全等业务无关细节。相反，我们通常只专注于描绘每种不同类型的业务请求的处理过程。

活动图中的活动以圆角矩形显示。当涉及特定类型的对象和软件组件时，它们可以和相关活动关联起来。

重要的是，当过程视图因想法改变而发生变化的时候，确保更新相应的逻辑视图。很难完全孤立地完成任一视图。随着新的解决方案想法的出现，在每个视图中进行增量更改变得越来越重要。在某些情况下，需要用户提出新的意见，这也会导致这些视图的演化。

我们可以画一个草图，描绘当植物学家提供初始训练数据时，系统应如何响应。这是第一个示例，如图1.15所示。

图1.15 活动图

植物学家上传的已知分类的数据集会被分成两部分：训练集和测试集。在问题描述或用户故事中并没有提到这点，这表明我们原来的用户故事有所欠缺。如果在用户故事中缺少一些细节，逻辑视图可能就会不完整。现在我们假设大部分的数据，比如75%，作为训练数据，余下的25%用作测试。[13]

比较好的做法是给每个用户故事都创建类似的图表，同时确保每个活动图都有相应的类来实现其中的步骤及状态转换。

我们在图中使用了一个动词：划分（Partition）。这建议我们应该用一个方法实现这个动词，可能意味着我们要重新考虑类模型以确保有相应的实现。

接下来，我们将考虑要构建的组件。这只是初步分析，我们的想法将随着我们进行更详细的设计并开始创建类而演化。