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

Question

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

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

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

程序员必须与用户交谈并尝试了解用户以哪种形式发现问题。当点击按钮“Ok”时，它是Form_Payr.1.2.aspx。然后程序员将返回他的座位并且必须检查Form_Payr.1.2.aspx中发生了什么，从vb代码调用了什么类和方法，如果在业务层或数据库的存储过程中执行了进程，最后得到什么问题。程序员只能通过IDE和调试来完成所有这些任务。

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

• 关于如何记录这种地图有什么最好的做法吗？

Answer 1

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

Answer 2

  

  
• 是否有任何UML文档或图表将映射哪些程序   （vb或aspx）调用什么clasess或方法，以及它们的进程   运行，因此维护起来会更容易或更快。
  

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

  

  
• 关于如何[记录]这种地图有什么最好的做法吗？
  

在您所指的详细程度上，手动创建反映代码的图表实际上是不可能的。维护两者都需要付出太多努力。你基本上有两个选择：

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

选项（2）基本上有两种方法。 Model-Driven Development通常主张从模型生成代码。它可以（并且确实）起作用，但它是你必须购买的范例。如果您更乐于编写代码，那么有些工具可以从代码中生成图表，例如： Enterprise Architect。我相信Visual Studio也支持这个，虽然没有使用它。

第h