Software Cinema

山不轉路轉, 嘿.

今天花了許多時間在挖某個 Jave-based Tool 的使用方式. 就不說是哪個 Tool 了, 也不打緊.

該 Tool 雖然有把 Source 公開 ( in Limited, Private License ), 但是幾乎沒有註解, 也沒有使用方式. 雖然包成了 Jar, 裡面也有 Applet GUI, 但是並沒有讓你直接使用的意思. Manifest.mf 裡面甚麼有意義的東西也沒寫, 也沒有內嵌 Applet 的 .html 檔案在. 換句話說, 該 Tool 作者使用包 Library 的方式在包一個事實上是 HTML Applet 的工具.

更麻煩的是, 某個必要的 Configuration File 並沒有附在裡面. 沒有該 File, 就算摸清程式運作邏輯, 也不可能讓工具動起來.

但是由於該工具可用的話將省下我一個禮拜以上的時間, 加上該工具的程式碼實在寫的太好了, 不使用跟探討看看可能是我的損失. 必須得想辦法回復此 Configuration File. ( 寫信跟作者要? 拜託... 這哪是可能的選項... 這樣不就讓作者得逞了嗎... )

在仔細去看 Loading Configuration 部分的程式碼之後, 發現了令人高興的事情: 該 Configuration File 的結構看起來十分簡單. 先看看他的 Config Loading 設計大概是這樣表示.


然後呢, 細節看看讀取跟處理的程式碼, 首先是如何取得單一設定值的要求.

<br />snippet_dir = new File(raykernel.config.Config.get("snippet_dir"));<br />scoreFile = new File(raykernel.config.Config.get("score_file"));<br />
接著看該工具怎樣處理 Configuration File 的 Parsing. ( 另外這裡只用 One-Pass 的方法, 讓程式更容易寫也值得筆記, 有時候不是非得要求 Two-Pass 來滿足任性的使用者 )

<br />private void process(String line)<br /> {<br /> line = remComments(line);<br /><br /> for (String tag : tagMap.keySet())<br /> {<br /> line = line.replace("$" + tag, getValue(tag));<br /> }<br /><br /> String[] values;<br /><br /> if (line.contains(":"))<br /> {<br /> String before = line.substring(0, line.indexOf(':')).trim();<br /> String after = line.substring(line.indexOf(':') + 1).trim();<br /><br /> currentTag = before;<br /> values = after.split(",");<br /> }<br /> else<br /> {<br /> values = line.split(",");<br /> }<br /><br /> if (currentTag != null)<br /> {<br /> addValues(currentTag, values);<br /> }<br /><br /> }<br />
如此一來就可以得到結論, 該工具的 Configuration File 大概是長這樣.

attr1:value1
attr2:value2,value3,value4
attr3:value5, value6

問題是, 該填寫哪些 Attributes 呢 ?

這時候注意到取得單一設定值的要求都是透過同一個 Method Call Interface 處理的.

Config.get("snippet_dir")
Config.get("score_dir")
Config.get("benchmarkdir")
Config.get("classifier")

因此只要寫個簡單的 Python Script 去掃所有的程式碼, 看看出現同樣 String Pattern "Config.get" 的是哪些部分, 然後把所有的 Attributes 值重建就好了.

當然, 這流程只對結構簡單的設定檔案會有用, 略為複雜的就不太可能成功, 或是需要更複雜的演算法幫助, 例如 Apache httpd.conf 那種 = =

不過這個經驗倒是讓我想到一個問題. 假使不考慮這件事情的複雜度跟需要花費的時間, 是否只要有 Program Logic (Source Code), 就一定可以反推出任何該 Program Logic 所會取用的 External File / Data Source 的最基本 Structure ? ( 最基本 = 使該 Program Logic 可以運作 )

這問題是否等同於, 只要我們確定兩個 Components 之間能夠進行溝通, 且必會進行持續溝通, 我們就一定能夠破解溝通的內容 ?

雖然我是個平常用不到 bytecode inspection tool 的人, 不過今天因緣際會看到 reJ 這個 tool, 起了一點想法.

