Software Cinema

前一陣子計畫工作需要, 對不同的 use cases 寫法作了 survey.

A. Cockburn 著名的 Writing Effective Use Cases [Cockburn01] 其實已經歸納了好一部分, 然而牽涉到 user interface design 相關的部分時, 有些 use case 的寫法也不在他的歸納內.

底下就我 survey 的, 自行整理數個類別, 請注意下面的許多 diagram 名稱在 UML 中也出現, 但內涵並不完全相同.

• Scenario Style (Continuous Narrative Style) [Constantine01]
• Numbered Sentences [Constantine01]
• Mainstream Use Case Writing Style [Cockburn01][Overgaard04][Rosenberg01][Rosenberg07]
• Partitioned Narratives [Constantine01]
• Essential Use Cases [Constantine01]
• Activity Diagram [Almendros-Jim´enez05]
• Collaboration Diagram [Elkoutbi99]
• Use Case Maps [UCM07]
  
• Sequence Chart [Cockburn01]
  

Mainstream Use Case Writing Style 指的是目前主流的寫法, 具有 use case name, actor, use case relationships, pre-conditions, post-conditions, flow of events, alternative flow of events 等等. 其他的在相關的 references 裡都有清楚說明了, 在此不贅述.

比較有意思的是在 [Constantine01] 中使用的 Partitioned Narratives style, 為了方便 user interface design, 建議把 flow of events 分為 actor 以及 system 兩邊分開論述, 這樣彼此的 action/reaction 就會比較清楚. 在目前主流的寫法中尚未有此慣例, 但是似乎也有人開始建議應該在主流的寫法中加上此 style 限制, 讓 use case 轉換成為 object & associations 的過程中, 可以更順利, 減少不必要的 iterations.

另外 Use Case Map [UCM07] 是我一直很感興趣的項目. 第一次接觸 Use Case Map 大約是兩年前的事情了, 但是直到現在相關的 research papers 還是差不多兩年前的量, 頂級的研究成果更是缺乏, 但我始終覺得 UCM 很有潛力說, 可能只是時候未到吧, 還沒有遇到適合的 application context.


References

[Cockburn01] Alistair Cockburn, "Writing Effective Use Cases," Addison-Wesley, 2001
[Overgaard04] Gunnar Overgaard, Karin Palmkvist, "Use Cases: Patterns and Blueprints," Addison-Wesley, 2004
[Rosenberg01] Doug Rosenberg, Kendall Scott, "Applying Use Case Driven Object Modeling with UML: An Annotated e-Commerce Example," Addison-Wesley, 2001
[Rosenberg07] Doug Rosenberg, Matt Stephens, "Use Case Driven Object Modeling with UML: Theory and Practice," Apress, 2007
[Constantine01] Larry L. Constantine, Lucy A. D. Lockwood, Structure and Style in Use Cases for User Interface Design, URL : http://www.foruse.com/Files/Papers/structurestyle2.pdf
[Almendros-Jim´enez05] Jes´us M. Almendros-Jim´enez and Luis Iribarne, "Designing GUI components from UML Use Cases," Proceedings of the 12th IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS’05), 2005.
[Elkoutbi99] M. Elkoutbi, I. Khriss, and R. K. Keller, "Generating User interface Prototypes from Scenarios", PRocs of RE'99, 1999.
[UCM07] Use Case Maps, URL : http://www.usecasemaps.org/

V. R. Basili 在 1984 開始逐步提出 Goal-Question-Metrics 方法 [1] (後有人稱整個相關概念成為一個 paradigm), 而常見的引用以及較為完整的說明可以在 [2] 找到. 關於 GQM 的內涵, 目的以及用處在 [2] 中已有說明, 在此不贅述.

單看字面以及 [2] 的說明, 容易陷入錯誤的迷思, 認為 GQM 的流程在於推導出適合使用的 software metrics 而已. 這顯然是錯誤的認知. 在 Wikipedia 上對於 GQM 列出六個 steps [3], 而關於 software metrics 的推導僅佔了前三個 steps. 以下六個 steps 引用自 Wikipedia:GQM,

