Uml 需要关于如何记录程序的建议吗

我了解UML的基本知识： -用例 -活动图 -类图 -序列图

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

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

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

我的问题是: -是否有任何UML文档或图表可以映射哪些程序（vb或aspx）调用了哪些类别或方法，以及它们运行了哪些流程，以便更容易或更快地进行维护

• 关于如何记录此类地图，是否有最佳实践

---

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

• 是否有任何UML文档或图表可以映射哪些程序 （vb或aspx）调用什么类或方法，以及它们调用什么进程 运行，以便更容易或更快地进行维护

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

• 关于如何记录这种地图，有什么最佳实践吗

在您所指的详细级别上，实际上不可能手动创建反映代码的图表。这两方面都需要付出太多的努力。您基本上有两种选择：

在更高抽象级别创建手动图表。这些可以让我们了解系统是如何工作的，但对细节没有帮助。您仍然需要一个过程来积极维护它们，否则它们将变得陈旧和毫无价值。由于开销（时间和规程）的原因，手动图表往往能够很好地记录解决方案中的基本模式；e、 g.关键架构机制或领域概念。它们往往不会经常改变，并提供了系统的有价值的概述

确保代码和图表自动保持同步。实际上，这意味着从另一个生成一个。两者都有可能 方案（2）基本上有两种方法。通常主张从模型生成代码。它可以（而且确实）起作用，但这是一个你必须接受的范例。如果您更喜欢编写代码，那么有一些工具可以从代码生成图表，例如。我相信VisualStudio也支持这一点，尽管还没有使用它

---

hth.

您的序列图不是显示了类之间的交互和进程流吗？我认为好的书面文档比图形更有用。有一些工具可以帮助您生成自己的API文档，例如。