上一篇我們通過抽象模型梳理了核心流程。
本篇是《如何高效閱讀原始碼》專題的第九篇，我們來通過繪圖加深核心流程的理解，同時將抽象模型和核心流程與概念模型進行整合，以得到一個更具象化的流程。
本篇主要內容：
-
為什麼要繪圖？
-
繪製核心流程圖
-
整合抽象模型和概念模型
為什麼要繪圖？
上一篇我們通過抽象模型梳理了核心流程。現在回想一下，你還能記得多少內容？！是不是隻記得個大概？甚至一點都不記得了？！
我們再往前推一點，在梳理核心流程之前，我們先基於核心類梳理了一個抽象模型，現在回想一下，你還能記得這個抽象模型嗎？是不是還能隱約記得有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
那麼現在的概念模型可能就變成了下圖這樣：
這個流程正確嗎？不一定，我們後面需要通過閱讀原始碼來驗證它。
總結
本文講解了如何通過核心流程繪製出核心流程圖，並將核心流程圖與概念模型結合，得到一個更加具象化的概念模型。
下文將通過對擴充套件模組的閱讀，來進一步完善這個模型。