这篇文章的灵感来自Tudor Girba在2015年慕尼黑SAP内部跟踪会议上的一篇演讲"不读代码解决实际问题"。感谢所有社区成员的工作，特别感谢Damir Majer邀请Tudor Girba。

Jason Heeris的一幅著名漫画《为什么你不应该打断程序员》

在他同事的咖啡休息后，数据建模，开发人员的思维模式消失了。因此，我们可能会问："我们能将心智模型具体化吗？"。或者至少是其中的一个重要部分。所以灾难不会太大，所以有些东西可以帮助开发者重建他的心智模型。我经常这样做。但这很费时。过了一段时间，图纸变得不正确，必须改正。由于我在编码方面的工作，这增加了已经存在的认知压力。所以我有时这样做，但不经常。当我这样做的时候，我经常质疑这样做是否值得。

从plantUML学习之后，绘制UML图变得更容易了。plantUML中的图表是由文本组成的，这些文本更容易制作和更改。这节省了很多时间。但是当我处理实际代码时，我经常需要关于其他方法使用属性和方法的信息。这在UML类图中是不可能的。因此，我将方法映射到类，将类映射到包；这在某种程度上是可行的，理财返利，但不是很好。UML类图在较新的版本中工作得很好。但可能需要正确设置SAPGui。为此，存在将UML类图提取到PlantUML图的项目。雅克·诺姆西在这里做了很多工作。另请参阅帖子，了解从ABAP痕迹中提取序列图的技术。

2015年10月，我听了Tudor Girba的演讲，了解了驼鹿分析和FAMIX元模型。FAMIX比UML类图更细粒度，包含方法调用和属性访问。我编写了一个从SAP到Moose的提取器，能够在Moose中生成图表。例如，请参见力吸引图：元素可以拖动到一个被检查的对象。它不仅仅是一幅画。因此，在项目中使用这样的图表是可能的。松散耦合的应用程序之间的链接很容易看到。除了"孤岛"外，类似乎与其周围环境没有任何联系。

但是我在从系统中提取元模型的其他技术中遇到的主要问题仍然是：

模型可能非常大布局不可更改需要打印评论

所以我开发了第二个工具来解决这个问题。它是在Smalltalk中开发的，工作在Moose使用的可视化框架Roassal之上。它托管在Smalltalkhub上。请参见github项目页面的Moose图。smalltalkhub应用程序的链接包含在这里。

Alexandre Bergel帮助我制作了Smalltalk代码，这些代码制作了看起来有点像UML类图的Roassal图。但是红色框是方法，蓝色属性，灰色类和矩形包。提取器SAP2Moose以更一般的方式解释方法和属性

将逻辑映射到方法将数据映射到属性

这种解释在我看来是有优势的，但据我所知，啥是大数据，目前只有SAP2Moose extactor支持这种解释。

对于中型应用程序，这种方法制作了这样的图表（这里使用了一种对连接元素着色的逻辑来突出显示某些点）：

可以拖动和检查元素，但在这样一个大的模式，这是不容易的。这是一个较小的应用程序，其中元素按逻辑结构排序，一些包装盒被抑制：

这更容易处理。有些线条不好，有些方框重叠。但这不是什么大问题，因为这是一个在法罗的图表。所有元件都可以拖动和检查。因此，即使它看起来并不总是好的，它似乎不是一个问题。可以只显示元素的子集。为此，将标记某些元素并给出以下语句：抑制除我和我用于第n层或我正在用于第m层的元素以外的所有其他元素。通过对多个元素执行此操作，应用程序的子集将显示在我称之为"当前布局"的内容中。这似乎很实用。可以添加注释。这些位置和其他设置随后被存储到一个文件中。这给出了这样的图表：

这类似于开发人员在上述漫画中的一个心理模型，为什么你不应该打断程序员。至少对我来说是有效的。这个图表比较容易制作（通常2分钟）。大多数元素都显示在图表中，因为它们连接到指定的元素。如果更改了编码并且再次生成了图表，那么更改将自动显示在图表中。删除的元素消失，如果要按上述规则显示，则会出现新元素。只要没有重命名，注释就会保留。所以当我真正的心理模型崩溃时，这些图表仍然存在，帮助我重建真实的，往往更复杂的心理模式。有些元素没有提取，大数据传输，有时会有bug。它只是一个模型。

但它对我来说太好了，我每天都在工作中使用它。

记住我在哪里计划做什么/li>查看依赖项如果模型中缺少某些内容，我会添加一条注释请支持。尝试一下，在Github存储库中随意打开一个问题，即使问题看起来很小。文档很重要，物联网智能家居，abapGit的开发者Lars Hvam的第一个pull请求就是纠正自述文件中的拼写错误。abapGit有更好的文档。开发abapGit是必需的，而不是使用它。提取器只是一个简单的ABAP报告。如果您使用SAP，请转到SAP2Moose如果您使用其他语言，您仍然可以使用Moose的增强功能，请转到Moose Diagram enhancements for developers最后一个想法。我们需要UML依赖关系图的标准化吗？