Software Cinema

Borland 今天正式公佈了三個預計於秋季釋出( release ? 販售吧 :p )的新工具. 詳細情況可以參考 Computer World 的這篇新聞 : Borland adds tools aimed at making application development more transparent.

三個 Tools 分別為 :

• TeamDemand : 這個是三個 Tools 裡我覺得最沒想到的. 企圖把 User Requirements 連結到 Development Tasks 以及 Development Process, 想要提供 Business Users ( Customers ) 一個可以即時 ( Real-time ) 獲知目前進度的溝通管道. 我認為這要做得到其實不難, 但要做的好不容易. 簡單的來說, 能夠讓 User 根據 Requirement 隨時輸入 Test Cases 其實就成功一半了, 接下來只要自動找到相對的進度作 Testing 就是另一半, 不過這之間都還隱藏許多問題.
  

• TeamFocus : 看來應該是用來連結 Developers 使用的 Tools, 彙整相關的 Information, 產生開發過程中的相關 Reports. 預計可以大幅降低 Developers 需要花時間在整理 Intermediate Report 的時間.

• TeamAnalytics : 根據 Project 內部可以獲得的各種 Information, 結合在特定 Domain 下適用的不同 Metrics 組合, 量測出 Project 目前的狀態, 對於不佳的情況可以事先給予 Warning. 尚不知內部怎樣管理 Metrics,不過如果是用類似 GQM 方法的話, 應該可以想像 Goal 沒有達到預期就是一種 Warning 了.

現在我在做的其中一個 Project 其實就是 Team Focus + TeamAnalytics, 另外其實再結合另外一個小 Project 也可以朝 TeamDemand 去作, 只是之前沒想到. 不知道該向 Borland 投以敵視的眼神還是感激的眼神 XD

Borland 真是 IDE 界的巨人阿~~

這篇 Paper [1] 介紹了一個以 Completion Strategy 為中心的 Programming Learning System.

Paper 中對於 Completion Strategy 的說明如下 :

The completion strategy uses well-designed programs as basic programs to be completed,modified and extended. The completion strategy suggests that the learning contents or programming skills should exist in the well-designed programs. These model programs may be complete or incomplete, and it is students’duty to modify or extend the original model program.

說白一點其實 Completion Strategy 跟 Fill-In-The-Blanks 有點像. 最單純的一種就是克漏字填充, 讓你清楚知道前後文, 請你填出正確或是合理的句子. 在 Programming Learning 中當然就是特定的語法, 或是變數宣告, Method Call 等等. 當然也會有比較複雜的情況, 例如留下一整個 Method 的內容, 要你根據 Spec. 或是說明, 把特定的演算法在該 Method 中實現. 這又比較像是利用 Design by Contract [2] 先規劃好框框, 再請你完成內容.

再有一種情況則可能是請學生 Extend 特定的 Class 或是 Function. 例如可以利用 Observer Pattern, 請學生建構自己的 Observer, 而教師利用 Subject 送出 State Information 去測試. 我以前給大一學生出作業時也作過類似的事情. 在 Paper 的敘述中也提到 Modification 的情況, 可能請你把某個 Depth 很深的 Loop 利用 Recursive 改掉, 或是修改某個 Function 的運作等等.

不管是哪一種, 基本上都是特過特別的規劃, 使得學生在完成練習的同時, 可以知道 Program 運作的細節, 以及學習到特定的 Programming Skill & Experience. 而在單一題目之外, 需要考量的還有如何安排一系列相關的 Completed/Incompleted Problem 給學生, 同時藉由學生的學習情況, 動態決定下一個題目該如何選擇以及製作. ( 以下圖片均參考取用自 [1] )


如上圖, 此 Paper 所提出的系統中, 具備一個 Problem Database 儲存各種 Problems. 一個 Problem 由主體的文字敘述, 以及相對的 Solution 組成. Solution 通常又是以數個 Templates 依序組成., 如下圖表示 ( 正確來說下圖的例子是 Problem Extension, 不過跟 Problem 的格式是一樣的 ) . Templates 被收納在 Template Library 中. 一個 Template 其實是一個 Code Slice/Fragment, 但是把其中要給學生填入的部分事先作宣告, 而在一個 Templates 中也允許嵌入其他的 Templates. 如下圖所示, 在 Average Template中, 也利用了 Output Template.

