Software Cinema

這篇 Short Paper [1] 以及所建立的 Tool ADORA, 包含重點大致可以歸納為兩點.

首先是使用 Fisheye View 的概念改進目前大部分 Tools 在協助使用者瀏覽整張 Software Design Diagram 時的問題. 既有的 Tool 在面對相當複雜且巨大的 Diagram 時大多無能為力, 往往需要使用者自行將 Design Diagram 從 Object Analysis ( 如果是在 OO Paradigm 中 ) 以後, 分為 Class Level 0, Class Level 1, ...... 等詳細程度不同的數張 Design Diagrams, 方便在不同的 Abstraction Level 間切換. 少部份 Tools 可以自動隱藏 Details, 但是當進行 Zoom In / Zoom Out 時卻是會對於整張圖作變化, 無法自由地只 Zoom In 想要進一步觀察的部份. Fisheye View 則讓此操作方式成為可能. ( 以下 ADORA 圖片皆取用自 [1] 並稍加編輯, 且無修改圖片本身內容 )


關於第一點在去年底我們實驗室有一位同仁在進行實驗室會議報告 Paper 時也有提到類似的概念, 當時他是用 StarCraft 當作例子, 在 StarCraft 中同時有主操作畫面 ( Local ), 以及左下方的微縮地圖全圖 ( Global ), 來說明如果 Design Tool 有類似的支援好像不錯. 當時大家討論都集中在使用方式上, 看了 [1] 的實做, 好像在 Layout 計算位置上也不是那麼容易實現, 畢竟要兼顧到整張圖的 Re-arrangement, 不能因為 Fisheye 使得整張圖亂掉. 我想這也是 [1] 裡面要強調可恢復性 (Stability) 的原因. ( 以下 StarCraft 插圖引用自 http://spyhunter007.com/game_over.htm )


第二是對於 Single Integrated Model 的理想. 在 Paper 尾段嘗試性的把不同時間點的一些 Diagrams 疊合在一起, 包含 User & Context, Use Case Diagram, 以及 Class Diagram. 可以想見的, 這樣一來就可以透過 ADORA, 在 Software Development Phases 之間快速自由的移動, 瀏覽相關的 Analysis Diagrams, Design Diagrams.


不過我認為 Single Integrated Model 的需求, 使用時機及模式, 以及呈現方式都還有很多探討的空間, 在本篇 Paper 中也沒有再著墨太多. 像是上圖左, Use Cases 跟 Classes / Components 混在一起的感覺就很奇怪, 也沒有因此曝露更多 Information. 如果改用 Use Case Map [2] 來作整理可能會好點. ( 話說 Use Case Map 是怎樣, 不紅到原本的介紹網頁都消失了, 現在只依附在 jUCMNav 底下了 XD )

或許之後在 Software Design Tools 中會出現更多這種 Visualization Information Mash-Up 的應用.


References

[1] T. Reinhard, S. Meier, R. Stoiber, C. Cramer, and M. Glinz, "Tool Support for the Navigation in Graphical Models," Proceedings of the International Conference on Software Engineering, pp.823-826, 2008
[2] R. J. A. Buhr and R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice-Hall, 1995

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 :)