装运服务

    Shipping 服务协议有一些复杂。想要运送产品的消费者请求运送服务。然而，运送者可能会花一些时间来决定产品被放置在哪里，它们是否在可用清单中或者是否需要被生产，以及运送产品的最有效的方式。因此，运送时间表使用前需要一段时间。消费者通常不希望等到时间表完成，因为这会阻止并行中的其他工作，或者不必要的将系统资源消耗在长进程上。

    因此，IT 架构师决定在消费者和提供者之间使用一个简单的请求响应或者回叫协议。消费者请求运送，过一段时间之后，响应来自运送者的请求来处理完全的时间表。要对这一协议进行建模，我们需要指定生产者和消费者这两个角色，它们的职责、以及它们进行交互的协议或者规则。最后一部分是非常重要的，这是因为如果运送者接收不到一个运送请求，那么它们将不能发送时间表。

    服务规范告诉您需要知道的关于服务的任何事情。这包括您必须满足的使用服务的需求（有时被称作 Use 或者 Usage 契约，请参见 Resources 中列出的 Daniels 和 Cheesman 的文章，再加上服务必须满足的应用的需求（有时被称作 Realization 契约）。这是您需要为业务需求捕获的同一类信息；除了主题区域和细节级别是不同的之外。您将在涉及服务消费者和提供者如何进行交互的 Service Requirements 契约中定义该规范。

    在这种情况下，我们使用一个抽象类来定义服务规范，如图5所示。

    图5. Shipping 服务规范
     

    ShippingService 规范涉及到两个角色：

    角色 shipper 是一个提供者的角色。它负责满足其类型赋予它的运送的职责，即运送接口。
    角色 orderer 负责处理运送进度表。这通过其 ScheduleProcessing 类型被显示。

    将这些角色指明为提供者和消费者并不是必须的。在一个潜在的长期运行的会话中（可能涉及到多方），这些只是任意的区别。通过 Service 规范实现被提供的运送接口和使用被需要的 ScheduleProcessing 接口，也很容易看出谁是消费者、谁是提供者。

    在运送者和订货人角色之间有一个连接器。它指出了在这些角色之间涉及某些交互作用的协议。requestShipping 交互作用为 ShippingService 类所拥有，它显示了这个交互作用是什么。

    ShippingService 交互作用指定了订货方运送方角色之间交互的行为的或者动态的方面。订货方首先发送一个 requestShipping 消息（或者调用运送方的 requestShipping 操作），一段时间后，必须响应来自运送方的 processSchedule 消息。交互作用涉及到两条生命线：一条用于订货方，另一条用于运送方。这些对象实例就是 Service 规范类中的订货方和运送方属性。也就是说，消息在哪些角色之间通过连接器被交换。这是一个简单的、异步的请求/响应或者回叫模式，它是许多服务协议的典型应用。

    ShippingService 协议通过使用任何 UML 2 行为被指定，这些行为可以是：活动、交互、状态机、或者不透明行为（代码）。选择哪一种来使用取决于建模者、他们更加偏爱的风格、或者问题域的适用性。