Software Cinema

雖然主要編輯軟體改成 OpenOffice.org 有一段時間了, 不過遇到某些狀況還是跟 OOo 白痴沒兩樣, 就跟以前使用 Word 一樣.

雖然說身為唸 software engineering 的人, 覺得責任也不全在我身上, 編輯軟體的 user interface design 應該是很典型的, 遵守 "讓使用者專心在他該花心思的事" 去設計, 而不是當使用者想要什麼效果時, 還需要抱著一兩本厚厚的書在翻找, 或是找有深厚使用經驗的 "高手" 求救 (通常這情形發生的越多, 表示這 software 的 user interface 設計越有改進的空間). 過去 Word / Office 每次出新版, 市面上的相關書籍就琳琅滿目, 該說 M$ 跟這些書的作者也算是某種共犯結構嗎 ?

回到 OOo 的自訂頁碼起始值好了, 如何插入頁碼在 OOo 的基本操作手冊文件裡已經有說明, 但是當我要自訂文件的頁碼起始值, 也就是希望頁碼不見得要從 1 開始, 可以從 15, 43, 或是任何數字開始呢 ?

(以下方法適用於 OOo 2.1, 也就是我現在使用的版本.)

有兩個方法, 第一個是在頁碼上按滑鼠右鍵進入欄位設定,

在欄位設定的格式選項下方, 有一個叫做修改的可修改欄位. 但問題是, "修改" 是什麼意思 ? 要修改什麼 ?

實際試了之後才會發現, 這裡的修改意思是對於目前頁碼的修改, 而且是加減的修改, 而不是直接替換掉原本的頁碼. 舉例來說, 如果把這裡填 10,

確定之後就可以看到原本頁碼是 32, 變成了 42, 同時上下相連的頁面, 其頁碼也會跟著改變. 換句話說, 原本的 32 + 修改的 10 = 最後的 42.

第二種方法就更神奇了, 你必須要把游標移到要改頁碼的該頁, 比如說剛剛的 page 32, 頁面內容的第一段上, 然後右鍵進入段落設定中. 請注意要是第一段, 否則改變的頁碼會從下一頁開始產生影響.

進入段落設定中, 在中間的位置有換行與分頁的設定, 需要把插入以及使用頁面樣式都勾選, 然後才能對右邊的頁碼進行調整, 一樣把他改到 42.

按下確定之後, 一樣可以看到 page 32 變成了 page 42. 但是請注意, 這種方法所造成的頁碼改變, 僅限於 page 32 及其以下的頁面, 換句話說 page 33 會變成 page 42, 但是 page 31 仍舊只會是 page 31, 跟第一種方法的影響不同.

Well, 回過頭來說 user interface design, 像是這種 design, 一來在使用者想要某項功能時, 很難以選擇施行(因為根本不知道可以這樣改阿), 二來對於究竟會造成什麼效果 (post-conditions), 也難以掌握. 今天只是改個頁碼就可能出現兩種不同的結果, 要是改其他的東西, 使用者如何放心文件的其他不相關部分不會被偷偷的進行什麼變動 ? 如果每次作設定的改變都需要使用者重新檢查文件一次, 這未免太累人了 :(

從這個 case 其實可以深入探討三個議題,

1. use case consistency : 如果上述兩個方法其實是同一個 use case, 或是相似的 use cases, 那麼他們的 post-conditions 是否應該保持一致 ?

2. use case understandability : 如何讓使用者事先意識到在他所使用的 use cases 中, 最終會對文件帶來什麼改變, 而不是等到 use cases 執行完了, 才讓使用者去找尋造成了什麼改變. 畢竟 use case 在 forward engineering 中本來就是給 customer 看的東西, 沒道理在真正使用 software 時反而不能從 use case 裡得到應該知道的訊息.

3. document-preserving activity : 這是從 refactoring 的 behavior-preserving 借用過來的, 以編輯軟體來說, 是否部分 activity 應該可以視為對 document 作了 refactoring, 同時這些 activity 也必須具備某種 document-preserving 的特性. 舉例來說, 上述的兩種頁碼變更方式, 第一種會維持頁碼的連續性, 第二種則是會打斷頁碼的連續性, 這可能是兩種不同的編輯功能, 但是顯然地他們造成的效果是不一樣的, 換句話說這兩個 activity 對於 document 的改變事實上就是具有不同的特性.

阿...越扯越遠了, 就此打住, 有機會再深入討論這些想法吧 :)

前一陣子計畫工作需要, 對不同的 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 也負有一些責任呢 ?