作者:印大大 | 来源:互联网 | 2024-12-11 06:15
类模型教导我们如何定义类,而动态模型则指导我们如何实现类的功能。通常,在完成类模型设计后,才会进行动态模型的设计,因为后者依赖于前者提供的类结构。相比类模型,动态模型设计更为直观,主要因为它较少涉及复杂的设计原则或模式。
类模型教会我们如何定义类,而动态模型则指导我们如何实现类的功能。动态模型设计通常是在类模型设计完成后进行的,因为动态模型设计需要利用到已定义的类。与类模型相比,动态模型设计较为直接,主要原因是动态模型设计时并不需要应用复杂的设计原则或模式,只需根据用例模型的特点,选择合适的动态模型来表达即可。
在实际开发中,动态模型起着至关重要的作用。简而言之,如果没有动态模型,即使完成了类的设计,也无法进行编码,或者只能编写类的声明代码(如类的属性和方法名),但无法编写类的实现代码(即方法的具体逻辑)。动态模型正是用于指导我们如何编写这些具体的实现代码。
对于何时需要进行动态模型设计,这取决于个人判断。如果认为某个部分较为复杂,就需要设计;反之,如果觉得简单,则可以直接编码。这一决策往往基于个人的经验。例如,在我的实际工作中,一个中等规模的项目可能只需要设计一两个业务的动态模型,而对于小型项目,我通常会直接根据需求编码。
根据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(); // 结束交易
}