Software Cinema

這幾天同時在忙著跟不同的人合作不同的 project, 剛好都需要建立 design diagrams. 而由於許多前期分析的文件彼此都會修改, 因此早早就用 Subversion 管理這些文件. 而在建立 design diagrams, 忽然想到一個問題 : 怎樣對於 design diagrams 作 version control ?

當然很直覺的, 既然 design diagrams 通常也是一個一個的檔案, 就跟 source code file 一樣管理不就好了 ? 事情當然沒這個單純.

通常一張 design diagram 內包含許多 elements, 例如可能有 10 個以上的 classes, 以及各種 associations. 在 source code level 中, 這些 classes 的 code files 很可能是分開的, 因此不同的 developers 要同時修改不同的 classes 可以很容易的透過 version control 達成. 但是如果今天是在同一張 design diagram 中呢 ? version control 基於本身 data model 的限制, 大概就無法直接幫上忙.



更甚者, 許多 design tools 習慣把一個 project 內的所有 diagrams 包在同一個儲存檔案, 例如 ArgoUML 就用 .zargo 把相關 diagrams 都壓縮在一起. 對於 version control system 來說, 這就只會是一個要管理的檔案, 然而對於使用者 (developer) 來說, 所面對的卻是不同的 diagram 檔案. 在這兩者之間產生了落差.

解決的方法很容易地可以想到幾種, 大多會需要把一張 design diagram 拆開來管理, 例如利用 XMI 來撰寫 design diagram, 然後把 XML elements 拆開來作 version control. 或是在儲存到 version control system 內的時候, 把壓縮起來的檔案解開儲存. 或是乾脆在儲存一張 diagram 時, 就是分開成數個 diagram elements 儲存, 例如 classes 跟 associations.

不過找了找 free / open source design softwares, 好像沒有具備此種 features 的 tools, 是否大家都沒有此種需要呢 ? 但是在 Mandar Chitnis 等人的 UML Tools 文章 [1] 中, 有提到此項 feature, 引用部份內容 :

Version control: A very important feature that we want to have in the UML tool is either an integrated version control mechanism or connectivity to a standard version control system. Configuration management is an integral part in the building of software systems. Considering that the design of a system is a very important artefact of the software lifecycle, maintaining versions and baselines of the system design is a desirable feature to have in UML tools. In the absence of direct support for version control, it is the responsibility of the designer to maintain versions of the design.

又找了找學術界的部份, 發現有兩篇 papers 討論了這個問題. 第一篇是 H. Oliveira 等人的研究 [2] , 使用 XMI 為儲存基礎. 在 Client 端的 UML IDE tool 以 XMI 輸出 design diagram, 透過 Server 端提供的 web interface 對於 XMI 檔案作必要的處理, 再利用 version control system 儲存. Client 端理論上應該可以使用不同的 UML IDE tools, 但是現實是各家 tools 的 XMI 輸出還是存在 mismatch, 因此很可能還是必須使用同樣的 UML IDE tool.


第二篇是 Takafumi Oda 等人的研究 [3], 這篇採用的是不同的作法, 將 software engineer 的編輯動作分解成為單一動作 ( atomic change), 然後編輯時 real-time 記錄下來. 在 check-in 時是紀錄這些動作, 作為 model 改變的代表 ( differences ). 在最初使用時需要 import 一個最初版本的 design diagram ( design model ) 作為 baseline, 而後進行 check-out 時, 是依據這個 baseline 加上中間紀錄的動作, 得到最後的 latest diagram or model ( 或是得到特定版本的 ) . 這個作法的缺點之一是目前的 UML IDE tool 顯然需要作比較多的修改才能配合, 同時如果希望各家 IDE 可以共享 diagram 的話, 還需要制定一個標準給各家公司遵守.


References :

[1] Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy, "UML Tools," developer.com, URL : http://www.developer.com/design/article.php/1593811
[2] Hamilton Oliveira, Leonardo Murta, and Cláudia Werner, "Odyssey-VCS: A Alexible Version Control System for UML Model Elements," Proceedings of the 12th International Workshop on Software Configuration Management, pp.1-16, 2005, pdf download here or here (ACM)
[3] Takafumi Oda and Motoshi Saeki, "Meta-Modeling Based Version Control System for Software Diagrams," IEICE Transactions on Information and Systems, vol.4, pp.1390-1402, 2006, pdf download here