我們對於什麼東西都可以用 5W1H, who, when, why, what, where, how 來嘗試弄清該東西的本質, 而我就想問了, what kind of bytecode inspection tool do you actually need ? 以及 who else also need this tool ?

reJ 這樣說了,

There are various robust libraries/APIs available for bytecode manipulation, such as:

• BCEL - http://jakarta.apache.org/bcel/
• ASM - http://asm.objectweb.org/
• Serp - http://serp.sourceforge.net/
  

Each library has a slightly different focus. reJ uses it's own API which is focused to serve the needs of the user interface. The user interface with syntax coloring, search, compare and editing capabilities is something that is less readily available elsewhere.

關鍵句子出現了, "serve the needs of the user interface".

現在已經有很多強大的 bytecode manipulation library 出現, 尤其是 BCEL 跟 ASM, 基本上最近幾年在比較好的 software engineering conference / journal 上看到關於需要處理 bytecode 的 paper 都脫不了使用這兩個 tools. 在品質上顯然是受到信賴的.

然而 bytecode manipulation 終究只是技術的問題. 怎樣從 bytecode data 中挖出 information 並不該是身為 programmer 的我們需要花費最多關注的問題, 畢竟這是個一定可以被解決的問題. 我們更應該關注的是怎樣更有效率地挖出有意義的 information, 或者換句話說, bytecode inspection tool 要該要呈現什麼樣的 user interface 給 programmer, 才能夠讓 bytecode inspection 的動作有意義且有效率. 我相信 reJ 的那段話就是在嘗試說明此點.

User interface 在這裡並不單純指 software GUI 而已, 而是包含了 programmer 跟 bytecode inspection tool 之間的各種 operating languages. 透過 user interface 的設計, bytecode inspection tool 可以知道 programmer 真正想要的 information, 並且將之呈現給 programmer.

從 reJ 的 screeshots 可以看到這種努力, 雖然目前支援的 views 還很少, 但是這是以 service 的觀點來製作 bytecode inspection tool, 嘗試把 programmer 真正想要用的 views 帶進 software. (這不就是 service-oriented computing ?) 底下 screeshots 取自 reJ @ SourceForge.net.


也有其他的 tool 有類似的想法, 例如 jclasslib, 可以看到的 information 更多, 但是過多的 information 卻沒有整理成適當的 views, 一樣對於 programmer 來說是種困擾. 底下是 jclasslib 的一張 screeshot, 其他的 screeshots 可以在他的網站找到.

WebST 是一個會根據你給定的 webpage 自動進行連結頁面 retrieval, 建立 star structure visualization 的 Java-based tool, 但很可惜地在 1.0 出現之後就沒有繼續發展了. 前一陣子有在 SourceForge.net 上作過 survey, 好像這類的 open source tools 並不多, 或是可能因為我不知道該用什麼關鍵字去找的關係 ?

WebST 執行的方式很簡單, 就是一般的 .jar 執行方式. 首先會出現輸入目標網頁的對話視窗, 但是這裡要注意前面不用加 http:// , 另外結尾要指定特定的網頁, 例如 index.htm , 而不能夠只有網域名稱. 舉例來說要看成大電機中文網站的結構, 要輸入 www.ee.ncku.edu.tw/chinese/index.htm , 而不能夠只輸入 www.ee.ncku.edu.tw/

輸入後就會進入主視窗. WebST 的 retrieval 動作還蠻快的, 這可能跟他不是一次抓完整個網站有關. 主視窗左邊是網頁預覽, 右邊是 star structure visualization. 上方有幾個不同的選項可以調整. 底下說明的 nodes, edges, radius 都是 Graph Theory 內的東西, 當然 Google 上很容易找到 definition.

• Show E# : 除了目前所選擇為 focus 的網頁 node 之外, 其他具有大於 E# 個 edges 的 nodes 不會呈現出來
  
• Expand E# : 除了目前所選擇為 focus 的網頁 node 之外, 其他具有大於 E# 個 edges 的 nodes 不會被展開
  
