货品计价服务

    为发货单计算初始的和最终的价格，涉及到订货者和货品计价之间一个更加复杂的协议。显然，initiatePriceCalculation 必须在 completePriceCalculation 之前被调用。然后，订货者必须被准备来作为结果的发货单。

    我们能够通过使用一个指定发货方和订货方角色、它们的职责、以及它们之间如何交互的协议（会话或者规则）的抽象类来捕获这个协议。这就像 ShippingService 规范，除了交互作用仅仅是简单的请求/响应之外。为了服务的有效使用，服务功能性必须以一种顺序被调用。

    图6中显示的 InvoicingService 服务规范捕获了这一协议。请注意该服务规范也执行了 Invoicing 用例。一个用力可能被用来反映服务指定的需求。该服务规范包括两个角色：发货方和订货方。这些角色的类型分别是 Invoicing 实现的接口和被使用的 InvoiceProcessing 接口。这些接口封装了角色（服务或者请求功能或者操作）的职责。服务规范中的 InvoicingService 活动为使用服务操作指定了协议，在订货方和发货方角色之间能够发生的实际交流。

    
    图6. InvoicingService 服务规范
 
    nvoicingService 是一个指定订货人和发货单之间的会话、交流协议、或者交互规则的类。协议的细节在该类的 ownedBehavior 中被捕获，并被用来为使用这一服务指定有效的交互模式。在这种情况下，该协议被表达为一种 UML 活动。

    该协议指示出订货方必须在试图得到完全的价格计算之前，启动一个价格计算。订货方然后必须响应一个请求（在本例中是回叫）来处理最终的货物。一些请求货品计价服务的消费者只需执行这三种操作，但是这些指定操作的顺序是受到协议约束的。没有一个 InvoicingService 活动中的 ActivityPartitions 反映 InvoicingService 类中的角色或者属性。一个属于某个分区的操作祈祷行动指示出祈祷处于分区所反映的角色（行动的目标输入码正是活动分区所反映的角色）。

    在这种情况下，在订货人和货品计价服务之间只有一种交互作用，所以服务规范类只有一个 ownedBehavor。在另一种情况下，消费者和提供者之间会有超过一种的交互作用，每一种都是用不同的协议。服务规范将拥有一个 ownedBehavior 为每一个会话指定有效的交互模式。

    您并不知道哪个服务提供者执行了一个 InvoicingService。您也不知道哪个服务消费者可能使用它。您只知道任何一个消费者使用服务必须做什么，以及任何一个提供者执行它时必须做什么。