Software Cinema

這幾天在做一些 Survey 時, 看到幾個有趣的 Authentication & Authorization 機制.

* Some images/pictures bellow are extracted from the papers. Please let me know if there is any legel right violation.

1. Graphical Password

P. Dunphy, A. P. Heiner, and N. Asokan, “A Closer Look at Recognition-based Graphical Passwords on Mobile Devices,” Proceedings of the 6th Symposium on Usable Privacy and Security, July 2010.

這篇 Paper 提到了事實上 PIN 機制備使用率偏低的情況 (畢竟忘記密碼而不能想打電話就打很麻煩, 要處理更麻煩), 同時就算有設密碼, 也可能是很簡單的 0000, 1111 這種 (我就這樣 @@).

作者們提出利用現在手機上的儲存的私人照片, 讓使用者自行選定某張照片, 或是某個 Combination 作為密碼, 取代原本的數字或字母組合. 其中也探討及引用了人對於影像記憶的能力, 怎樣自動選擇容易被記住的影像, 以及私人照片對於旁邊不經意偷看的人不容易記得等等.


不過我覺得這方法還有一些討論的空間, 像是 (1) 私人照片怎樣可以自動避免出現太過侵犯隱私的, 例如只篩選出旅遊照, (2) 影像組的順序本身往往有 Semantic Meaninig, 是否還有利用空間等等.


2. Eye Tracking

A. D. Luca, M. Denzel, and H. Hussmann, “Look Into My Eyes! Can You Guess My Password?,” Proceedings of the 5th Symposium on Usable Privacy and Security, July 2009.

這篇是整合 Eye Tracking 技術到 Authentication & Authorization 中, 利用你的眼睛注視定點的移動順序, 作為 Password 來通過 Authentication. 主要的優點是, 許多側錄或是旁邊偷看的攻擊方式幾乎就都行不通了.


雖然有趣, 但是實際應用上還有很長的路要走, 要有相當的軟硬體支援才行, 無形中也限制可應用的情境.


3. Changed Context

V. Hourdin, J. Y. Tigli, S. Lavirotte, G. Rey, and M. Riveill, “Context-Sensitive Authorization in Interaction Patterns,” Proceedings of the 6th International Conference on Mobile Technology, Application Systems, Sept. 2009.

此篇利用 Observing Interaction Behaviors 作為 Contextual Information, 來判斷已經過了 Authentication 的使用者, 是否在 Valid Session 中, 被 (偷) 換成其他的真實使用者. 換句話說, 是作為輔助性的機制, 去避免使用者因為任何情況被置換了...比如說忘記 logout 之類的.


不過我覺得這篇 Paper 裡沒有舉出比較具體應用的例子是比較可惜的地方. 因為這方法不一定在任何 Cases 下都會很好用, 因此哪些類型的系統適合, 就變成很重要的資訊.


4. Mode Switch based on Context

J. Seifert, A. D. Luca, B. Conradi, and H. Hussmann, “TreasurePhone: Context-Sensitive User Data Protection on Mobile Phones,” Proceedings of the 8th International Conference on Pervasive Computing, pp. 130–137, May 2010.

現在的高階手機通常可安裝相當多的應用程式, 自然也有相當多的 Data 儲存在裡面. 有不同的 Data 種類, 包含工作, 理財, 家庭, 朋友等等... TreasurePhone 的概念是, 不同的 Data 應該要只允許在相對應的情境下可以被取用. 譬如說工作相關的 Data 就應該只有在工作的情境下可以被取用, 這樣就可以避免被家人或是朋友看到.


作者們把該取用情境稱為 Sphere, 而 TreasurePhone 即根據目前的 Sphere 來決定應該設定為哪種工作模式.


5. Distorted Pictures

E. Hayashi, N. Christin, R. Dhamija, and A. Perrig, “Use Your Illusion: Secure Authentication Usable Anywhere,” Proceedings of the 5th Symposium on Usable Privacy and Security, July 2008.

