用例建模方法

在用例建模方法中，功能性需求用参与者(系统的用户)和用例来描述。用例定义了一个或多个参与者和系统之间的交互序列。在需求阶段，用例模型将系统考虑成黑盒，并以包含用户输人和系统响应的叙述形式描述参与者和系统之间的交互。用例模型用参与者和用例描述系统的功能性需求。系统被看作黑盒，即处理系统会做什么来响应参与者的输人，而不是系统如何做的内部细节。在后续的分析建模(见第8章)期间，会确定参与每个用例的对象。用例总是从参与者的输人开始。典型地，一个用例包含了参与者和系统之间的交互序列。每个交互由参与者的输人以及后续的系统响应组成。因此，参与者向系统提供输人，而系统向参与者提供响应。系统总是被考虑为一个黑盒，使得其内部细节不会暴露。尽管一个简单的用例可能只包含参与者和系统之间的一个交互，但一个更典型的用例会由参与者和系统之间的多个交互组成。更复杂的用例也可能会涉及不止一位参与者。
举一个简单的银行系统的例子，自动提款机(AIM)允许客户从他们的银行账户中取款。这里有一个参与者"ATM客户"(ATMCustomer)和一个用例"取款"(WithdrawFunds)，如图6-1所示。"取款"用例描述了客户和系统之间的交互序列。用例始于客户将一张AIM卡插入到读卡器中，然后，客户响应系统提示输入密码(PIN)，最终客户收到ATM机发出的现金。

一个简单的用例
考虑"应急监控系统"(EmergencyMonitoring System)中的"查看警报"(ViewAlarms)作为一个非常简单的用例示例。其中有一个参与者，即"监控操作员"(Monitoring Operator)，他能请求查看所有警报的状态。该用例描述的关键部分由以下内容组成:
用例的名称:查看警报。
参与者的名称:监控操作员。
一句话的用例概要:给出简要描述。
对事件主序列的描述。对该用例而言，第一步是操作员请求，第二步是系统响应。对主序列的替代情况的描述。对该用例而言，在第二步会有一个替代:如果出现监控紧急状况则该替代会被执行。