连载：面向对象设计精髓：理念、技术与实践（27）-动态模型构建

类模型教会我们如何定义类，而动态模型则指导我们如何实现类的功能。动态模型设计通常是在类模型设计完成后进行的，因为动态模型设计需要利用到已定义的类。与类模型相比，动态模型设计较为直接，主要原因是动态模型设计时并不需要应用复杂的设计原则或模式，只需根据用例模型的特点，选择合适的动态模型来表达即可。

在实际开发中，动态模型起着至关重要的作用。简而言之，如果没有动态模型，即使完成了类的设计，也无法进行编码，或者只能编写类的声明代码（如类的属性和方法名），但无法编写类的实现代码（即方法的具体逻辑）。动态模型正是用于指导我们如何编写这些具体的实现代码。

对于何时需要进行动态模型设计，这取决于个人判断。如果认为某个部分较为复杂，就需要设计；反之，如果觉得简单，则可以直接编码。这一决策往往基于个人的经验。例如，在我的实际工作中，一个中等规模的项目可能只需要设计一两个业务的动态模型，而对于小型项目，我通常会直接根据需求编码。

根据UML标准，以下是几种常见的动态模型：

【状态模型】

状态模型用于描绘对象在其生命周期内的状态变化。通过状态图，可以清晰地了解对象的不同状态及其转换条件。当对象的状态变化较为复杂时，设计状态模型尤为重要。

在UML中，状态图用于表示状态模型。

【活动模型】

活动模型用于描述工作流程或计算流程。它关注的是在完成某项任务的过程中，各个对象的角色和它们之间的交互顺序。当流程较为复杂时，设计活动模型有助于理清思路。

在UML中，活动图用于表示活动模型。

【序列模型】

序列模型用于展示对象间按时间顺序的消息交互过程。它的关键在于“时间顺序”，因此也被称为时序图或顺序图。序列模型是最常用的动态模型之一，特别适用于将用例模型或系统序列图转化为动态模型。

在UML中，序列图用于表示序列模型。

【协作模型】

协作模型用于展示基于对象间关系组织的消息交互过程。其特点在于强调“对象关系”而非时间顺序。虽然协作模型与序列模型作用类似，但在大多数情况下，序列模型因其时间顺序与用例模型步骤的一致性而更受欢迎。

在UML中，协作图用于表示协作模型。

需要注意的是，并非所有模型都是必需的，应根据实际情况选择使用。这些模型可以从用例模型中推导出来，尤其是活动模型、序列模型和协作模型，通常与用例模型一一对应，或对应某个特定分支。通常不建议在一个模型中包含多个分支，以免图形过于复杂且主题不明确。

相比之下，状态模型较为复杂，因为不能仅从单个用例或其分支直接推导出某个对象的所有状态。需要综合多个用例模型，提取与该对象状态相关的信息，再进行统一设计。

从用例模型推导出动态模型的过程是一种“分解和分配”的过程。在用例模型中，系统被视为一个“黑盒”，而在动态模型中，系统被细分为多个类。因此，需要将原本笼统分配给系统的功能和职责进一步细化，并分配给不同的类。简而言之，动态模型明确了为了实现系统的某一功能，各类需执行的任务及其顺序。

以POS机为例，假设我们基于“结账”这一用例的正常流程设计“序列模型”，则可得到相应的“序列模型”。有了这个“序列图”，编写代码时可以参照以下伪代码（实际编码会更加复杂，但方法相同）：

main(){
    Trade trade = new Trade();
    Integer tradeId = trade.makeNewTrade();  // 创建交易
    trade.addGoods();                       // 添加商品
    trade.calculateTotal();                 // 计算总价
    Receipt receipt = new Receipt();
    receipt.print(trade);                  // 打印收据
    trade.finish();                        // 结束交易
}