编写有效用例读后感二

被讨论系统是在不同项目相关人员之间制定契约的一种机制，用例是规范行为的契约。用例中的每个句子都描述了一项行为，这些行为维护或增进了某些项目相关人员的利益；有的句子也可能描述两个执行者之间的一种交互，或描述系统为了维护项目相关人员的利益所必需采取的一个内部动作。分为两个部分，第一部分称为“执行者和目标”概念模型，第二部分称为“项目相关人员和利益”概念模型。

执行者之间的交互需要注意一下几点：

首先，执行者要有目标，主执行者是对SuD（被讨论系统）具有目标的人或系统，辅助执行者是对SuD具有目标的其他系统。系统需要完成它的职责，其中需要注意的是系统有责任维护所有项目相关人员的利益，为了实现其职责，系统制定出一些子目标，系统可以内部实现一些子目标，但其他子目标需要借助“辅助执行者”来实现，辅助执行者通常会履行自己的承诺，并将子目标的完成结果交付给被讨论系统SuD，SuD与外部执行者进行交互，按一定次序陆续实现其子目标，直到最终交付其职责，即它所承诺的服务。

交付承诺服务是一个最高目标，他通过子目标来实现，子目标可以进一步分为子-子目标，子-子目标又可以进一步分解，如此可以无限细分下去，很可能没有一个终点。要编写好的用例最困难的是控制写作中的子-子目标。执行者和目标概念模型是一个有用的通用模型。

第二，目标可能失败，强调目标失败和失败反应是用例通常能够进行良好的系统行为描述和出色的功能需求描述的原因之一。

第三，交互是复合的。一个消息序列或场景是一个复合的交互，交互可以根据需要被折叠或分解，就像目标能大能小一样。场景中的每一步都捕获一个目标，因此每一步都可以被展开，而自成为一个单独的用例。通过对目标和交互进行折叠，可以在一个很高的层次上来表示系统的行为，通过对它们一点一点地逐步展开，也能够对系统行为尽可能进行精确的刻画。要描述将来的一次交互过程，就必须要对不同的情况进行处理，创建出一个交互序列集，对每一个交互序列，说明它发生的条件，然后描述交互的发生情况，最后给出交互产生的结果。

第四，要注意用例聚集场景。用例把所有的场景聚集在一起，显示了一个目标获得成功或遭遇失败的所有可能的途径，通过一个“条形裤”图案来阐明，裤子上的条形带指明了把所有场景聚拢在一起的目标，一条裤腿代表成功场景的集合，另一条代表失败场景的集合。

系统运行时并不是所有项目相关人员都在场，所以需要保留一个日志来记录所有的交互过程，以备发生争议时项目相关人员的利益能够得到保护，它也记录其他信息，以便能够判断在失败之前交易究竟进行到何种程度。

要认真完成一个用例有必要列出所有的项目相关人员，然后根据用例中的操作命名他们的利益，为了满足项目相关人员的利益，需要描述三种行为：两个执行者之间的交互（为了促进一个目标）、确认（为了保护项目相关人员）、内部状态变化（代表项目相关人员）。

范围用来描述项目开发人员负责的设计工作的边界，以便与应由其他人负责的设计工作或已经完成的设计工作相区别。弄清楚一个项目的范围，或只是明确一次讨论的范围，这都是很困难的。书中介绍了一个用来跟踪和管理范围讨论的很好的小工具——“内/外”列表。