這篇也很有趣, 應該要跟 P. Dunphy et al. 那篇一起聯想. Authentication by Distorted Pictures 的概念其實就是: "熟悉的人不需要獲得全部的資訊就可以拼湊出正確的資訊". 舉例來說, "pasword" 雖然少了一個 s, 但是看的人直覺就知道是 "password".


所以可以進一步確保, 只有知道原本該照片的 Semantic Meaning 的使用者可以準確答出. Paper 裡面也有討論到在 Distorted 後, 可能產生 Sementic Meaning 混淆的情況, 像是黑白外殼的電池跟熊貓.


6. Musical Password

M. Gibson, K. Renaud, K. Renaud, and C. Maple, “Musipass: Authenticating Me Softly with “My” Song,” Proceedings of the New Security Paradigms Workshop, pp. 85–100, Sept. 2009.

列出這篇單純是覺得有趣. 作者們想要用 Music 取代以字母跟數字為主的密碼. 進行 Authentication 時, 是透過輸入一組旋律的方式來進行驗證.


不過我個人是認為, Musical Password 示好想法, 但是依照這個方向跟設定是錯的. 因為缺點太多. 雖然有些缺點在 Paper 內有想利用一些方式解決, 例如 Training, 但是比起傳統的 PIN 跟 Image-based 方法實在沒有太多優勢, 作者自己也在 Paper 裡面承認這點.


7. Context Sensor Data

A. Nosseir, R. Connor, C. Revie, and S. Terzis, “Question-Based Authentication Using Context Data,” Proceedings of the 4th Nordic Conference on Human-Computer Interaction, pp. 429–432, Oct. 2006.

這篇跟我 Master Thesis 有關, 但是當時真沒想到還有這樣的應用 @@

這篇的作者們利用一般人生活環境中可能有的 Context Sensors, 所回報的 Data, 自動產生 Quesitons, 用來作 Authentication 使用. 比如說, 你今天幾點離開的家門, 幾點泡的咖啡, 泡了幾人份等等... 不是很親密且持續觀察你行為的其他人, 很難正確地做出回答.


不過呢, 我認為這個系統有個致命的缺點... 一旦攻擊者知道你在用這個系統, 就完了 = = , 因為答案就在你的生活中...

今年雖然有投上 ICSEA 2010, 但是受限於早先已經申請了到 SEKE 2010 的補助了, 不太方便再跟國科會申請, 只好放棄 Nice 之行, 委託也有投上的另位實驗室同仁代為進行 Presentation.

不過帶回來的 Proceedings 還是應該掃過一次. 雖然 ICSEA 不算是頂好的 SE Conference, 但是我還蠻喜歡逛這種 Proceedings, 有時候會發現一些不成熟但是有趣, 具啟發性的想法 :)

1. A. Martin, R. Mazalu, and A. Cechich, ''Supporting an Aspect-Oriented Approach for Web Accessibility Design,'' pp.20-25

Software GUI Design 事實上從 70 年代以來就沒有公認的 Process. 雖然期間曾經有一段時間出現了各種 Methodology, 也有類似於 OO 分析的方法出現, 但是始終對於應該在何時開始考量 GUI, 中間的 A/D/P Process 與 Application 本身的 A/D/P Process 關係, 以及後續的 Maintenance 議題, 沒有一個串起來的發展系統. 而 Web GUI Design 近年來的思考似乎也漸漸向 Conventional Applications 靠齊... 除了看起來 Style 不太一樣, 其實操作模式都跟 Conventional Applications 很類似. 如果我們把 Browser 換成一般的 Client-side Interface, 似乎就也沒什麼兩樣. 我倒是很期待看到 Web GUI Design, 或是討論 Accessibility 議題是, 如果針對 "User 使用同樣的 Client-side Interface (Browser) 來看所有的 Web Applications'' 這點作討論的話, 會出現什麼樣的 Papers.