由於從 Problem/Solution 到 Templates, 以及 Templates 之間的組成關係, 因此一個給學生的 Completed/Incompleted Problem 的行程事實上是透過數個 Iterations 的 Expansion 所形成的, 例如 Paper 中所舉的例子 :


在第一張圖中央的 Problem Generator 具有一個 Learning Operator, 負責根據 Evaluation 結果決定下一個題目是什麼. 其實這個部分以及 Problem 之間關聯性的設計, 是我覺得整個系統是否有效的關鍵之一, 但是 Paper 並沒有在此著墨太多, 畢竟這應該是屬於 Completion Strategy 本身的問題了. 但我認為如果把問題縮小到Programming Learning 的框框下, 其實還是有探討的空間, 只是可能無法得到一個完美的答案, 就像盧梭無法為愛彌兒設計一個完美的教育流程一樣.


References

[1] Kuo-En Cheng, Bea-Chu Chiao, Sei-Wan Chen, and Rong-Shue Hsiao, "A Programming Learning System for Beginners - A Completion Strategy Approach," IEEE Transactions on Education, vol.43, no.2, May 2000

[2] Bertrand Meyer, "Applying Design by Contract", IEEE Computer, vol.25, no.10, pp.40-51, October 1992

奧運 8 搶 3 的錦標賽官方網頁出現了令人傻眼的投手防禦率排行表, 居然把投手防禦率由高至低排名, 是在選爆爆樂投手第一名嗎 ?


負責網頁製作的是 yam 天空, 我說 yam 的工程師阿, 就算你不懂棒球也該做好 domain analysis 吧, 另外承辦單位負責作 validation 的人也在混阿. 雙方都在系統沒有經過 validation 的情況下就上線了, 或許他們有測了 "functionality", 但是原本所建的 test case 就是錯的阿 XD , 再怎樣測結果也會是錯的.

這個例子也充分說明, test case 的確不是在 design phase 或是 implementation phase 再建就好, 而是應該從 domain analysis 一路下來, 階層式地 ( hierarchically ) 建立 test cases.

Built-in Test (BIT) 簡單來說就是把 object 內( 在 OO 中來說 )加上 self-testing 的部分, 因而此 object 就會有兩種 modes, 一種是正常的 functional mode, 另一種是 testing mode. 藉由執行 testing mode, 可以確認 object 的運作是否正常, 因而達成 testing 的部分目的. 因為此 tests 是建立在 object 內, 因此叫做 Built-in Test.

下圖取自於 [Wang2000] 可以簡單看出 BIT 的概念, 至於 BIT 的地位以及原始概念可以參考 [Binder1994] :

這些 built-in tests 可能會以 testcases 的方式呈現, 但是基本上跟 JUnit 之類的 testcase 還是有所不同. 例如 BIT 可以測試的對象以及能保證的事情, 跟一般在 object 外部的 testcase 就不完全相同, 同時兩者所持的觀點也不相同.

當然我們也可能把一般的 testcase 整合進 object 內作成 BIT 的樣子, 但是這樣一來就失去了不少 flexibility, 同時也造成 maintainability 的問題. 另外一個問題是, BIT 幾乎只有對原始程式碼了解的人, 可能只有原本的 developers, 可以產生, component consumers 要加入 BIT 有許多困難存在.

References

1. [Binder1994] Robert V. Binder, "Design for Testability in Object-Oriented Systems," Communications of the ACM, vol.37, no.9, pp.87-101, Sept. 1994


2. [Wang2000] Yingwu Wang, Graham King, Mohamed Fayad, Dilip Patel, Ian Court, Geoff Staples, and Maraget Ross, "On Built-in Test Reuse in Object-Oriented Framework Design," ACM Computing Surveys (CSUR), vol.32, no.1es, March 2000