第四部分:使用 Altova UModel 分析现有应用程序
在系列文章的第一部分中,我们导入了源代码到Altova UModel,以创建一个UML项目,并分析了我们现有ATM应用程序的类图。
在第二部分中,我们创建了一系列UML用例图,用于描述用户与系统的交互,并计划进行一项应用升级,以实现收取提现手续费的功能。
在第三部分中,我们设计了一个UML状态机图,以进一步分析和记录我们系统的运作。在本部分,我们将回到我们之前计划的改进。我们被分配的任务是实施一种ATM取款费用:取款金额少于100美元时收取2美元的费用,取款金额达到或超过100美元时收取4美元的费用。在第二部分中,我们绘制了一个用例图,以展示用户将如何与这个新功能进行交互
![]()
在第一部分中,我们对面向对象类进行了分析,了解到我们的系统中包含一个“提款”类,这正是实现新功能的理想位置。我们可以通过在模型树中选择“提款”类,然后在右键菜单中选择“创建新图”,来显示该类的新的类图。
![]()
![]()
我们选择创建一张层次图,以便清晰地展示“提款”类(Withdrawal class)的所有属性,包括从“交易”类(Transaction class)继承的属性。在实现费用功能之前,我们还有一些相关问题需要调查。我们希望验证当前的代码是否包含一个测试,以确保用户请求的提款金额不超过当前账户余额。一张UML序列图可以帮助我们追踪提款操作的执行流程。UModel可以自动从反向工程处理的类中生成序列图。我们可以在类图中选择“执行”操作,然后从UModel的右键菜单中选择“生成序列图”,从而创建所需的图表。
![]()
UModel序列图生成对话框提供了多种选项,这些选项将有助于我们实现新功能。我们选择了“自动更新”选项,因为我们希望在修改代码后,能够自动更新图表。此外,将代码显示在单独的图层中,可以帮助我们更好地专注于提款逻辑。
![]()
滚轮大小表明我们当前只看到序列图的一小部分。我们可以缩小视图以适应窗口,但文本可能难以辨认。 另一种方法是利用 UModel 灵活的用户界面,自动隐藏“图表”树和“属性”窗口,这样我们就可以放大“概览”辅助窗口:
![]()
我们可以通过在“概览”窗口中拖动红色方块来浏览序列图。 这样,我们就能快速找到关于提款金额和账户余额的比较信息。
![]()
我们还可以看到错误提示信息,例如当自动取款机内现金不足或账户余额过低时,就会显示这些提示。
![]()
回到“退款”类图,我们可以添加“费用”属性,并设置其默认值:
![]()
我们将首先实现费用逻辑,但暂时不包括用户取消选项。通过从我们的模型更新源代码,我们将在 Withdrawal 类中添加费用属性。然后,我们将打开我们常用的代码编辑器,直接在 Withdrawal.java 文件中实现费用逻辑。对重新编译后的应用程序进行测试,结果如下:
![]()
初始余额为147美元。在提取了100美元后,新的余额为43美元。费用信息显示在一个新的提示信息中,并且最终余额是正确的。但是,我们UML模型中的序列图现在不准确,因为它没有包含费用功能。我们可以通过更新UML项目,使用修改后的源代码来修正序列图。UModel消息窗口显示,对Withdrawal.java文件的更改导致序列图被重新生成。此外,我们可以轻松地浏览该图表,找到我们新的关于提取金额的测试,以查看费用是否需要增加到4美元。
![]()
现在,经过修改的序列图以图形化的方式展示了ATM的更新后的运行流程,我们可以确信,在系列文章的第三部分中我们遇到的那位忙碌的司机有足够的现金来购买那个冰淇淋甜筒了!在下一部分,我们将利用UModel的另一个功能,为我们迄今为止的工作生成丰富的项目文档——这是保持我们的UML模型和应用程序源代码同步的又一个优势。
如果您想在您现有的 Java、C# 或 Visual Basic 应用程序上试用 Altova UModel,请点击此处下载一个免费的、功能齐全的 30 天试用版