2. H. P. Breivold, D. Sundmark, P. Wallin, and S. Larsson, ''What Does Research Say About Agile and Architecture ?'' pp.32-37

我對於這篇的 Summary 不太意外, 因為整篇直接嘗試把 Agile 對於 Architecture 的影響在不限定 Context 的情況下去評估, 本身很可能得不到任何有意義的結論. 對我來說 Agile 其實是不適合直接跟其他的 Paradigms 去比的. 更進一步來說, 大部分的 Paradigms 都有它最適合的使用情境, 硬是要拉在一起比意義不大. 比較重要的是, Managers / Developers 是否可以在適當地時候得到該使用哪種 Paradigms 最有利的建議. 以這篇來說, 如果可以鎖定目前最常使用 Agile Paradigm 的開發情境, 再歸類此情境下最常被採用的 Architecture Design 類型, 再來作討論會比較有意義.

3. M. Basdavanos and A. Chatzigeorgiou, ''Placement of Entities in Object-Oriented Systems by Means of Single-Objective Genetic Algorithm,'' pp.70-75

這篇讓我想到五年前在實驗室的一個沒有完成的計畫. 該計畫的其中一個觀念就是把 Use Cases 當作 Capabilities 的集合來分析, 所有的 Objects 事實上是 Capabilities 的 Distribution. 這樣做的目的很抱歉無法在這裡說明...畢竟這是個不知道什麼時候會活起來的計畫. 不過可以理解在這篇裡面嘗試把所有的東西都打散, 不要依照直覺與經驗式的去找出 Objects 的想法. 但是在此之前的前端分析方法 Papers 中沒有明說...我覺得這對這篇 Paper 的 Justification 還挺重要的. 另外值得注意的是 Second Author 是 Alexander Chatzigeorgiou, 他跟 Nikolaos Tsantalis 的幾個 Works 真是令人印象深刻, 也讓我對這篇的下一步充滿期待阿...

4. M. Gebhart, M. Baumgartner, and S. Abeck, ''Supporting Service Design Decisions,'' pp.76-81

這篇左看右看總覺得, 跟 OO 的某部份分析方法好像阿(笑), 只不過一些關鍵字, 像是 Class, Coupling, Metrics, 沒有被拿出來, 也沒有被 Formalize 就是了. 我想, Service-Oriented Computing 跟 Functional Paradigm 以及 OO Paradigm 之間的關係, 應該在未來的兩年內就會很明朗了, IEEE TSE 上已經開始有 Paper 表明立場了...

5. H. Kaindl, J. Falb, S. Melbinger, and T. Bruckmayer, "An Approach to Method-Tool Coupling for Software Development," pp.101-106

因為這個方向, 實驗室也有一個延續性的計畫方向在做, 不便評論太多, 但是這個題目很實用也很有趣. 簡單來說, 現在的 Software Process/Paradigms 越來越多, 裡面要做的事情越來越細也越明確, 但是又不是每個細項都要在每一次的 SDLC 中被作到. 另一方面, 不管是 Commercial 或 FLOSS 的"工具"也越來越多, 同時各項工具目的用途有重疊也有相異, 有些共享標準有些沒有. 好的工具很重要, 如何知道根據工作選與使用好的工具更加重要... 大概就是這樣的問題.

6. M. Y. Santos and R. J. Machado, "On the Derivation of Class Diagrams from Use Cases and Logical Software Architectures,,," pp.107-113

從 Use Case Diagram 到 Class Diagram 的自動生成也是一個老問題了, 近幾年來幾乎沒有什麼新的東西出現, 主要還是這技術本身有 Accuracy, Reliability 的問題在, 連帶影響 Efficiency & Effectiveness... 太小的系統用處不大, 太大的系統又沒人敢/有必要用. 不過這篇 Paper 倒是提供了另外一個角度的思考: 如果在 Transformation 過程中, 加入了 Domain-Specific 的 Constraints 進去, 是否會讓這個技術有 "轉換" 之外的價值產生 ?