• Radius : 目前所選擇為 focus 的網頁在 radius 個 edges 內, 所以可連結到的所有頁面 nodes 都會被呈現出來. 簡單地說, 從目前 focus 的網頁出發, 經過 radius 次的網頁超連結切換, 所可以到達的網頁都會被列出來到 star structure visualization 中.
  
• Show BlackLinks : 把與目前選擇為 focus 的網頁之間有 backlink 關係 (其他網頁連結回目前的選擇網頁) 的網頁列出, 但是我有點懷疑這個功能有點小 bug.
  
• Zoom : 調整視野大小, 達到放大縮小的功能
  

可以看到上面的圖雖然跑出來了, 但是似乎不太正確, 成大電機系網站不會只有這兩個頁面吧, 就算再調其他參數也是一樣的結果.

這是因為 WebST 的 MyParserCallback class 只有對 Frame Tag 作處理, 而電機系網頁用了 Map Tag 而非 Frame Tag 去連結其他頁面, 因此 WebST 就無法解讀相關的 links. 同時對於 links 的路徑判斷很單純, 沒有考慮原始網頁開發人員將絕對及相對路徑混用的情況.

剛好 WebST 有把 source 提供, 因此我就去作了一點 hacking, 讓 WebST 可以處理 Map Tag, 同時可以在一開始指定要 retrieval 的 level 深度. 我改過的 WebST 可以在這裡下載 (要處理 Map Tag 才需要, 正常的網站應該是可以用原版的就好). 除了 MyParserCallback class 之外其實還要改其他地方, 有興趣的人就自己利用 decompiler 比較差異摟.

執行的方式相同, 只是一開始輸入的除了網頁 URL 之外, 還多了 level 的指定. 同時就這樣就可以正常地看到成大電機系中文網頁的星狀結構了.

雖然說 WebST 的介面設計實在有點陽春, 同時功能也只有 visualization, 不過因為我還蠻喜歡串聯小 tool 使用的, 同時 free software 中也找不到相似的 tools 了 (另外一個類似的 WebLoupe 對於過大網站的 visualization 會有問題), 所以基本上 WebST 還是算堪用. 再不然就需要自己 parse 再接 graph library 了, 這樣可用的 library 倒是很多.

不負責任的推測, WebST 應該是大學生的修課作業之類的. 因為在 WebST 網站上有一個 Business Plan 的 pdf 檔案, 雖然內容看不懂, 但是有點像是大學部或研究所的 project document, 加上 WebST 本身也像是一個 project 作業, 然後完成後就沒有繼續 maintain 了, 一整個很像是課程 final project ^^b

當初看上 Jupe 是因為他的 reverse engineering 支援, 看起來似乎頗有希望. 在 forward engineering 部分的 UML tools 已經夠多了, 而且甚至有點雜. 除了對於 XMI 支援以及呈現的問題, 不同的操作 style 也造成這些 forward engineering tools 合用互補的不易. 然而在 reverse engineering 的部分, 則是連這樣的缺點都還沒辦法有 ^^b , 因為好用的 reverse engineering tools 實在太少了, 有些可能要在 commercial 才看的到.

Jupe 相依於 Eclipse GEF, Eclipse UML2 frameworks, 同時嘗試支援 forward and reverse engineering. 在今年 (2007) 三月左右停止繼續維護與開發, 原因不明.

在使用上, Jupe perspective 右手邊是 forward engineering 用的 UML 元件選單, 這跟大多數的 tools 一樣, 就沒什麼好說的. 而在 reverse engineering 部分則是可以從 package 或是 class 直接增加到 class diagram 內, 操作上是還算直覺.


但是在呈現上的結果到是有很大的問題. 僅以加入一個 class 來說, 圖上會連同外面的 package 一起出現, 但是圖形卻不會自動調整大小, 整個就擠在一起.


需要手動分開才能看一點.




而且對於 graph boundary 沒有作 checking, 所以可以隨便移動, 離開原本的 package 也是可以.


