U23 將程式碼視為Model，產出文件視為View

“這個功能的流程大概是什麼樣子？”“功能實作時呼叫了哪些元件的方法？”……，之前詢問快速完成功能的同事時，都會得到很經典的一句：“你要的東西全部都在程式碼裡，100%正確而且100%可以正常執行！”。所有人都同意東西全在程式碼裡，但是其他人要花多少時間才能取得自己想要的資訊？

一個功能使用UML來描述時至少需要四張圖（Use Case、Activity、Class、Sequence），畫這些圖的時間遠大於程式寫作的時間，更何況未來還需要另外製作各種使用的水平與垂直追溯表！額外花費心力完成一堆文件後，日後遇到程式碼的修改還得同時修改一大堆文件，這樣的工作內容有誰可以接受？要我也不想這麼做。

既然程式碼裡有完整且正確的所有資訊，又同時需要數份描述那些資訊的文件產出，那麼應用MVC Design Pattern設計一個轉換工具（Controller）把程式碼的內容（Model）轉出為各式各樣的對應文件（View）不是很理想嗎？文件可以制訂出固定不變的格式，規定程式碼的寫作格式有助於固定住轉換來源，兩者是達成功能的必要條件。

即使固定了設計的結構，但是不同程式語言的解析方法不一樣，每一個人對於同一種語言的寫作方式也不同，要寫出包含各種不同寫法的轉換工具近乎於不可能；我所能想到的就是在依設計準則安排Class與Method的佈置，同時再定義出固定不變的註解格式來提供轉換工具讀取（讓人快速看懂也是目的）。

Class與Method的佈置提供的是轉換工具處理的流程，註解內容則是轉換工具處理的動作，這兩類規格的定義讓程式碼與文件得以作有關聯的轉換（甚至可以做到註解的雙向轉換）。實作的重點在於註解Data Model的統一定義，這正是接下來要進行的主題。