常见的用例之间的关系有两种，分别是包含关系和扩展关系。如果多个用例都具有一部分相同的行为，可以将这部分相同的行为作为一个单独的用例抽取出来，与原来的用例形成一个包含关系。扩展关系又称为延伸关系，如果一个用例在执行时可能会使用到另一个用例，或者使用一个新的用例对原有用例的行为进行扩展时可以使用扩展关系。关于包含关系和扩展关系箭头的指向，可以记住两句口诀：包含进来，箭头向外；扩展出去，箭头向里。

——包含向外是指大包小，箭头从基用例（大）指向被包含用例（小）；扩展向里是指扩展出去的用例有可能被纳入进来，故从扩展用例指向基用例，基用例得到了加强，有更多的处理选择余地。

用例文档是用于描述用例的文档，每一个用例对应于一个用例文档，在用例文档中需要用文字的方式描述用例的执行过程，即执行者与系统的交互过程。

——用例的执行过程展示了系统在接收到执行者的输入之后有做了什么处理，并将哪些结果反馈给执行者。

用例文档中最关键的部分是基本路径，基本路径又称为“正常路径”或者“开心路径”，它是用户最想看到、也最关心的路径，是用例建模核心中的核心。

——这里讲到了用例建模的核心中的核心是——基本路径！！！也就是最基本的sunny day scenario。

在编写用例文档时，需要认真细致编写基本路径，确保非专业人员都能够在读完基本路径后理解执行者和系统的交互过程。

——文档是写给别人看的东西，因此必须要浅显易懂，思路清晰，不要带有问题领域之外的软件专业术语。

除了基本路径之外，很多用例都存在一些替换路径和异常路径，通常可以将替换路径和异常路径统称为扩展路径。

——异常路径展示的就是rainy day scenario，替换路径应该是在某些场合下也可执行的，但不是最常走的道路。

字段列表、业务规则、非功能需求和设计约束是对用例的补充描述。“字段列表” 为后续的数据库设计工作提供了极大的帮助；业务规则用于描述在步骤中执行者或系统在执行某些操作时需要满足的条件。非功能需求用于描述用例在可靠性、安全性、可用性、移植性等方面的一些要求。设计约束是指设计过程中存在的一些待解决的问题。

——以上这些不是在文档中一定会出现，但若出现，则必然是有益的补充。字段列表对后面的数据库设计非常重要，业务规则则可能对逻辑处理和界面设计也设定了重要的条件。非功能需求意味着产品验收时的一个测试维度，比如安全性，或者响应时间，或者吞吐量等。设计约束也提供了软件后续升级时可能需要面对的问题。

在实际软件开发过程中，用例编号、用例名、执行者、前置条件、后置条件和基本路径是一个用例必不可少的组成部分，其他部分可根据实际情况确定，可有可无。

——写文档也要实事求是，应该有的就一定要写，没有的也别胡编乱造，误导读者。