操作契约
目标：
- 定义系统操作。
- 为系统操作创建契约
在UP中，用例和系统特性是用来描述系统行为的主要方式，并且足以满足要求。有时需要对系统薪给进行更为详细和精确的描述。操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化，并作为系统操作的结果。领域模型是最常用的OOA模型，但是操作锲约和状态模型也能够作为有用的与OOA相关的制品。
操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。
契约的主要输入时SSD中确定的系统操作、领域模型和领域专家的见解。该契约也可以作为对象设计的输入，因为它们描述的变化很可能时软件对象或数据库所需要的。
示例
契约CO2：enterItem :
- 操作：enterItem(itemId:ItemID, quantity:integer)
- 交叉引用：用例：处理销售
- 前置条件：正在进行的销售
- 后置条件：
- 创建了SalesLineItem的实例sli（创建实例）。
- sli与当前Sale关联（形成关联）。
- sli.quantity赋值为quantity（修改属性）。
- 基于itemID的匹配，将sli关联到ProductDescription（形成关联）。
定义：契约有哪些部分
- 操作：操作的名称和参数。
- 交叉引用：会发生此操作的用例。
- 前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。这些假设比较重要，应该告诉读者。
- 后置条件：最重要的部分。完成操作后，领域模型对象的状态。后续章节将详细论述这个问题。
定义：什么时系统操作
可以为系统操作定义操作契约，系统操作时作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD时确定。更精确地讲，SSD展示了系统时间，即设计系统的事件或I/O消息。输入的系统事件意味着系统具有用来处理该事件的系统操作，正如OO消息要由OO方法来处理那样。
涉及所有用例的系统操作的完整结婚将系统视为一个构件或类，定义了公共的系统接口。在UML中，作为整体的系统可以表示成名称为System的类的一个对象。
定义：后置条件
后置条件描述类领域模型内对象状态的变化。领域模型状态变化包括创建示例、形成或消除关联以及改变属性。
后置条件不是在操作过程中执行的活动，相反，它们时对领域模型对象的观察结果，当操作完成后，这些结果为真。
后置条件可以分为以下三种类型：
- 创建或删除实例。
- 属性值的变化。
- 形成或消除关联（精确的讲，时UML链接）。
后置条件如何与领域模型相关
这些后置条件主要时在领域模型对象的语境表示的。
动机：为什么需要后置条件
首先，后置条件并不总是必要的。大多数情况下，系统操作的效果对开发者而言时相对清晰的，他们可以通过阅读用例、与专家交流或根据子集的姿势对此进行理解。但有时需要更详细和精确的描述。契约正提供了此类描述。
契约时优秀的需求分析或OOA工具，能够详细描述系统操所需的变化，而无需描述这些操作时如何完成的。
换言之，涉及可以被延迟，我们可以重点分析必须发生的事物，而不是如何实现这些事物。
准则：如何编写后置条件
用过去时态表达后置条件，以强调它们时有操作引起的状态变化的观察结果，而不是发生的活动。
类比：后置条件的本质：舞台和幕布
为什么以过去时态编写后置条件？可以通过以下比喻来理解：
系统及其对象出现在剧院的舞台上。
- 在操作前，对舞台拍照。
- 落下幕布，应用系统操作（后台内叮当、尖叫、喊叫的嘈杂声）。
- 打开幕布，拍摄第二章照片。
- 比较前后两张照片，把舞台状态的变化表述为后置条件。
准则：后置条件应该完善到何种程度？敏捷与重量级分析
契约有可能时无用的。但是假设契约有用，则为所有系统操作生成完整详细的后置条件集合时不可能的，或是没有必要的。
示例：enterItem后置条件
创建和删除实例
属性修改
关联形成和消除
准则：是否应该更新领域模型
通常在创建契约的过程中会发现，需要在领域模型中记录新的概念类、属性或关联。不要局限于先前定义的领域模型，当你在思考操作契约过程中有新发现时，要对领域模型进行改进。
在迭代和进化式方法中，所有分析和涉及制品都不是完善的，要根据新发现对其改进。
准则：契约在何时有效
在UP中，用例时项目需求的主要知识库。用例可以为涉及提供大部分或全部所需细节。这种情况下，契约就没有什么作用。但有时对于用例而言，所需状态变化的细节和复杂性难以处理或过于细节化。
后置条件的形式提供并提倡了十分精确的分析性语言，能够支持充分的详细程度。
如果开发者在没有操作契约的情况下，能够准确地理解所需要完成的工作，则可以不编写契约。
准则：如何创建和编写契约
创建契约时可以应用以下指导：
- 从SSD中确定系统操作。
- 如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约。
- 使用以下集中类别来描述后置条件：
- 创建和删除实例。
- 修改属性。
- 形成和清除关联。
编写契约
- 以说明性的、被动式的过去时态编写后置条件，以便强调变化的观察结果，而非其如何实现的涉及。
- 记住，要在已有或新创建的对象之间建立关联。
常见错误
最常见的问题时遗漏了关联的形式。特别是当创建了新实例时，通常需要建立与若干对象的关联。
示例：NextGen POS 契约
示例：Monopoly契约
应用UML：操作、契约和OCL
本章中所给出的契约和UML之间有怎样的关系？UML正式地定义了操作。引证如下：
操作时可以调用对象执行的转换或查询的规格说明。
在UML中，接口元素就是操作。操作时抽象而非实现。相比之下，方法时操作的实现。印证如下：
[方法是]操作的实现。它规定了与操作关联的算法或过程。
在UML元素中，操作具有特征标记，在这种语境中最为重要的是，与一组UML约束对象关联，这些对象被分类为指定操作语义的前置条件和后置条件。
概括以下，UML通过约束定义操作的语义，这些约束可以用前置或后置的形式指定。要注意，本章强调UML操作的规格说明不能表示算法或解决方案，而只能是状态的变化或操作的效果。
契约除了用于指定整个System的公共操作外，还能够用于任何粒度的操作：子系统的公共操作、构件、抽象类等。本章讨论的粗粒度操作属于讲整个系统作为黑盒构件的System类，但是UML操作可以术语任何类或接口，它们都具有前置和后置条件。
用OCL表示的操作契约
本章中的前置和后置条件的格式非正式的自然语言，完全可以被UML接受，并易于理解。
但UML还具有更正式、严谨的语言，称为对象约束语言，OCL可以用来表示UMl操作的约束
出发有不可避免的实际源于要求人们学士和使用OCL，否则要保持简单并使用自然语言。经过我确信存在真实的应用，但我从未见过使用OCL的项目，级别我调查了大量客户和项目。
过程：UP的操作契约
前置和后置条件契约是UML指定操作的常用风格。在UML中，操作在许多界别中存在，从System到细粒度的类。系统级别的操作契约是用例模型的一部分，经过原始的RUP或UP文档中并没有正式的强调这一点。RUP作者，证实了用例模型中包括操作锲约。
阶段
- 初始：初始阶段不会引入契约，因为过于详细。
- 细化：如果使用契约的化，大部分契约讲在细化阶段进行编写，这是已经编写了大部分用例。只对最复杂和微妙的胸痛操作编写契约。