第三部分：使用 Altova UModel 分析现有应用程序

在系列文章的第一部分中，我们使用了Altova UModel的逆向工程功能，从现有的ATM模拟应用程序中导入源代码。我们创建了一个UML类图，用于展示该应用程序的类层次结构和类之间的关系。在第二部分中，我们绘制了一个UML用例图，用于记录用户与系统的交互，并绘制了几个额外的用例图，用于记录交互细节以及一个计划中的改进。在本期文章中，我们将从另一个角度来分析ATM系统。

在一个炎热的夏日午后，一位疲惫的司机前方看到一个冰淇淋店，店里设有免下车购买通道。但出现了一个问题——他身上没有现金！于是，他拐进购物中心的停车场，将车停在玻璃隔间的自动取款机旁边。还没下车，这位焦躁的银行客户就开始担心自动取款机的状况。是不是已经有其他客户在里面办理复杂的银行业务？即使隔间里没有人，自动取款机也可能已经停止服务了吧？

统一建模语言 (Unified Modeling Language) 的缩写 状态机图 （也称为状态图）可以帮助我们了解模拟的自动取款机所处的状态，以及触发这些状态的因素、事件以及状态之间的转换，从而更好地理解我们的旧应用程序的运行方式。现在，让我们再次回顾一下运行模拟的经验，以便开始：

当我们启动了该遗留应用程序时，我们的模拟ATM进入了空闲状态，等待着第一位顾客

接下来，可以尝试识别并绘制其他状态，并将它们以独立的椭圆形式呈现。 这样，我们可以像拼图一样移动这些椭圆，找到逻辑顺序，而无需担心从一个状态到下一个状态之间的转换。

这份自动取款机（ATM）状态的初步列表只是我们最初的草稿。这些状态的描述是根据我们现有应用程序的菜单项提出的，很明显我们可以进行简化：

• “选择第一笔交易”和“选择下一笔交易”之间没有区别，因此应该合并这两个选项。
• “注销”可能不是一个状态，而是在用户在交易菜单中按下“4”时发生的瞬间操作。
• 我们可以将用户输入的取款金额或存款金额作为“执行交易”状态下的子状态。

第三项修改可以简化我们的图表，并且与我们对用户输入的账号和密码作为“用户身份验证”一部分的处理方式保持一致。

在进行这些修改并添加状态转换后，我们的图表将如下所示：

我们添加的简单转换是触发器，它们会导致自动取款机从一个状态转换到下一个状态。请注意，每个状态都至少有一个入口和一个出口——否则，旧系统可能会将我们的用户困在死胡同里。在“选择交易”和“执行交易”之间的菱形元素是 UML 图中表示流程选择的符号。最初，可能看起来不合逻辑，因为应用程序允许用户在执行任何交易之前退出，但这正是我们的旧系统在“交易”菜单中提供的一个选项。而且，现实世界中的用户经常会在最后一刻改变主意！我们在命名元素和描述时，尽可能使用一致的语言。状态名称使用现在时动词，以“-ing”结尾。转换的标签用于指示导致状态改变的动作完成。一致的元素命名方式可以提高图表的清晰度。

一旦我们有了像上面那样的工作状态图，就值得考虑一下，如果尝试进行状态转换，但未能成功会发生什么。例如，ATM用户可能输入了无效的账号/密码组合，或者经过身份验证的用户可能请求取款金额超过了账户余额。我们可以改进我们的状态图，以包含这些可能性：

现在，我们的状态机图展示了应用程序执行过程中许多不同的路径，而不仅仅是单一的、所有环节都顺利的“理想路径”。 我们选择了垂直布局来呈现我们的图表，但并没有任何规定必须采用这种形式。 某些应用程序可能更适合水平布局，或者这可能仅仅是您的个人偏好。 下图展示了我们状态机图的一部分，采用水平布局：

无论您选择哪种状态机图的布局方式，都应该避免绘制相互交叉或重叠的转换线。绘制 UML 状态机图可能对于我们的 ATM 模拟来说显得有些复杂，因为现有的应用程序规模较小，而且我们都熟悉 ATM 的工作原理。然而，这些技术在您需要处理更大规模、运行在不熟悉或复杂领域中的应用程序时，可以提供非常有用的指导。

如果您准备好为您的 Java、C# 或 Visual Basic 遗留应用程序创建 UML 状态机图，请点击此处下载 Altova UModel 的免费、功能齐全的 30 天试用版 在下一部分，我们将详细介绍提款交易以及我们在第二部分中计划的新功能。