为了防止正在进行的项目退化，在项目的整个生命周期内记录所有更改并更新架构是非常重要的。然而，由于各种原因并非总是如此。 因此，已经从源代码中对SA的自动恢复进行了一些研究。特别有趣的是系统在运行时的动态视图。
通过动态视图，我可以参考视图，其中显示了组件之间方法调用的信息（例如，UML中的序列图）。
由于我没有软件架构设计方面的经验，我的问题是：
例如，
或任何其他建议。
此外，您在整个职业生涯中经历过的有哪些工具很有意思？我遇到的一个示例工具是kieker框架，它完全符合我的要求，但在我看来缺乏良好的可视化技术。
答案 0 :(得分：1)
软件架构师通常对应用程序中存在的组件感兴趣。您应该在架构描述（组件模型，耦合决策等）中寻找所需的东西。
选择在它们之间进行大量通信的组件可能是一个兴趣点。据我所知，从这个问题来看，你似乎已经有了一个过时的架构描述。与它进行比较以查看哪些点已更改，新代码是否引入了高耦合？新方法是否违反了图层规则？
兴趣点可包括：
虽然这些工具可能无法访问，但如果您记住这些内容，您可能会对它们有所帮助。从底部（例如源代码）到顶部的工作过程称为：“逆向工程”。
如需进一步阅读，我建议these slides。
<强>更新
动态视图侧重于监控流程，并在此过程中恢复SA信息。正如这句话所解释的那样：
静态分析旨在恢复软件系统的结构，而动态分析则侧重于其运行时行为。
但实际上，他们不是朝着同一个目标努力吗？虽然监控过程与静态分析不同，但两者都有助于恢复架构。这些方法应该恢复的详细程度（可能是您的问题）取决于项目的大小和为此任务提供的时间量。
我们是在谈论一个大型项目（完整的银行系统）还是更小的项目？它真的是时间的选择。由于动态分析通常需要很长时间才能完成，因此您可能会问自己是否真的需要该工具可以获得的所有信息。对于中型项目，我会对以下问题感兴趣：
只需这三个问题就可以恢复大部分组件模型。在这种情况下，您仍然会遗漏许多软件架构的信息，我建议使用静态分析来恢复类图，例如/可能检测正在使用的层模型（及其规则）。将它们中的两个结合起来可能是一种更具时间效率的解决方案。部署模型也不应该难以创建。