Software Cinema

最近我有一個關於 code commenting 的想法, 正交由學弟妹進行計畫以及撰寫 paper 中, 剛好找別的資料時又看到一篇有趣的文章 : Ryan Campbell 早在 2005 年寫的 Successful Strategies for Code Commenting [1]. 文章中列舉了數種 code commenting 的樣式, 探討了 comment readability 甚至 comment reusability, 嘗試從各個面向, 探討一個好的 code comment 應該要有的長相. 文章內的其他連結也都很值得一讀.

然而, 我們真的需要這些 successful strategies 嗎 ? 或是更準確地說, 我們需要為自己或是 project 找一套 successful strategies 嗎 ? 誰又能負責對於是否 successful 作 evaluation ?

Software engineering 的書裡常說, software 的存在是為了讓人們可以更加專注在於他們應該思考的事情, 而不需要去在意可以透過 software 解決的事情. 而選擇或是擬定 comment strategy, 真的是 programmer 在撰寫 comment 時, 應該要花時間去思考的事情嗎 ?

Referfences
[1] R. Campbell, "Successful Strategies for Code Commenting," August 2005,URL : http://particletree.com/features/successful-strategies-for-commenting-code/

About a month ago, I found that several refactoring patterns are expressed with thumbnails [1]. The following figure is Evolving to the Strategy Pattern thumbnail, expressed by several refactoring thumbnails, referred from [1].


And yesterday, when I was checking the differences between JUnit 3.x and JUnit 4.x, I found it again in the document of JUnit 4.x [2] release. The following figure is referred from JUnit 4.x document.


This figure contains rich information, and clearly shows the global picture of how and the order design patterns were composed in the design of JUnit 4.x, without revealing the details.

I myself usually do the similar thing when sketching the initial design idea, however there is no patterns or fixed forms of my sketch. The lack of regulation in the sketches makes the design granularity and leveling hard to control.

It would be wonderful if there exists a design tool that can hold the design granularity and leveling control for me...maybe by the design thumbnailing support ?

References
[1] Refactoring Thumbnails, URL : http://refactoring.be/thumbnails.html
[2] JUnit, URL : http://www.junit.org/

雖然主要編輯軟體改成 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/