下载掌阅APP，畅读海量书库
立即打开
UML中的用例和用例图的主要用途是描述系统的 （8） 。
（8）A．功能需求
B．详细设计
C．体系结构
D．内部接口
用例（Use Case）是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。
从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就是用例方法的基本思想。在用例图中，主要包括参与者、用例和通信关联三种元素，如图1-3所示。
图1-3 用例图中的基本元素
（1）参与者（Actor）。参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表系统的使用者或使用环境。
（2）用例（Use Case）。用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
（3）通信关联（Communication Association）。通信关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。
用例设计的主要目的如下：
（1）利用交互改进用例实现；
（2）调整对设计类的操作需求；
（3）调整对子系统和（或）它们的接口的操作需求；
（4）调整对封装体的操作需求。
一个系统的行为可以用许多方法来说明，包括协作或者交互的方法。用例设计通常使用交互（特别是序列图）来说明系统的行为。当系统或者子系统的行为主要通过同步消息传递来说明时，序列图非常有用。由于消息序列通常没有严格的定义，因此，尤其是在事件驱动系统中，异步消息传递更容易利用状态机和协作来进行说明。
用例方法完全是站在用户的角度上（从系统的外部）来描述系统的功能的。在用例方法中，我们把被定义系统看作是一个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。用例方法首先描述了被定义系统有哪些外部使用者（抽象成为Actor），这些使用者与被定义系统发生交互；针对每一参与者，用例方法又描述了系统为这些参与者提供了什么样的服务（抽象成为Use Case），或者说系统是如何被这些参与者使用的。所以从用例图中，我们可以得到对于被定义系统的一个总体印象。
与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，用例定义了系统功能的使用环境与上下文，每一个用例描述一个完整的系统服务。用例方法比传统的SRS更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的一个有效手段。
（8）A