7. K. Popovic, Z. Hocenski, and G. Martinovic, "Do the Software Architects get the Need Support for the Job They Perform ? pp.123-128

這篇我只對最後一個整理出的 "What Architects Do and What They Need" 表格有興趣. 要我自己整理可能都要花個幾天想想.

8. S. Gunther, M. Haupt, and M. Splieth, "Agile Engineering for Internal Domain-Specific Languages with Dynamic Programming Languages," pp.162-168

我覺得這篇還不錯, 從務實的的角度把 "大家其實都是這樣作 DSL 的", 以及 "這樣作 DSL 比較會有人用" 給整理出來. 其實 Domain-Specific Language 可以說無時無刻都存在, 只是透過 Formalization / Standardization, 以 Language 的角度作整理, 才能有效地利用/重利用. 而建立於既有的 Programming Languages 之上, 可以省去建立 Compiler 的麻煩, 同時如果跟自家產品用同一種 PL 就有更多 Traceability Management 上的好處. 不過現有的 Dynamic Programming Languages 在被利用來建立 DSL 的侷限性, 例如適用的 Domains 等等, 似乎還是一個未知的問題 ?

9. S. C. de B. Sampaio, E. A. Barros, G. S. de A. Junior, M. Jose, C. e Silva, and S. R. de L. Meira, "A Review of Productivity Factors and Strategies on Software Development," pp.196-204

就只是關於 Productivity Factors 以及 Productivity Improvement Strategies 的整理. 可參考用.

10. M. Breu, R. Breu, and S. Low, "Living on the MoVE: Towards an Architecture for a Living Models Infrastructure," pp.290-295

我只能說, 有夢最美阿... 基本上有統一的 MetaModel. 以及不斷被建立的 Adapters 當然是很理想. 問題是一個不需要時常被更新的 MetaModel, 勢必造成不同 Models 之間的實質差異性會很大, 這樣的話能夠透過 Adapter 去解析與管理不同 Models 的能力就變低. 退一步來說, 在 Programming Languages 的轉換問題上, 也曾經造成一陣子的風潮, 但是現在幾乎沒有看到人在談了, 取而代之的是從根本建立一個共通的中介碼, 然後不同的 Programming Languages 則是根據用途變成不同 "Interfaces" 的感覺. 但是連在 Programming Languages 階段的改變, 實質效益跟使用度/接受度都還沒有明顯的功效之前, 我覺得一下子拉到 System Modeling 的層級還太早.

11. N. M. Carod and A. Cechich, "Cognitive Profiles in Understanding and Prioritizing Requirements: A Case Study," pp.341-346

雖然我認為如 Paper 內所提到, 此篇的 Study 結果也很難被用來佐證在其他 Context 下, 此方法的有效性, 但是 "感覺應該會有效" 卻是很直覺. 要想看到比較大規模的 Case Studies 也許還要等好一陣子, 畢竟這個想法的相關工具跟實驗應用的商業公司數量感覺都還不算多. 同時如何建立 Cognitive Profiles 在不同的應用情境下似乎又是一個不同的問題. 或許把此想法跟 Visual Software Requirements 結合會有意外的發展...

12. G. Grambow and R. Oberhauser, "Towards Automated Context-Aware Software Quality Management," pp.347-352

這篇 Paper 在 Abstract 以及 Solution Approach 一開始所描述的其實是一個 Too Good to Be True 的理想, 貌似我在碩一快結束時提的碩士論文題目也是類似的想法, 而且還包含更多 SDLC 的東西在 Context-Aware 的概念下, 所以我完全可以理解這篇作者的 "偉大願景" :p 很遺憾理想跟事實總是有相當落差... 從 GQM 出發我不認為是個好選擇, 因為 GQM 相當倚賴經驗法則去建立 Model, 要想全自動化需要先建立相當程度的假定 (Assumptions), 而這又會讓 GQM 變得不好用. 從這篇所引用的 Agent-based GQM Papers 全都是出自不太有名的會議論文也可略窺一二.