綜合以上總總, 實在不能算是派的上用場的 tool, 而只是 yet another failed Eclipse plug-in. 有空真該來統計一下 fail / success 的 Eclipse plug-ins 比例. Eclipse platform 身為一個響譽軟體開發社群的 IDE, 是否對於如此多的 fail plug-ins 也負有一些責任呢 ?

Jdec 就如其名是一個 Java Decompiler, 目前主要支援的 features 包含 :

1. Decompiling a Java class
2. Decompiling a jar file : 我喜歡直接支援 jar file 的 decompiler, 而不是需要使用者自己利用各種技巧來作到
   
3. Selective Decompilation of a class file : 這個功能是不錯, 但是需要知道該 class 的 specific name, 如果可以作到將 jar file 當作 code repository, 而可以利用 keyword 去作 mapping 就更好了. 而且 Jdec 也不能自動將相關的 classes 都作 decompiling. 事實上我們作 decompiling 就是想看 code, 因此如果能自動找出直接相關 (high-coupling) 的, 形成一個 concern, 或許會更為有用.
   
4. Decompiling 2 Versions : 感覺不太有用, 只是方便想比較的人, 但是我直接利用 decompiling a Java class 找出兩個版本, 再用其他更 powerful 的 tool 去比較版本不是更好 ?
   
5. Disassembling a Java class : 這個能力不錯, 雖然我用不太到. 其他的 Java decompilers好像也沒有看過這能力. 但是這功能跟 decompiler 關係有很大嗎 :p
   
6. Local variable information : 只對原本的 developer 較有用而已, 或是想認真 trace code 的人
   
7. Exception Table Information : 這個對於 code tracing 也很有用, 或是 component reuse 時, 可以用這功能加以擴充, 作 contract checking. 不過他還作的不夠好就是了. 既然又作這個, 其實可以在 Decompiling a jar file 功能上搭配這個, 幫忙分析 code 中的 exception handling coverage 情形, 可以用樹狀圖之類的表示. 不過這同樣超越一般 code decompiler 的能力了.
   
8. Constant Pool Details : 一樣, 對於作底層的人, 或是 performance 比較可能比較有用, 一般人大概沒什麼用
   
9. Skeleton Display of Class File : 實用的功能
   

不過我覺得他的操作流程設計不是很好, 新建 decompiling project 時的選擇方式非常 engineer-thinking, 這樣限制使用者的 view 會讓人感覺很不舒服. 同時 configuration 必需所有的欄位都填完才能 decompile 一個 .jar file, 還我一開始試了好幾次, 難道不能有預設值嗎 ?

他的 UI 設計應該是是有受到 Eclipse 使用 JFace 的影響, 不過還差遠了 XD

整體來說是作為一個一般 Jave decompiler 該有的功能都有了, 但是這個時代這樣已經不夠了, 或許 decompiler 所定義的能力範圍就是那樣, 但是我們總是希望更好, 總是希望一個 tool 不只是完成整個 scenario 內的一個 role, 而是能幫我演出整個 scenario, 或是只少把他跟其他 role 的關係交代清楚, 而不是我要自己去指導它們怎麼演戲, 不是嗎 ?

Bunch Tool [1] 是由 Software Engineering Research Group (SERG) 所建立的 reverse engineering tool, 可在此下載. 基本的原理是利用 graph-based source transformation, 以 module dependency graph (MDG) 為基礎, 以特定的 clustering algorithm 作不同 level 的 graph clustering. 並且基於 coupling / cohesion 計算各個 cluster 的 MQ value, 從中選出最佳的 clustering 結果作為對於 software architecture 的 best guess. 以下圖來說明的話, 左側的 MDG graph 有 4 個 nodes C1, C2, C3, 以及 C4. 其之間的 dependency 如圖所示, 同時 depedency 上有加註 weight, 經過計算可以得到各種組合的 MQ 值, 選出 MQ 值最高的. 詳細原理可以參考 [1]. 需注意其得到的結果為 partial view, 而非 complete view on architecture.


