Software Cinema

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 高許多 :)

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

前一陣子有需要利用 Parser Generator 產生 Python-based Parser,
用來 parsing Java source, 因此就做了一點 survey.

不過出乎意料的, 找不到幾個好用的工具, 大致上 Python Parser SIG [1]
裡列出的都嘗試過了, 有些雖然可以用, 但是沒有人寫好 Java grammer,
要自己寫實在有點麻煩. 有些則是看起來不錯, 也有 Java grammer, 但是卻
無法成功使用, 例如 PyBison [2].

附帶一提如果有人想嘗試 PyBison 的話, 記得裝 PyBison 時要先裝 :

sudo apt-get install python-dev
sudo apt-get install build-essential

最後我是採用有名的 ANTLR [3], 它的 Python Interface 雖然還在發展中,
但是勉強是可以用了, 小 bug 自己改一下就好.

我使用的流程如下, 提供參考(以 MS 環境為例) :

1. 首先到官方網站下載 ANTLR 3, URL : http://www.antlr.org/

2. 解壓縮到特定資料夾, 例如 C:\antlr-3.0\

3. 設定 CLASSPATH, 讓 C:\antlr-3.0\lib\ 底下的所有 .jar 檔案都在
CLASSPATH 設定內, 可以參考這裡的說明進行 :
http://www.antlr.org/wiki/pages/viewpage.action?pageId=728

4. 到 C:\antlr-3.0\runtime\Python 底下進行 python runtime 安裝, 請參考 :
http://www.antlr.org/wiki/display/ANTLR3/Python+runtime

5. 到 ANTLR 網站上下載 Java grammer file :
http://www.antlr.org/grammar/list
嘗試產生 Python-based Java parser, 請參考 :
http://www.antlr.org/wiki/display/ANTLR3/Antlr3PythonTarget

6. 上述網頁上的 Java 1.5 grammer files 有很多個, 如果是使用 Terence Parr
的 grammer file (我是用這個), 則需要對於產生出來的 JavaLexer.py 以及
JavaParser.py 作一點修改. 此修改為在按照上面網頁執行 parsing 的過程中,
會出現語法上的錯誤, 請把錯誤的部分, 從 Java 語法改為 Python 語法即可.

如果有需要對產生的 Parser 作修改的話, 可以參考 ANTLR Python API Doc. :
http://www.antlr.org/api/Python/index.html


References
[1] Python Parser SIG, URL : http://wiki.python.org/moin/LanguageParsing
[2] PyBison, URL : http://wiki.python.org/moin/PyBison
[3] ANTLR Python, URL : http://www.antlr.org/