13. C. L. Reis and J. M. Pacheco, "Minimizing CO2 Emissions in a Computing World," pp.395-399

跟內文無關, 只因為最後一頁的那張圖 (話說, 內文也沒直接引用到這張圖阿... = =). 這圖很有意思, 最近有個題目的關係, 正在重新思考 Distributed Computing, Grid Computing, 到 Cloud Computing 之間的關係, 跟演進的理由. 這張圖在某個角度上還蠻符合我目前的想法. 這三個名詞都是指不一樣的東西, 雖然核心技術會感覺很像, 但是本來 CS 很多技術都是舊的, 只是當 User & Context 改變了, 想要達到的 Perception 也改變了, 導致最終提供的 Services 也改變了, 此時 Challenges 也不一樣了. 當然, 達到的效果也完全不同.

覺得比較有意思的, 扣掉自家實驗室的, 大概是這些篇, 因為按照順序看下來, 基本上頁數也是照順序. 在 page 399 之後的覺得有些跟 SE 關係其實較遠了, 有些非常技術性, 就是穩定地建立一個演算法來加強或解決某個具體的問題之類的, 可衍生的想法較少, 就都不記了.

The idea behind Wang et al.'s paper "An Online Monitoring Approach for Web Service Requirements" [1] is simple and useful. The challenges their study faced is to ensure the behavior of Web services consistent with their requirements. To achieve that, a monitoring approach is taken. They built a monitoring model including five specific system event types. Further, a monitoring framework is also built to providing probes, agents, and analysis components based on the monitoring model. In short, this study contributes an external behavior monitoring approach to ensure the Web service behavior to be consistent with requirements.

Extended Questions and Remarks:

• Is the same chanllenge ever discussed in conventional software development, ex. CBSD ?
• What's the trade-off applying this approach in practice ? ( required extra human resource, development and maintenance effot, and so on )
• Can some constraints mentioned in this study be validated using Web service testing tools in development phases ?
• The security issues behind this approach : Who can be the administrator and What services can be monitored ?

References

[1] Q. Wang, J. Shao, F. Deng, Y. Liu, M. Li, J. Han, and H. Mei, "An Online Monitoring Approach for Web Service Requirements," IEEE Transactions on Service Computing, vol.2, no.4, pp.338-351, Oct./Dec. 2009

這篇 Short Paper [1] 以及所建立的 Tool ADORA, 包含重點大致可以歸納為兩點.

首先是使用 Fisheye View 的概念改進目前大部分 Tools 在協助使用者瀏覽整張 Software Design Diagram 時的問題. 既有的 Tool 在面對相當複雜且巨大的 Diagram 時大多無能為力, 往往需要使用者自行將 Design Diagram 從 Object Analysis ( 如果是在 OO Paradigm 中 ) 以後, 分為 Class Level 0, Class Level 1, ...... 等詳細程度不同的數張 Design Diagrams, 方便在不同的 Abstraction Level 間切換. 少部份 Tools 可以自動隱藏 Details, 但是當進行 Zoom In / Zoom Out 時卻是會對於整張圖作變化, 無法自由地只 Zoom In 想要進一步觀察的部份. Fisheye View 則讓此操作方式成為可能. ( 以下 ADORA 圖片皆取用自 [1] 並稍加編輯, 且無修改圖片本身內容 )