在使用上, Bunch Tool 提供 Swing-based GUI 介面, 還算容易使用, 但是對於原理或是 algorithm 不了解可能部太知道怎樣去對結果作 tuning, 但基本上不影響使用. 缺點是沒有 (或許是因為不能) 整合前端的 source code analysis components, 所以必須要自己找來用. SERG 另外有一個基於 Bunch Tool 提供 reverse engineering service 的 web-based tool, 叫做 REportal [2], 據網頁上所說, 目前僅支援 Java-based source code analysis, 但是我偷偷試過其實 C++ 也是可以. REportal 上就內建有 decompiler, code analyzer, bunch tool, graphiz dot viewer 等等, 話句話說它是一個完整的 Bunch Tool 使用環境, 如果懶得自己找相關 tools, 直接利用 Reportal 也是可以, 而且分析解果也可以打包下載.

Bunch Tool 相關的前端 code analysis 以及 module dependency graph generation 工具, 目前我試用過的有以下兩個

1. depgraph : 給 python 用的
2. cinclude2dot : 給 C / C++ 用的, 這個很容易操作, 可以產出 .dot 檔案. 因為產出的 .dot 檔案格式很接近 .mdg 格式, 因此寫小程式轉換也好, 手動轉換也好 (我是直接手動簡單的 editing / replace 就處理了), 很容易轉成 mdg 檔, 再用抓下來的 Bunch Tool 分析就 ok. 我用這個加上 Bunch Tool 成功地對 FileZilla 作了分析.
   

Java 的部份我就直接用 REportal 處理了. 其實 MDG 格式相當簡單, 如果有其他的格式, 只要能夠轉成 graph, 自己動手寫個小程式其實也不難, 因此其實很多 code analysis tool 都可以接到 Bunch Tool 使用, 重點在於使用 Bunch Tool 分析是否有意義.

後端的 visualization 由於是 dot 格式的 partitioned MDG graph, 因此只要能夠讀 dot 格式的 viewer 應該都 ok, 像是 Graphiz 內建的 dotviewer 就能用了. 但是觀看大型程式時的效果並不是很好. 不過我也找不到其他好用的 dot visualization tools, 真是有點奇怪. 下面是對於 jChecs 的分析結果之部分, 原始圖太大了, software 真的是很複雜的東西.


Bunch Tool 的另外一個缺點是, 沒有提供 source, 所以雖然理論上可以很容易地擴充其 clustering algorithm, 但是必須要 decompile 其 bytecode 才行, 同時又有 license 的考量, 所以想拿來自行修改並不是很容易的事情. 前不久因為出於 research 上的需求, 我偷偷做了一點 hacking, 也發現 Bunch Tool 內的 algorithm strategy architecture design 有點亂, 對照他們之前的 conference paper 到 journal paper 的內容, 應該是中間經過不同 maintainers 修改的緣故, 總之不是很容易 trace 就是了.

Bunch Tool 同時可以讓你自行指定那些 nodes 必定要在同一個 cluster 內, 這在他的 document 內有說, 但是他沒說該 configuration file 的 format 該是如何, 我從 source code 反向去推, 試出了一種寫法, 不過不確定是不是唯一寫法, 反正可以 work 就是了 :p , 寫法如下 :

1.(Cluster1)=C1,C4
2.(Cluster2)=C2,C3

前面的 1. 2. 是必須的, 表示是兩個分開的 equation indications. C1, C2, C3, 以及 C4 都是 node id.

目前對此 tool 的瞭解大概是這樣, 因為有個題目會利用此 tool, 估計會繼續深入研究, 甚至重新實做一個.


References

1. B. S. Mitchell and S. Mancoridis,"On The Automatic Modularization of Software Systems Using The Bunch Tool", IEEE Transactions on Software Engineering, Vol. 32, No. 3, March 2005


2. S. Mancoridis, T. S. Souder, Y-F. Chen, E. R. Gansner, J. L. Korn, "REportal: A Web-based Portal Site for Reverse Engineering," IEEE Proceedings of the 2001 Working Conference in Reverse Engineering (WCRE'01), pp. 221-230, October, 2001