9.用例use case
用例是一个捕获一个系统功能需求的技术。用例的工作是通过描述系统的使用者和系统本身间典型的交互typical interaction，提供一个系统是怎样被使用的描述。
先描述下情景scenario。一个场景是一系列描述用户和系统间交互的步骤。如下的场景：
the customer browses the catalog and adds desired items to the shopping basket.
when the customer wishes to pay, the customer describes the shipping and credit card
information and confirms the sale.
the system checks the authorization on the credit card and confirms the sale both
immediately and with a follow-up e-mail
这是一个可能方式的情景。但信用卡认证可能失败，这会是一个分开的情景。另外你可能有一个常客，
你不需要获取信用卡信息，这是第3个情景。
这些情景不同但相似。这里3个情景相似的地方是用户有相同的目标：买东西。虽然不总是成功，但其目标没变。这个用户的目标是用例的关键：一个用例是一个 有一个共同用户目标的情景的集合a set of scenarios tied together
by a common user goal。
在用例里，用户指actor演员。一个演员是用户在系统中扮演的角色。演员可能包含顾客、卖主和产品分析。演员实现用例，一个演员可能完成多个用例，一个用例可能有多个演员完成。一个人可以扮演多个角色。
演员并不是正确的说法，角色role应该更好。
【用例的内容】content
见图9.1
你开始选一个作为主要成功的情景main success scenario。你开始用例的身体，通过写出主成功场景的一系列数字步骤。你然后写其他的场景作为扩展extensions，描述他跟主成功情景的不同，可以是成功的或者失败的。
每个用例都有一个主要的角色primary actor，来请求系统提交一个服务。这个主角有这个用例尝试满足的目标，且经常是这用例的发起者。在实现用例时，也会有其他角色来跟系统交流，这些叫配角。
用例中的每一步是角色和系统间的交互的一个元素。每步应该是一个简单的描述，并可清楚的显示是谁在执行这一步。所以你不用在用例里描述用户接口user interface。的确，写用例经常是在设计ui之前。
用例的扩展指定了在主要成果情景MSS中不同的交互的结果的条件condition，并说明那些区别。扩展的开始是为检测到条件的那一步命名，并提供该条件的简短描述。然后是后面的一些步骤，结束是通过描述你要返回的MSS的哪一步。
用例的结构是一个很好的方式来集体讨论brainstorm主成功场景的不同选择。一般最后最开始就集体讨论好所有的扩展条件，这样能想到更多的条件，后面也会占用更少的时间。
用例里一个复杂的步骤可以是另一个用例。uml中可以说第一个用例包含include第二个。在文本里没有标准的方式来显示一个被包含的用例，但我发现下划线暗示超链接，很有效。
对于一个复杂的步骤（会混乱主场景或在几个用例中重复用到），使用被包含included用例很有用。但不用尝试去将用例分成很多子用例，这样浪费时间。
像场景里的步骤一样，你可以添加一些其他的公共信息到用例去。
·前置条件pre-condition：描述了在系统允许用例开始前，系统应该确保true的东西。这告诉了程序员在他们的代码里不用考虑哪些条件
·保证guarantee：描述了系统在用例的最后会确保什么。Success guarantees hold after a successful scenario; minimal guarantees hold after any scenario
·触发器trigger：指出让用例开始的事件
当你考虑添加元素时，请概括。最后不要做太多事情，保持用例简洁易读。
用例里你需要的细节的数量取决于用例里风险risk的数量。经常早期的时候你需要一些关键用例的细节，其他的在你开始实现的时候可以被很快的具体化fleshed out。你不需要写下所有的细节，口头交流也很有效，特别是在一个迭代循环里通过运行代码需求就被满足meet了。