關於第一點在去年底我們實驗室有一位同仁在進行實驗室會議報告 Paper 時也有提到類似的概念, 當時他是用 StarCraft 當作例子, 在 StarCraft 中同時有主操作畫面 ( Local ), 以及左下方的微縮地圖全圖 ( Global ), 來說明如果 Design Tool 有類似的支援好像不錯. 當時大家討論都集中在使用方式上, 看了 [1] 的實做, 好像在 Layout 計算位置上也不是那麼容易實現, 畢竟要兼顧到整張圖的 Re-arrangement, 不能因為 Fisheye 使得整張圖亂掉. 我想這也是 [1] 裡面要強調可恢復性 (Stability) 的原因. ( 以下 StarCraft 插圖引用自 http://spyhunter007.com/game_over.htm )


第二是對於 Single Integrated Model 的理想. 在 Paper 尾段嘗試性的把不同時間點的一些 Diagrams 疊合在一起, 包含 User & Context, Use Case Diagram, 以及 Class Diagram. 可以想見的, 這樣一來就可以透過 ADORA, 在 Software Development Phases 之間快速自由的移動, 瀏覽相關的 Analysis Diagrams, Design Diagrams.


不過我認為 Single Integrated Model 的需求, 使用時機及模式, 以及呈現方式都還有很多探討的空間, 在本篇 Paper 中也沒有再著墨太多. 像是上圖左, Use Cases 跟 Classes / Components 混在一起的感覺就很奇怪, 也沒有因此曝露更多 Information. 如果改用 Use Case Map [2] 來作整理可能會好點. ( 話說 Use Case Map 是怎樣, 不紅到原本的介紹網頁都消失了, 現在只依附在 jUCMNav 底下了 XD )

或許之後在 Software Design Tools 中會出現更多這種 Visualization Information Mash-Up 的應用.


References

[1] T. Reinhard, S. Meier, R. Stoiber, C. Cramer, and M. Glinz, "Tool Support for the Navigation in Graphical Models," Proceedings of the International Conference on Software Engineering, pp.823-826, 2008
[2] R. J. A. Buhr and R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice-Hall, 1995

就在 Java 成為 C/C++ 之外主流 Programming 課程使用語言沒幾年後, 對於 Java 適用性的討論也逐漸開始, 主要以興起的 Scripting Languages 為挑戰對象, 其中又以 Python [1][2] 以及 Ruby [3][4] 為多.

大部分的 Papers 是以 Languages 的特性去論述改為使用 Scripting Languages 的優點, 以及目前使用 Java 對於學生太過複雜等. 不過通常這些特性與實際學習上的影響之間, 有甚麼樣的連結很難說清楚, 而透過問卷對於學生的調查, 通常又受限於問題內容的表達方式, 使得調查結果是否能反應特定的問題有所疑慮.

相較之下我就喜歡 [1] 的說明方式, 利用範例程式碼本身的資訊來比較. 例如一個簡單的 Java Hello World 程式碼其實就暗藏了相當多的 Programming Concepts ( 以下所有圖片取用自 [1] ),


相對來說 Python 的程式碼就比較不具有學生不容易在短時間內理解的資訊 ( 可惜 Paper 沒有直接用一模一樣的程式碼來比 ),


這是很具體的比較, 就我之前當 T.A. 的教學經驗, 其實學生最困擾問題之一是, 在沒有面對任何 Programming Languages 經驗的情況下, 一下子就要弄清楚一段程式碼文字, 裡面一堆不認識的詞彙. 想像如果我們在學英文時是被要求直接看一段英文段落來學, 即便已經知道單字了, 也會是很痛苦吧.

另外在 [1] 中, 也利用一小段落說明 Java 比較適合作為 Second Programming Language to Learning. 基本上我同意這樣的意見, 但是目前似乎在 Python 到 Java, 或是 Ruby 到 Java 之間, 沒有為 Novice Programmer 去探討在 Syntax 以及 Semantics 之間的銜接, 以降低兩個階段之間轉移的 Learning Curve, 同時讓 Student 知道學習不同的 Programming Languages 之間, 可被轉移 (Transferable) 的學習經驗.


References

[1] A. Radenski, " Python First : A Lab-Based Digital Introduction to Computer Science," Proceedings of the 11th Annual SIGCSE Cconference on Innovation and Technology in Computer Science Education, pp.197-201, 2006

[2] Linda Grandell, Mia Peltomäki, Ralph-Johan Back and Tapio Salakoski, "Why Complicate Things?: Introducing Programming in High School using Python," Proceedings of the 8th Australian Conference on Computing Education, pp.71-80, 2006

[3] Robert J. Sheehan, "Teaching Operating Systems with Ruby," Proceedings of the 12th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education, pp.38-42, 2007

[4] A. Ortiz, "Language Design and Implementation using Ruby and the Interpreter Pattern," Proceedings of the 39th SIGCSE Technical Symposium on Computer Science Education, pp.48-52, 2008

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

M. A. Smith 在此篇文章 [1] 中先花了一點篇幅討論 Portal 的定義, 而最終作者所給予 Portal 的定義為 :

An Infrastructure providing secure, customizable, personalizable, integrated access to dynamic content from a variety of sources, in a variety of source formats, wherever it is needed.

基於上述的定義, 作者認為與 Internet OSI Model 其實有相近之處, 故在此篇中是以 Layered Architecture 來建立標題中所述的 Portal Application Framework. 共有七層 Layers, 分為三個 Groups, 分別為 Process Interface Layers ,Resource Discovery Layers, 以及 Network Interface Layers. 下圖有各層的簡要 Description, 更詳細的內容可以看 Paper [1].


但我認為在文章中, 也許限於篇幅, 並沒有深入討論在此 Layered Architecture 之上, 各 Layers 之間透過由 Layers 建構起來的 Abstraction, 得以直接進行 Communication 的行為. 例如 Resource Identification Layer 如何跟另外一個 Resource Identification Layer 進行溝通. 這應該是 Internet OSI Model最重要的特徵之一. 缺乏此敘述, 將會使得各個 Layers 看起來只像是一個 Functional Blocks, 這樣就跟一般的 Block Diagram 沒什麼兩樣了.

同時在 Layers 與 Layers 之間的 Communication 說明也是缺乏. 另外一個問題是, 基於這樣的 Application Framework 所建立的 Portal, 在進行 Deployment 時會有哪些選擇呢 ? 我們在 Network 上有各式的 Routers 或是 AP, 負責了 OSI Model 中數層的工作, 是否對於 Web Portal 而言, 也是會出現類似的概念呢 ? 也許這些問題要到最近幾年的 Conference Papers 裡去找了吧, Magazine 的文章向來比較難以說到細節.

另外也很值得想像的一點是, 既然把此 Layered Architecture 與 OSI Model 對比, 我們是否也可以很合理地想像, 這會變成 Web OS 對應於 Internet Service/Resource 管理使用的一個 Module 呢 ?

References

[1] M. A. Smith, "Portals : Towards An Application Framework for Interoperability," Communications of the ACM, vol.47, no.10, October, 2004

這篇 paper [1] 主要提供了一個對於目前在 Software Engineering Experiments 中, 對於 Theory 使用的檢討之外, 其用來進行的方法, 同時也提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法.

如下圖所示意, 整體概念為自 Software Engineering Experiments 的範疇內, 定出一個 Factors 集合, 藉由串聯這些 Factors 集合, 對於所有目標的 Papers 作討論與分類, 最終結合將這些 Factors 串聯的方式, 以及利用 Papers 所作的驗證, 得到一個 Theory Use Model.


其中有價值的分為三部分. (1) 此 Process 本身, (2) 對於 Factors 進行串連的方法, 以及 (3) 一個呈現出具體成果的 Factors 集合.

此 Process 本身並非創新的提出, 而是一個 Common 的 Process, 但是這篇成功的 Paper 在討論 Software Engineering Experiments 的 Theory 使用上, 展示了此 Process 的合理使用. 自此可預見此 Process 會是往後相關延伸研究的基本 Process 之一.

對於 Factors 進行串聯的方法我認為是最有價值的部分. 往往我們可以列出許多的 Factors, 但是卻不知道怎樣對於 Factors 作取捨以及相互搭配, 主要原因我認為是所立足的基準點 ( Base ) 認識不清楚所致. 而這篇 paper 在整個過程中, 逐步穩固地解釋選擇 Factors 的合理理由, 同時以兩個軸去分析最重要的 Factors. 兩個軸分別是 (1) 對於 Theory Type 以及 Theory Components 的分析, (2) 對於 Theory Role 的分析, 這兩個軸事實上源自於同樣基準點 : 提供往後 Software Engineer 進行 Software Engineering Experiments 可以利用來判斷該選用什麼樣的 Theory 的方法, 換句話說, 跟如何選擇以及如何使用有很大的關係.

最終的部分, 一個呈現出具體成果的 Factors 集合, 我認為比較算是副產品. 除了可以驗證這樣的進行方式之外, 同時也是站在 Theory 於 Software Engineering Experiments 內, 以偏向 Empirical Study 的角度選擇了 Materials 以及相對的 Factors, 同時隨後進行的討論內容進一步證實了此 Factors 集合可以發揮的作用.

About Paper Writing

在 Paper 撰寫上我認為此篇 Paper 採用較為平鋪直敘的寫法. 首先在 Introduction 就說明問題, 以及本篇 Paper 所謹守的研究範圍. 接著承接研究目的及範圍, 說明上述的兩個主軸. 兩個主軸剛好對應到 Theory 本身的特性分析 ( Theory Type ) , 以及使用上的分析 ( Theory Role ), 因此分析立論一開始的空間感就很充足, 為之後的 Findings 解釋立下很說服人的基礎.

Section 3 說明此次 Review 的 Data 來源, 以及 Extract Data 的方法及原則. Section 4 則反向說明 Findings. 這裡的反向是指, 先從看完第三段後, 讀者可能會比較直覺想到的 Articles 與 Theories 之間的關係說明起, 再往回接到 Theory Roles 以及 Theory Types, Theory Components.我認為這樣寫的好處是不容易有文章閱讀上的斷點產生. 而後 Subsection 4.4, Subsection 4.5 則回歸到對於 Theory 出處以及所列為觀察的 Paper 之 Authors 之間, 對於 Theory 使用的分析, 我認為這邊事實上是回映到 Background 一開始的敘述. 回頭來稍微探討以 Theory 使用的觀點, Software Engineering 是否算是一個 Mature Science. Section 5 就以 Theory Use 為中心, 探討各項 Issues, 但是這邊我還看不出什麼 Regulation, 例如怎樣列出這些 Issues 之類的.

Remained Questions

• Paper 中提到, 對於所觀察的 Papers 選擇是自 1993 到 2002, 是否有特殊的理由 ? 或僅僅是因為 Time 以及 Effort 的考量而作此決定 ? 是否與 Empirical Study 的數量歷年增加比率有關 ?
• 本篇 Paper 本身是否也算是利用了 Role Theory ?
• Figure 1. 中, 左右的順序之意義為何 ?
• Figure 1. 中, Experiment 與 explain 所涵蓋的範圍是一樣嗎 ? 又所涵蓋的範圍應該怎樣解釋其意義. 同時 Theory 所涵蓋的範圍以及意義又是如何 ?
• 最後的 Section 5. Discussion 是否有任何的 Regulation 存在 ? 往後進行相似的 Researches 時, 應該怎樣進行 Discussion ?
  

References

[1] Jo E. Hannay, Dag I.K. Sjøberg, and Tore Dyba°, "A Systematic Review of Theory Use in Software Engineering Experiments," IEEE Transactions on Software Engineering, vol.33, no.2, pp.87-107, Feb. 2007

此篇文章以台大本身所建立的 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