UMLSpeed 是一個 light weight 的 UML edition 以及 layout tool, 以 text-based 方式撰寫 UML-based design, 同時 UMLSpeed 則幫忙產生 SVG UML graphical layout, 以及支援轉換成 XMI 輸出, 或是其他 programming language 的 code generation.

UMLSpeed 作者之所以開發的理由包含 : (引用修改自 UMLSpeed 網頁)

1. Graphical UML tools in general suck - why should we, as programmers have to drag and drop stupid graphical things and use a mouse when we could express what we want 10 times faster with a text editor and a simple notation?
2. A declarative approach is closer to the mental model used by developers when designing systems.
3. Why should we layout diagram components when the computer could do it for us?
4. Graphical UML tools are bloated, huge, memory and disk-hogging monsters.
5. Graphical UML tools use either a binary data format or XML, which is not particularly friendly to source code control systems.
   

基本上我同意第 2, 3, 4 點, 但是對於 1, 5 則不完全同意.

以第 3 點來說, 雖然說 layout 不可能完全由 computer 取代, 身為吹毛求疵的 designer, 就算 tool 能夠自動幫我做 layout, 八成還是會對結果動手動腳的. 但是基本上 layout 結果的好壞是可以用一些 graph complexity metrics 去評量好壞的, 因此自動產生的結果是可以趨近 designer 會感到滿意的結果, 因而還是可以省下不少功夫, 更別說可以根據 designer 的喜好產生專用的 layout style. 第 4 點的問題應該常用許多 IDE 的 designer 都有相同的感覺吧, 有時候想要功能比較強, visualization 比較好看的 IDE, 卻會有需要大量 resource 的問題. 而 light weight 的 tool 往往功能上就比較被侷限住. 不過這基本上是個很難兩全其美的問題. 唯一的 solution 可能是能夠有一個 easy-customizable 的 IDE, 使得在不同的 environment 下可以很容易作 customization, 得到最需要的功能就好. (不過至今沒有這樣的 IDE 出現, 連 Eclipse 也還做不到)

同樣地對於第 1 點來說, grphical editor 在 visualization 上有他的優勢在, 我相信 graphical software design 只是還沒有突破性的發展, 但是 visualization 在 software design 上至少可以同時結合 design layout 與 design document (design code) 之間的 traceability, 但是像 UMLSpeed 這樣的 tool 就沒有支援這樣的 traceability, 只是因為 UMLSpeed 功能不強大, 所以這樣的缺點也就沒有被放大. 第 5 點也是見仁見智的問題, 採用 XML-based solution 是為了標準化以及延伸性考量, 如果不考慮此點當然可以批評採用 XML 的做法. 但是相對來說, 採用自家標準的 tools 往往容易被淘汰, 至少我就不太會想用, 因為 data 無法被不同的 tools 共用, 換句話說無法被長久保存, 這是很困擾的事情. 要是 UMLSpeed 沒有支援 SVG 或是 XMI 輸出, 我大概也不會想用了.

UMLSpeed 的使用是以 C-style 的 text-based code "programming" 展開, 看圖就很清楚了, (下圖取用自 UMLSpeed 網站 )


而輸出是以 SVG 格式的檔案輸出, 另外支援 XMI UML 文件輸出. 另外從網站上看來, UMLSpeed 目前支援 use case diagram, class diagram, sequential diagram, 以及 deployment diagram.

基於 UMLSpeed 的特性, 我認為有幾個不錯的額外用途 :

