3.7 实现用例

用例用来描述系统应能实现的独li功能，实现用例就是在系统内部实现用例中所描述的动作，通过把用例描述的动作转化为对象之间的相互协作，完成用例的实现。UML 中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。协作的实现用脚本描述。具体内容是：
（1）用例实现为协作
协作是实现用例内部依赖关系的解决方案。通过使用类、对象、类（或对象）之间的
关系（协作中的关系称为上下文）和它们之间的交互实现需要的功能（协作实现的功能又称交互）。协作的图示符号为椭圆，椭圆内部或下方标识协作的名字。
（2）协作用若干个图表示
表示协作的图有协作图、序列图和活动图。这些图用于表示协作中的类（或对象）与
类（或对象）之间的关系和交互。在有些场合，一张协作图就完全能够反映出实际用例的协作画面，而在另一些场合，只有把三种不同的图结合起来，才能反映协作状况。
（3）协作的实例——脚本
前文已经讲过，脚本是用例的一次具体执行过程，它代表了用例的一种使用方法。当
把脚本看作用例的实例时，对角色而言，只需描述脚本的外部行为，也就是能够完成什么样的功能，而忽略完成该角本的具体细节，从而达到帮助用户理解用例含义的目的；当把脚本看作协作的实例时，则要描述脚本的具体实现细节（利用类、操作和它们之间的通信）。
实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类、类的操作
和 类之间的关系。具体说来，就是把用例中每个步骤所完成的工作交给协作中的类来完成。实质上，每个步骤转换成类的操作，一个类中可以有多个操作。注意，一个 类可以用来实现多个用例，也就是，一个类可以集成多种角色。比如，自动售货系统中，负责“供货”和“提取货款”的角色就可以定义为同一个类（当然，从安全 角度讲，最好不要定义为同一个类）。
用例和它的实现（即协作）之间的关系可以用精化关系表示（图示为带箭头的点画线），也可以用CASE 工具中的不可见的超链实现。使用CASE 工具中的超链，能方便地将用例视图转换为协作或脚本。图3-10 表示一个用例的实现，从图中可以看出若干个类加到了协作中。为了实现用例，用例描述中的每个步骤的职责还需转换为类与类之间的协作（用关系和操作描述）。

若想成功地利用类表示用例描述，需要借助开发者的经验。通常，开发者必须反反复
复地多次试验各种不同的可能情况，逐步完善解决方案，使该方案能够实现用例描述且灵活易扩展。如果将来用例描述改变了，只要将其对应的实现作简单地修改即可。
另外，UML 的创始人Jacobson 定义了三种类型的版类对象类（stereotype object types）；边界对象（又称接口对象）、控制对象和实体对象。还可以利用这三个对象类描述用例的实现。每个对象类能胜任的职责是：
（1）边界对象（boundary objects）
这种对象类紧靠系统的边界（虽然仍在系统内部）。它负责与系统外部的角色交互，
在角色和系统内部的其它对象类之间传递消息。
（2）控制对象（control objects）
这种对象类控制一组对象之间的交互。控制对象可以是刺激用例启动的角色，也可以
用来实现若干个用例的普通序列。控制对象通常仅存在于用例执行阶段。

（3）实体对象（entity objects）
这种对象类代表系统控制区域内的区域实体。它是被动对象本身不能启动交互。在
信息系统中，实体对象通常是持久的，存储在数据库存，中实体对象也可以出现在多个用例中。
上述三个对象类各有自己的图标，可以用来图示协作和类图。在定义了不同的对象类
和详细说明了一个协作之后，也可以用一个具体的活动测试用例，确认对象的实现方式，以便这些类重用在其它用例中，Jacobson 将这种开发过程称为用例驱动的开发过程。
实现用例有多种不同的方法。不同的实现方法为实现用例的类分配不同的功能。有些
方 法采用先建立作用域分析模型（用于显示所有的作用域类及其它们之间的关系），然后才处理用例，为分析模型中的类分配应完成的功能，在这个过程中有时会修改 分析模型或在模型中添加新的类。另外一些方法则把用例当作发现类的基础，在为类分配应完成功能的同时，逐步建立作用域分析模型。总之不论采用何种方法，对 开发者来说，要明白这种实现工作将是反反复复的过程。也就是说，当利用用例为类分配功能时，或许可以发现类图中的错误和遗漏，这时，必须返回去修改类图或 者建一个新类来反映用例的本意。当然，在某些情况下，可能必须修改用例图，因为初期建造的用例图不一定完全正确地描述系统的功能，随着开发者对系统功能的 深入理解，原图之中的不足之处就可能暴露出来。最后一点需要说明的是，并不是所有面向对象的方法都提供用例图。比如有的方法只提供类和对象等静态结构，忽略系统开发过程中其它方面的描述。