Software Cinema

這篇 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

此篇文章以台大本身所建立的 CEIBA 數位課程管理平台 為例, 藉由使用統計數據, 說明 Learning Management System 在教師使用情況上, 成功關鍵在於系統設計之初, 是否針對校內教師的需求進行設計, 而非系統平台本身的技術性問題.

Before investing time and money to develop technically advanced tools, it is necessary to investigate the needs of the faculty [1].

這在軟體開法方法論中, 其實並不是甚麼新的結論, 但是如果我們以國內的情況來說, 卻很少有學校的管理階層體認到這一點.

在文章中也特別提到 CEIBA 建構團隊針對台大人文相關系所的教師需求, 在 CEIBA 上提供建立多媒體互動教學資料的輔助工具, 使得不懂 PC 操作的人文科系教師也很容易可以利用該系統建立所需要的教學資料. 這點聽起來似乎不簡單, 好像似乎要提供很強大的使用者介面的感覺. 但是我覺得如果真的有實地去蒐集教師的需求, 在 CEIBA 內可能只需要很簡單的功能就可以達成相當好的效果. Software 只是解決問題的 Solutions 其中一種, 而選擇 Software 的理想目的應該是為了使用者省下許多麻煩, 在幾乎不用改變正常工作流程下享受 Software 的好處.

從下圖可以看到, 自 2000 年到 2007 年, 人文相關科系的教師使用情況, 遠比理工科系的來的理想. 除了上述的原因, 可能也跟理工科系的老師習慣自己或請學生準備教學資料, 再放到網路上, 而非使用統一的教學平台有關. 不過文章並沒有針對此一部份進行說明.


另外在文章中也針對 CEIBA 上各項功能在 95 年第二學期的使用情況做了統計. 其中 Interaction 部份的使用情況都偏低, 相對來說 Knowledge 部份則比較高. 可以看出學生還是不習慣使用網路平台進行互動式學習. 這可能也跟台灣學生習慣在講堂上單方面接受來自於教師的知識傳授, 但是較少藉由團體合作進行課程學習有關.

另外我覺得值得一提的, 但是文章中可能因為與重點無關所以沒有說明的是, 看起來 CEIBA 自 1995 開始歷經了數年幾代的發展, 目前是CEIBA 4, 其中自 CEIBA, CEIBA 2, CEIBA 3, 到 CEIBA 4 每一代的發展維護人員幾乎都不相同. 很好奇 CEIBA 本身的 Quality 如何, 畢竟在 1995 到 2000 年, 對於 Web-based System 的 Quality 觀念應該還不成熟, 同時許多功能應該是最近幾年才加上去的. 很想看看是否有 CEIBA 對照 New Features 與 Quality 變化的相對數據圖表.


References

[1] Hsiu-Ping Yueh and Shihkuan Hsu, "Designing A Learning Management System to Support Instruction," Communications of the ACM, vol.51, no.4, pp.59-63, April 2008