上一篇咱们经过笼统模型整理了中心流程。

本篇是《怎么高效阅览源码》专题的第九篇，咱们来经过绘图加深中心流程的理解，一起将笼统模型和中心流程与概念模型进行整合，以得到一个更具象化的流程。

本篇首要内容：

• 为什么要绘图？

• 制作中心流程图

• 整合笼统模型和概念模型

为什么要绘图？

上一篇咱们经过笼统模型整理了中心流程。现在回想一下，你还能记住多少内容？！是不是只记住个大约？甚至一点都不记住了？！

咱们再往前推一点，在整理中心流程之前，咱们先依据中心类整理了一个笼统模型，现在回想一下，你还能记住这个笼统模型吗？是不是还能模糊记住有TestClass、FrameworkField、FrameworkMethod以及FrameworkMember？然后是否能回想起它们的结构？FrameworkField和FrameworkMethod是FrameworkMember的子类，TestClass构建了FrameworkField和FrameworkMethod。

依据美国哈佛商学院有关研究人员的剖析材料标明，人的大脑每天经过各个感官接受外部信息的份额差异很大：味觉最少只要1%，触觉次之1.5%，嗅觉第三为3.5%，听觉第四为11%，而视觉则高达83%。

所以，花点时刻画一些图辅佐回忆对错常有必要的。不但能够加深咱们的理解，也便于存档，方便今后需求时，能快速的唤起咱们的回忆。也便是说，即使你忘记了整理的内容，你也能经过制作的模型图和流程图回忆起流程，不然你需求花费更多的时刻来再看一遍文章。

制作中心流程图

在面向目标里，一般经过时序图来描绘目标之间的交互联系，但是时序图在这里相对太细化了，杂乱的时序图阅览起来也不方便，一起也不方便和前面的概念模型进行整合。所以咱们不使用时序图，而直接依据笼统模型来手动制作一个通讯图（非标准通讯图，首要是为了示意出流程）。

通讯图在UML中也称为协作图，展示了合作目标间怎么经过发送和接纳音讯进行动态的交互。
首要咱们删除笼统模型中的依赖联系，只留下接口和类。如下图所示：

接着，咱们参加前面整理出来的中心办法：

• TestClass中的结构办法，scanAnnotatedmembers办法、collectAnnotatedFieldValues办法和collectAnnotatedMethodValues办法

• FrameworkMember的handlePossibleBridgeMethod办法

• FrameworkField的get办法

• FrameworkMethod的invokeExplosively办法

最后，结合办法的履行流程，将各个类经过线条连接起来。

笼统模型和概念模型整合

注意上面的图，有没有发现少了点什么？从上图咱们能够明确TestClass是模型的入口，但是谁去实例化TestClass呢？现在还不知道，咱们先将此类称为Client，将其补充到图中。

这个Client并不属于笼统模型，所以咱们能够在这里画个边界，将Client和流程模型隔脱离。

现在咱们再来考虑一下，这个Client或许是什么呢？
咱们能够回过头来看概念模型，概念模型给出了一个完整的流程。

从这个流程里，咱们来看一看，哪里或许会调用TestClass呢？一个或许的当地便是TestRunners！即

• TestRunners经过各个Test的Class构建TestClass

• 然后调用TestClass里的collectAnnotatedMethodValues和collectAnnotatedFieldValues办法履行相关测验

• 再经过对收集到MemberValueConsumer里的结果的断定，得到Result

那么现在的概念模型或许就变成了下图这样：

这个流程正确吗？不一定，咱们后边需求经过阅览源码来验证它。

总结

本文解说了怎么经过中心流程制作出中心流程图，并将中心流程图与概念模型结合，得到一个愈加具象化的概念模型。
下文将经过对扩展模块的阅览，来进一步完善这个模型。