1. Develop a set of corporate, division and project business goals and associated measurement goals for productivity and quality
2. Generate questions (based on models) that define those goals as completely as possible in a quantifiable way
3. Specify the measures needed to be collected to answer those questions and track process and product conformance to the goals
4. Develop mechanisms for data collection
5. Collect, validate and analyze the data in real time to provide feedback to projects for corrective action
6. Analyze the data in a postmortem fashion to assess conformance to the goals and to make recommendations for future improvements

然而從這六個 steps 卻很難直覺看出在 GQM process 中, 自 conceptual level, operational level, 到 quantitative level 的 hierarchical relation, 更別說當 software metrics 完成後, 持續對於 product 進行 measurement 時的 goal-satisfaction 是如何藉由 question 被 answer 而達成. 因此我在理解 GQM 時, 是選擇以 GQM 本身的 architecture 為角度去詮釋 GQM 與 software measurement (product measurement) 的關係. 可以用下圖表示 :


我認為 GQM process 應該可以被清楚地分為兩個 phases. 在 Definition Phase 目的是推導或是組合適當的 metrics. 而在 Utilization Phase 則是利用推導的過程得到的產品, 包含 metrics, question 與 metrics 之間的 associations, goal 與 questions 之間的 associations, 自 bottom-up 去檢驗是否 goal 有被滿足, 從而出發 refinement actions. 而在這之中, 實際對於 data 進行 measurement 就發生在 utilization phase 的第一步. 同時這張圖也說明了 GQM 與 software measurement 之間的關聯.

在 GQM 身上事實上還留有許多相當模糊的空間. V. R. Basili 在 [2] 中事實上也是透過 examples 來說明 GQM 的使用而已. 然而這就留下許多問號, 例如究竟我應該選擇哪些 objects 設立 goals ? 怎樣的敘述較像是一個 goal ? 怎樣自 goal 推導出 questions ? 怎樣的敘述比較像是一個 question ? 怎樣為 question 定出合理的 metrics ? 這之中最大的問題可能還是在於 questions 身上, 也就是 operational level 的決定. 在我看過的書以及 papers 中, 對於怎樣使用 GQM 似乎還沒有一個比較明確的 rules 出現. 先階段似乎只能夠根據一些 examples, 或是看看別人的 papers 怎樣利用 GQM 進行說明, 來仿效使用.


References

[1] V. Basili, Barry T. Perricone, "Software Errors and Complexity: An Empirical Investigation," Communications of the ACM, vol.27, no. 1, pp.42-52, January 1984
[2] V. Basili, G. Caldiera, and H.D. Rombach, The Goal Question Metric Approach, Encyclopedia of Software Engineering, pp. 528-532, John Wiley & Sons, 1994.
[3] Wikipedia:GQM, URL : http://en.wikipedia.org/wiki/GQM

當初看上 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/

看到一個好玩的網站 : FloorPlanner , 可以用來幫你規劃家裡的各樓層擺設, 有商業版軟體, 但是也可以註冊他的免費帳號, 可以試用線上版 (使用 Flash 製作). 註冊只要使用 emial 帳號跟設一個自己的密碼, 門檻很低.


進去後可以 create 自己的一個新的 project, 或是開啟別人的來看, 結果我開了其中一個名為 container 的規劃圖, 共兩個樓層 :


而且他也把 tag system 用在分類大家的規劃圖, 所以使用線上系統的人, 就可以共同快速地分享自己不同空間的設計.

使用設計上相當直覺, 以 Drag&Drop 為操作基礎, 分為三個控制 menu, 一個是 (1) 新增房間, 門, 窗, 註解等等 global constructs 的 menu, 一個是 (2) 新增各種家俱的 library menu, 下拉式選單內有各種 library, 另外一個是 (4) navigation menu, 就是左移右移放大縮小啦, 另外 (3) 的編輯部分也是很容易操作, 直接用滑鼠拉空間範圍, 換顏色等等, 搭配 library menu, 很快就能作出很漂亮的設計.

以 Software Product 的角度來看, 真是一個很吸引人使用的 Software :)