这一章主要说明的问题就是目录的两大点：“具有目标的执行者之间的交互”和“具有利益的项目相关人员之间的契约”

1、首先，仅从捕获(具有某种目标的)执行者之间的交互行为的角度来考察一个用例，然后可以进一步扩充讨论的内容，直到用例能被用作项目相关人员间协调各自利益的契约。

这里说明了一个很重要的问题，就是获取用例是有过程的，第一步就是根据执行者的目标来捕获需求，然后第二步才是关心具体交互所牵涉到的利益。例如，在一个医院管理系统（HIS）中，患者是执行者，其在HIS里的一个重要目标就是完成看病，所以我们就有了一个大的用例——患者看病用例，假设当我们列出了患者看病的交互过程，如挂号，到诊室就诊，做检查，做检验，交费，取药等，至此已经捕获了一部分用例了，然后扩充讨论问题，就是患者，挂号员，收费员，医生，护士等项目相关人员的利益，甚至是医院高层的利益等，当考虑到这些人的利益的时候，很多交互过程就有所侧重了，如，患者挂号场景中，是刷卡挂号，还是口头挂号，如果刷卡（这里指的是带有患者唯一标识的卡而不是银行卡），患者就有一个唯一标识，在以后的场景都以这个标识为数据源，这样大大方便了医院的数据记录，而且还保留了患者的历史就诊信息，大大方便了患者和医生之间的沟通，所以，引入了利益，就会导致一些交互方式或者顺序发生改变，同时也引出了很多失败场景。

2、为了实现其职责，系统制定出一些子目标。系统可以内部实现一些子目标，但其他子目标需要借助‘辅助执行者’（supporting actor）来实现。这些辅助执行者可以是打印子系统，也可以是其他组织，如合作单位或政府代理等。
用例的执行者并不都是人

3、执行者可以是单个人员、组织或者计算机。执行者和目标概念模型可以用来描述由人、公司和计算机组成的混合系统；也可以用来描述一个软件系统。
对第2点的解释

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

5、活动序列很适合于描述发生在过去的交互过程，因为“过去”是已经完全确定的。要描述发生在将来的交互过程，需要有一个所有可能出现的活动序列组合的集合。

6、用例包含了到达一个目标可能出现的所有场景的集合，为了更加完善，需要加入一下内容：

(1)与同一个主执行者的同一个目标有关的所有交互过程。
(2)用例由触发事件启动后开始执行，直到目标被实现或者被取消而结束，系统通过本次交互完成它的职责。

7、用例，做为规范行为的契约，捕获了与满足项目相关人员利益相关的所有行为，并且仅限于此。
为了满足项目相关人员的利益，需要描述三种行为：
（1）两个执行者之间的交互（为了促进一个目标），交互过程中可能会有信息的往返传递
（2）确认（为了维护某一项目相关人员的利益所进行的确认）
（3）内部状态变化（代表项目相关人员）
这个现在我还是不太明白，可能要看第四章才会有更深的体会