1. Software project 階段性的 design review, code review : 在 software project 進行過程中, 偶爾會需要進行 design review 或是 code review. 這通常是由於 design 或是 source code 已經有點混亂, 因此該部分的 leader 會召開會議, 把所有負責各部分的 designer / programmer 集合起來, 針對整個 design / source code 作 review, 確認每個部分的用途, 以及解決方法是否足夠好. 由於會議人數眾多, 同時進行會議中可無法容忍慢吞吞的大型 IDE, 或是時不時出現的 IDE 怪問題. 因此像是 UMLSpeed 這樣能夠快速進行 pure text-based modification 以及自動 layout 的 tool 應該適合使用. 但是要達成此點, UMLSpeed 跟其他 project 會用到的主流 IDE 之間的 data consistency 問題可能需要被解決.


2. Design on mobile devices : 可能會想要這樣功能的人很少, 但是我就是其中之一 :p . 在 mobile devices 上, 或是如最近的 ASUS EeePC 上要跑平常的 IDE 幾乎是不可能的(很辛苦), 但是畢竟我想要的只是在等人或是喝個咖啡時, 可以思索一下最近手上計畫的 software architecture 的一小部分 design 而已, 一個 light weight, 可以馬上產生圖的 tool 就足夠使用了. 這些需求 UMLSpeed 看起來通通符合 :)


3. UML programming on Wiki, Blog System : 我們實驗室使用的是 MoinMoin Wiki System, 偶爾會想在 Wiki 上畫個 UML 圖形來說明. 在 MoinMoin 上已經有類似的 plug-ins, 使用上跟 UMLSpeed 有點像, 只需要撰寫特定格式的 UML code, 就可以在頁面上被轉換成為 UML graph. UMLSpeed 應該可以提供在 Wiki 或是 Blog System 上的類似支援

另外 UMLSpeed 支援 SVG 輸出這點也使得他可以跟一些支援 SVG 的繪圖軟體合作使用. 例如我依賴的 Inkscape, 這樣要修改 UMLSpeed 的輸出結果, 用在準備 slides 或是 reports 也很容易. 小 tool 果然是 flexibility 高許多 :)

雖然我是個平常用不到 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 可以在他的網站找到.

TagSEA [2] 是好一陣子前看 ICSE paper [1] 時發現的 tool, 當時就覺得蠻有趣的, 不過好像中文網站還沒有太多的介紹. 作者群在 ICSE 的那篇 paper 是 tool demonstration short paper, 應該蠻容易看懂的. TagSEA 網站上也可以直接看的到.

如其名, TagSEA 的主要功能在於能夠讓你隨意在程式碼上加上各種 tags. 有些是 TagSEA 已經訂好的 common tags, 例如 TODO tag, 而你也可以自定習慣的 tags. Tag 的位置可以在程式碼上, 註解上, 或是空白的部分. 加上 tag 的方式可以採用手動以 Java comment 語法加上 @tag 標籤, 或是直接在要註解的地方按 mouse 右鍵, 從選單中加入 waypoint (TagSEA 稱呼在 source code 中被標上 tag 的 location 為 waypoint). 在 waypoint dialog 中可以再指定要創造新的 tag 或是採用既有的 tags. 更詳細的說明在 TagSEA 網站上有很多易懂的 examples. 值得注意的是用 @tag 標籤加上的稱為 parsed waypoint, 而利用選單加上的稱為 resource waypoint. 這在後面製作 presentation tour 時會有差別.


TagSEA 對於 waypoints 提供了 hierarchical tree view (上圖左下方), 以及有趣的 cloudsee view.

CloudSee view 雖然好像有些趕流行, 但是對於想一眼看出不同 tags 數量關係還蠻有用的, 況且 programming environment 內實在需要出現一些有趣點的東西, 可以紓解 debug 壓力 :p


不過在右方的 tag message list 有點小 bug, 當新增 tag 時, tag message list 不會馬上更新, 需要等到再加一個新 tag, 或是 mouse 右鍵 tags -> show waypoints 才會更新.

TagSEA 內的 waypoint 應該是沿用自 GPS 系統的稱呼 [3], 可以想見 TagSEA 其實定位自己是 Eclipse 上的 GPS navigator 系統. 因此同樣地, 數個 waypoints 以特定順序串在一起就形成 route (同樣來自於 GPS 系統) [1], 而一長串的 route 其實就是一個 navigation tour.

