需要有关如何记录程序的建议

Question

我知道关于 UML 的基本知识： - 用例 - 活动图 - 类图 - 序列图

所有这些对我来说都很棒。我可以对系统或应用程序有一个一般的“愿景”或“理解”。但只是“一般”。

想想这个例子：程序员必须第一次处理应用程序。我提到的所有 UML 文档都将帮助他对系统有一个大致的了解。但有一天他的老板对他说：“‘工资核算流程’有问题，检查一下。”

程序员必须与用户交谈并尝试了解用户发现问题的方式。单击“确定”按钮时，它是 Form_Payr.1.2.aspx。然后程序员将回到他的座位上，必须查看 Form_Payr.1.2.aspx 中发生了什么，从其 vb 代码中调用了哪些类和方法，是否在业务层中执行流程或在数据库中的存储过程中执行，最后得到什么问题。程序员仅使用 IDE 和调试来完成所有这些任务。

我的问题是： - 是否有任何 UML 文档或图表可以映射哪些程序（vb 或 aspx）调用哪些类或方法，以及它们运行哪些进程，这样维护起来会更容易或更快。

• 关于如何记录此类地图是否有任何最佳做法？

Answer 1

• 是否有任何 UML 文档或图表可以映射哪些程序 (vb 或 aspx) 调用什么类或方法，以及它们的处理过程 运行，因此维护起来会更容易或更快。

是的 - 您已经提到了最相关的图表（序列/活动）。问题不在于图表，而在于确保图表与代码一致。

• 关于如何[to]记录此类地图是否有任何最佳做法？

就您所指的详细程度而言，手动创建反映代码的图表实际上是不可能的。维护两者都太费力了。你基本上有两种选择：

1. 在更高的抽象级别创建手动图表。这些可以使您了解系统的工作方式，但对细节无济于事。您仍然需要一个积极维护它们的过程，否则它们将变得陈旧和毫无价值。由于开销（时间和纪律），手动图表往往可以很好地记录解决方案中的基本模式；例如关键架构机制或领域概念。这些往往不会经常更改，并提供了有价值的系统概览。
2. 确保代码和图表自动保持同步。实际上，这意味着从另一个生成一个。两者都是可能的。

选项（2）基本上有两种方法。 Model-Driven Development 一般提倡从模型中生成代码。它可以（并且确实）起作用，但这是您必须接受的范例。如果您更喜欢编写代码，那么有一些工具可以从代码生成图表，例如Enterprise Architect。我相信 Visual Studio 也支持这个，虽然没用过。

第一次。

Answer 2

我不确定任何数量的 UML 图是否真的能帮助开发人员追踪错误。这就是调试器和 IDE 的用途。您提到的图表和地图显然会记录应该发生的事情，而问题可能是发生了其他事情。那可能是在任何时间点。它甚至可能很难重现，因为它是某个地方的竞争条件。我的建议是，投资一个好的 IDE、调试器和分析器，并鼓励您的开发人员掌握它们。