TagSEA 也提供 Tour 的幫手功能 (但是需要 Eclipse 3.3 以上), 藉由 Tour 功能, 你可以快速地利用已經標好的 tags, 在 Eclipse 上建立一個簡單的 presentation (進行的步驟在 TagSEA 網站上寫的很清楚了). 只要執行編輯好的 Tour, 然後利用播放鍵就可以很順利地依照你的 plan 進行 presentation, 再也不用擔心 present 到一半卻忘了要開哪個檔案, 或是找不到要講的那段 code, 或是忘了本來要開的 view 是哪一個 -- 是的, Eclipse 上的 view 也可以作為建立 presentation tour 時的一的造訪點 (其他可以加的東西都在右側的 Tour Palette 上). 但是這裡要注意的是, 如果你要 Tour 自動根據 tag 換到該位置, 必須要是 resource waypoint 的 tag 才可以, 如果只是 parsed waypoint, 似乎 Tour 不會有反應.

執行後的 Tour 會在上方出現播放控制盤, 可以看到目前的位置, 也可以前後播放, 不過還沒有辦法直接跳躍到某個步驟.

可以看到當執行第一個步驟時, 畫面就自動切換到第一個 resource waypoint 所 tagging 的地點了.


另外除了 Tour Palette 上可以加的東西, 以及 resource waypoint 之外, PowerPoint 之類的也可以加到 Tour 裡面, 我嘗試了 OpenOffice.org 系列, odt 檔案可以, 但是 odp 就會出現一些顯示的問題, 不過這些問題應該跟 TagSEA 無關, 是 Eclipse 本身的問題 (OpenOffice.org 會直接以 OLE 物件的方式開啟在 Eclipse 視窗內, 而 PowerPoint 會獨立開啟), 我也嘗試了 PDF, 但是會出錯, 根據錯誤訊息應該是我 local 端的設定問題. 換句話說只要你 local 端有相對支援開啟的 software, 應該都可以順利在 presentation 過程中開啟. 下面是開啟 odt 檔案的樣子.


從 tool 的角度來看, TagSEA 算是蠻小巧好用的 tool, 而我喜歡他的另外一點是, 從 research 的眼光來看, 這個小 tool 有相當大的潛力. 現在 TagSEA 只能在 code 上加 tag, 而別忘了 Eclipse platform 上的 plug-ins 幾乎快涵蓋了整個 model-driven software development, 雖然有些 plug-ins 還不算太成熟, 但是當 TagSEA 可以更順利地支援直接在 use case, object model, analysis model, architecture design, detail design 上加註 tag 時, 想想他將會有的 power, 給 software developer 提供的 traceability service 以及 consistency checking service, 還有很多可能的應用, 都可以建立在這一個看起來很簡單的 tool 身上去實現.

我想這是包含我在內的許多台灣研究學生, 經常忽略的一點, 在我們手上的許多小想法因為他們簡單, 所以擁有更大的發展空間, 老想著重新作出全新的東西, 會讓我們的研究工作前進的十分緩慢. 好好地利用已經有的東西, 往上堆積新的價值, 才是一直以來研究該有的方式.


References

[1] L. Cheng, M. Desmond, and M.-A. Storey, "Presentations by Programmers for Programmers," In Proceedings of the 29th international Conference on Software Engineering, pp.788-792, 2007
[2] TagSEA, URL : http://tagsea.sourceforge.net/
[3] waypoint @ Webster's dictionary, URL : http://www.websters-online-dictionary.org/definition/waypoint

今天才看到 OxygenOffice Professional 這套 OpenOffice.org 的加強版軟體, 真是後知後覺. 雖然中文網頁有討論的不多, 但是好像早在去年 10 月左右, OpenOffice 補給站就有人發出訊息討論過了.

OxygenOffice Professional 說穿了是加強 OpenOffice.org 在編輯上的便利性, 嘗試藉由更容易管理與引用圖片等資源, 加入類 VBA 的 support, 以及提供更多分類後的 templates 來達成 (好像還有額外的 Fonts ?).

在 SourceForge.net 上的 statistics (~2007/10) 倒是有點奇怪, 雖然在 2007-04 後大幅增加了網頁流量, 但是 downloads 數次卻逐漸低迷, 顯示並未造成使用的大流行, 只有一開始固定的用戶有持續更新, 新用戶可能極少. 或許跟宣傳有關 ? (以下圖片擷取自 SourceForge.net )


我也抓下來試用了一下. 可以看到在編輯 odt 文件時, 能夠把圖片引用選擇開啟在工具列, 然後直接用拖曳的方式拉進去. 不過我覺得圖片選擇工具組能夠開在左右比較好, 因為現在有寬螢幕 LCD 卻沒有長螢幕 LCD (除非把寬螢幕旋轉過來, 但是並非每台 LCD 都可以), 放在左右比較不佔文件編輯空間.


另外開啟檔案時有許多種類的 templates 可以選.


隨便選了一個 maintenance report 相關的 template.

試用歸試用, 我真正覺得有趣的地方在於 OxygenOffice Professional 是否能夠成功, 以及他的成功帶來的意涵.

長久以來 Windows 的使用者習慣於 Microsoft Office 類型的編輯軟體, 即便是後來在 Linux 上的 AbiWord, KOffice, StarOffice 等等其實都是一樣, 此類編輯軟體的 power 掌握在開發團隊手上, 即便有些採用較為開放的 license, 但是缺乏良好的 design 以及 interface, 有心者一樣很難加入開發.

而隨著時間推進, OpenOffice.org 出現了, 仍舊, 跟過去一樣, 是 power 掌握在開發團隊手上的編輯軟體. 但這次有點不同. 不同之處在於同時期出現了一個極為成功 (可能是有史最成功的) 的開發軟體 : Eclipse.

熟悉 Eclipse, 而且使用過如早期 Visual Studio, IBM Builder 系列等等有的沒的 IDEs 的使用者, 應該都能一下子指出 Eclipse 跟這些 IDEs 的最大不同處. 這樣的不同處建立在良好規劃的 software architecture, interface, 以及 open source community 的逐漸壯大上 (當然, 還有 Java 的熱潮).

OxygenOffice Professional 給我的感覺就像在 OpenOffice.org 上加了許多 plug-ins, 看那引用圖片管理的工具組, 不覺得跟許多 Eclipse plug-ins 的出現方式很像嗎 ?

或許 OpenOffice.org 想持續壯大, 搶奪 Microsoft Office 的市佔率, 應該考慮以 Eclipse 為學習對象, 變成一個文書編輯軟體的 framework/platform. OOo 本身有絕佳的條件變成文書編輯領域的 Eclipse, 唯一的問題在於目前的 architecture 以及 interface 是否設計的夠好, 如果需要修正, 要花多少 efforts ?

我期望著有一天我會像在 Eclipse 上嘗試各種 plug-ins 的 combination 以提升我的 development performance 般, 在 OpenOffice.org 上嘗試數不完的 plug-ins :)

當初看上 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 也負有一些責任呢 ?

PyDev 是一個可以用來做 Python 以及 Jython programming 的 Eclipse-based Plugin. 之前有試用過(還不到 1.0 版的時候), 當時還很陽春, 但已經算是好用了. 昨天猛然發現已經到 1.2.9 版了, 而且在 1.2.8 版就加入了 code-completion, auto-edit, 以及 refactoring 的功能. 對於我來說這三個都還蠻重要的, 可以很有效地加速開發. 不過我很好奇他的 code-completion 是怎做到的, 畢竟 Python 不同於 Java, 要在 programming 時很快地推論出 type 似乎不是很容易的事情. 可能是在做 programming 時, PyDev 在背後不斷地進行 interpretation, 保留 code information 吧, 之前稍微嘗試寫過 Eclipse Plugin, 大概知道怎樣做到.

試了一下, build-in string 的 code-completion :

撰寫新的 class 時也會自動補上 self argument :

自己撰寫的 class 也馬上就會在 code-completion 的支援裡了 :

上面是我稍微試了的結果, 其它更多能力可以參考 PyDev 的 ScreenShot, 以及 Release Log