最近看到Kent Beck與Martin Fowler講的一句『諺語』,說:"Stick with simple tool, like pencil, paper, and whiteboard. Communication is more important than whizbang." 我才想到PO這篇短文,提供學生們(至少選我開授的OOSE的學生)參考。這句諺語我認為最重要的是『溝通』,溝通在軟體發展的過程中十分重要,尤其想使用『敏捷方法』發展軟體的工程師們更為重要(可參考Agile Alliance在2001年發表的『宣言』(manifesto),此地不宜對宣言多做闡述),問題是你要使用何種工具或方法來溝通?我想除use cases外,CRC cards可能是最佳工具之一,它是隨時隨地可得的低技術工具,易學易用。 軟體開發與維護時,工作夥伴的合作十分重要,換言之,團隊合作是發展工作成敗的關鍵,夥伴合作必須有好的工具或技術協助,CRC cards可能是適當的工具之一,據我所知,在台灣發展軟體的工程師很少使用像CRC cards這種簡單但被認為是一種『驚奇』(wonderful)的發明 (David Bellin, et al. 1997),而這種技術雖然簡單,但卻可避免發展早期陷入太細節或者產生雜亂且定義不清楚的類別,因此希望這篇報導能引起從事軟體發展的人士注意到這種『老而彌堅』的技術,而且也希望各界人士能予指正。 CR C cards (Class-Responsibility-Collaborator cards) 是1989由Kent Beck與Ward Cunningham所共同介紹 (http:\\c2.com/doc/oopsla89/paper.html), 其出現時期與WWW相同,至今約有20幾年的歷史,這個工具開始是用來教導新學員如何學習物件導向的觀念與程式製作,後來的演變卻超乎在教室內的需要,而成為軟體分析、設計以及敏捷思考的工具。CRC cards的軟體發展方法屬於一種非正規方法 (informal approach),雖然屬非正規方法,但CRC cards可做為正規方法的輸入或前端作業,如Booch方法、James Rumbaugh, et al. 的OMT、Ivar Jacoson, et al.的OOS...
同意~ 先從抽象層及架構教起,再去教導程式撰寫的細節
回覆刪除黃教授的觀點,我們(北科大)在OOAD(碩一下)一門課中實施。多年來陳偉凱教授與我以約略相同的模式進行這門課程。課程含一個專題,由學生大致依循unified process從提出問題、分析problem context、撰寫需求(use cases and nonfunctional requirements)、conceptual modeling and design modeling(使用UML)、test plans等、寫程式、demo等,並以2~3個iteration完成。
回覆刪除由於時間的關係,OOAD並未涵蓋MDA相關工具與議題。因此,學生仍需『手動』將OO model翻譯成C++ 或Java程式。說起來仍脫離不了coding。
OOAD的課程,是在學生修完pattern oriented software design(碩一上,必修)之後進行。這門課涵蓋GoF 23 個 patterns中15~20個patterns,學生需要做完一個規模大約2000~3000行的程式。如果以pattern數來算,大約涵蓋4~6個patterns(每年因作業題目有不同)。
關於這兩門課程最近開課的相關資訊,請參考陳偉凱教授網頁http://www.cc.ntut.edu.tw/~wkchen/courses/ooad992/index.htm與
http://www.cc.ntut.edu.tw/~wkchen/courses/gposd991/index.htm
我的看法與郭譽伸教授接近,modeling與coding並非競爭關係,而是合作關係。以前述二門課程的設計而言,modeling始於POSD而應用於OOAD。
另外,如MDA方式產生程式,勢必在OO Models上需要更為嚴謹,且需有適當地工具可用。
雖與OO Modeling無直接關係,近來我曾多次與陳教授討論改以Scrum作為流程框架,但這個規劃需進一步探討。
「課程改進」我認為是一項嚴肅的議題,我很敬佩北科大陳偉凱教授早就對這個議題所做的努力,我提出這個議題並非否定學生學習coding的重要,而基本概念是讓學生學習軟體發展技術由modeling入門,也許這樣學生才不會只成為「coding匠」,也不至於如Q43諺語所說的那麼「淒慘」,而提升分析、設計、‧‧‧的能力。
回覆刪除至於MDA,如果觀察Grady Booch等人提出的MDA Manifesto(見The MDA Journal一書)包括Direct Representation, Automation, Open Standards,其中Automation一項直接與Agility相關,所謂Agile MDA,Agile MDA的基本觀念是code與executable models相等,我不擬在此多討論MDA,只不過訓練學生發展軟體似應由modeling入門。
如果這個議題值得討論,我建議軟工學會提供討論的機會。
北科大的陳偉凱及鄭有進(漏提,抱歉)教授對OOAD課程的努力似與本人想法有出入,而且北科大的課是針對碩一學生所開授,我的提議是針對大一的計摡或大二軟工的入門課程而言,這個提議可能會有點爭議,因為可能有「顛覆」傳統的嫌疑,所以才要討論。
回覆刪除我想補充一些我個人的想法。首先,就我個人觀察,目前就業市場似乎仍然需要大量的programmer寫code,而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』,而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗,更遑論良好的架構了。我覺得這樣的code,即使可以動,也不能算是「好code」,當code需要維護時一定會造成很大的困擾。因此,我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗,以指導學生寫「漂亮的code」,將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立,如果使用MDA以及code generation的機制,問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海,應該更能培養Modeling能力,比較不會被code牽著走。舉例說,一般大學部OOP的課多著重於程式語言的文法與演算,反而少了物件模型、互動、UML,更遑論設計樣式,在這種情形下,就算會寫code,也不會很OO,而這些東西如果等到高年級(甚至研究所)的OOAD再學,似乎又嫌晚了。暑假期間,個人參與軟體工程課程模組教材編撰,則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介,希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程,增加MDA或其他modeling的教學,我覺得也是可行的。但是,我並沒有很明確的idea,不知道黃教授有沒有什麼構想?
我想補充一些我個人的想法。首先,就我個人觀察,目前就業市場似乎仍然需要大量的programmer寫code,而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』,而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗,更遑論良好的架構了。我覺得這樣的code,即使可以動,也不能算是「好code」,當code需要維護時一定會造成很大的困擾。因此,我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗,以指導學生寫「漂亮的code」,將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立,如果使用MDA以及code generation的機制,問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海,應該更能培養Modeling能力,比較不會被code牽著走。舉例說,一般大學部OOP的課多著重於程式語言的文法與演算,反而少了物件模型、互動、UML,更遑論設計樣式,在這種情形下,就算會寫code,也不會很OO,而這些東西如果等到高年級(甚至研究所)的OOAD再學,似乎又嫌晚了。暑假期間,個人參與軟體工程課程模組教材編撰,則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介,希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程,增加MDA或其他modeling的教學,我覺得也是可行的。但是,我並沒有很明確的idea,不知道黃教授有沒有什麼構想?
我想補充一些我個人的想法。首先,就我個人觀察,目前就業市場似乎仍然需要大量的programmer寫code,而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』,而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗,更遑論良好的架構了。我覺得這樣的code,即使可以動,也不能算是「好code」,當code需要維護時一定會造成很大的困擾。因此,我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗,以指導學生寫「漂亮的code」,將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立,如果使用MDA以及code generation的機制,問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海,應該更能培養Modeling能力,比較不會被code牽著走。舉例說,一般大學部OOP的課多著重於程式語言的文法與演算,反而少了物件模型、互動、UML,更遑論設計樣式,在這種情形下,就算會寫code,也不會很OO,而這些東西如果等到高年級(甚至研究所)的OOAD再學,似乎又嫌晚了。暑假期間,個人參與軟體工程課程模組教材編撰,則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介,希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程,增加MDA或其他modeling的教學,我覺得也是可行的。但是,我並沒有很明確的idea,不知道黃教授有沒有什麼構想?
我想補充一些我個人的想法。首先,就我個人觀察,目前就業市場似乎仍然需要大量的programmer寫code,而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』,而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗,更遑論良好的架構了。我覺得這樣的code,即使可以動,也不能算是「好code」,當code需要維護時一定會造成很大的困擾。因此,我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗,以指導學生寫「漂亮的code」,將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立,如果使用MDA以及code generation的機制,問題自然就消失了。
回覆刪除我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海,應該更能培養Modeling能力,比較不會被code牽著走。舉例說,一般大學部OOP的課多著重於程式語言的文法與演算,反而少了物件模型、互動、UML,更遑論設計樣式,在這種情形下,就算會寫code,也不會很OO,而這些東西如果等到高年級(甚至研究所)的OOAD再學,似乎又嫌晚了。暑假期間,個人參與軟體工程課程模組教材編撰,則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介,希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程,增加MDA或其他modeling的教學,我覺得也是可行的。但是,我並沒有很明確的idea,不知道黃教授有沒有什麼構想?
由於陳偉凱教授回應本文時遭遇一些困難,故由我代post:
回覆刪除===
我想補充一些我個人的想法。首先,就我個人觀察,目前就業市場似乎仍然需要大量的programmer寫code,而我在TCSE Panel Discussion中拋出code的議題是因為常看到「學生寫出『不好的code』,而學生自己卻不以為意」。有些比較差的code甚至連最基本的「對齊」、「變數命名」都弄得一蹋糊塗,更遑論良好的架構了。我覺得這樣的code,即使可以動,也不能算是「好code」,當code需要維護時一定會造成很大的困擾。因此,我的原意是徵詢Panelist或在場的先進是否能分享這方面的教學經驗,以指導學生寫「漂亮的code」,將來就業時也會比較有競爭力。這個議題的有效範圍當然只有在「必須寫code」的時候才成立,如果使用MDA以及code generation的機制,問題自然就消失了。
我贊同黃教授提議讓學生在學習軟體技術時由modeling入門的觀念。我覺得Modeling的觀念如果能儘早進入學生的腦海,應該更能培養Modeling能力,比較不會被code牽著走。舉例說,一般大學部OOP的課多著重於程式語言的文法與演算,反而少了物件模型、互動、UML,更遑論設計樣式,在這種情形下,就算會寫code,也不會很OO,而這些東西如果等到高年級(甚至研究所)的OOAD再學,似乎又嫌晚了。暑假期間,個人參與軟體工程課程模組教材編撰,則希望在大學部的OOP課程中加入6-9小時對於這些元素的簡介,希望早一點引進modeling的觀念。
對於調整大一計概或大二軟工課程,增加MDA或其他modeling的教學,我覺得也是可行的。但是,我並沒有很明確的idea,不知道黃教授有沒有什麼構想?
由 陳偉凱 於 2011年7月25日下午5:08 張貼在 輕鬆談軟工
===
我很感謝北科大的鄭有進與陳偉凱兩位教授對於這個議題的興趣與意見,同時也敬佩他們訓練學生撰寫好程式的努力,我未曾教過學生如何寫程式,也許不太了解教學生寫程式的困難,但我並非忽視這件事,我只不過提議教學生寫程式之前教一些modeling的觀念與技術,也就是:modeling → programming的程序,採用這種教學程序,將來學生寫的程式可能比較容易保養,建構容易保養的軟體是很重要的事,例如早讓學生懂得應用一些design principles或design patterns,這樣可能可以讓發展的軟體易於修改與擴張,軟體也比較有「彈性」,我的想法在於此,至於是否使用MDA或code generator,應該是另一議題。
回覆刪除我舉兩種範例參考。1989年Kent Beck與Ward Cunningham在OOPSLA'89介紹CRC cards時,主要目的是要提供一種工具以教授學員OO想法,這些學員也許無OO概念,但可能撰寫程式經驗豐富,沒想到CRC cards後來移出教室變成分析與設計的「天才工具」(Nancy M. Wilinson)(註:雖然這項工具已有二十幾歲,但仍然「老當益壯」,據我所知台灣很少人重視它,也很少用它),我想這是modeling → (OO)programming的範例。另外一則例子是Georgia Institute Technology的K.A.Gray, et al.等教授發表一篇他們的教學經驗:"Extending CRC Cards into a Complete Design Process",其基本觀念是:Scenarios → CRC Cards → Code,前半段是modeling,或許可以說由modeling入門再到coding,至於是否必須使用CRC cards技術,則另當別論。
如果說大一或大二的課程增加MDA或許不必,雖然OMG說MDA是他們的「標準」軟體發展方法,而且前途「光明」,但是引進入大一課程,我想大可不必,因為裏面有一些標準與技術並非大一甚或大二學生容易了解。至於教modeling方式很多,也許早一點教學生UML,以及如何使用它以表達OO觀念與設計,可能可以考慮。
這個議題蒙鄭、陳兩位教授以及TCSE Panelists討論過很多,我想已很清楚,我只不過主張提升教學「抽象層次」而已,至於是否得當,見仁見智,也許其他人士另有看法,值得討論。
我想再補充一下。簡而言之,這兩年我在大二OOP一門課中,也嘗試以Class-Responsibility-Collaboration(CRC)法,讓學生做一些簡單的modeling。相關的理念發表在TCSE 2010(中央大學),我將該paper『融入軟體工程實務於物件導向程式設計課程)』的introduction摘錄於後,全文pdf可自我的網頁下載(http://www.cc.ntut.edu.tw/~yccheng/papers/tcse2010_OOP.pdf)。
回覆刪除==
大二物件導向程式設計(Object-oriented Programming)課程,是資工系學生第一次接觸到物件導向觀念與程式語言語法的機會。學生在這門課中需學會物件導向的重要元素如封裝(encapsulation)、資訊隱藏(information hiding)、繼承(inheritance)、多型(polymorphism)、泛型(genericity)等技術;這些技術普遍被認為適用於開發具規模的中大型軟體,透過妥善的物件導向設計,程式可被賦予適當的耦合度(coupling)、內聚度(cohesion)、可修改性(modifiability)、 與可維護性(maintainability)。雖然這些物件導向技術構為軟體的構成提供一個良好的基礎,但要開發一個好的軟體,則需要更多的軟體工程技術。在北科大資工系大二物件導向程式設計課程中,我們嘗試在固有的物件導向相關議題之外加入工作規劃(work planning)[4]、單元測試(unit testing)[5]、重構(refactoring)[6]、例外處理(exception handling)[7]等當前普遍受軟體工程界重視的幾種軟體工程實務(software engineering practices)。我們以George Polya著稱於世的How To Solve It解題方法(problem solving)中所揭櫫的的四個步驟,即瞭解問題(understand the problem)、規劃解法(devise a plan)、依規劃解題 (carry out the plan)與回顧(look back)等四個步驟[1],作為導入軟體工程實務的框架。在瞭解問題之後,以物件-責任-合作(class-responsibility-collaboration, 簡寫為CRC)的物件導向設計法[2]列出物件及其方法,並將實做每個方法的工作當作一個待辦工作;這些待辦工作被列管於一個簡單的工作庫存表(task backlog)。此外,工作庫存表亦包括方法的程式碼與測試程式的撰寫,以及其他相關工作。在單元測試的撰寫上,我們採用xUnit單元測試框架。在此作法下,每一個程式撰寫(coding)的工作的完成(done)變得極為清晰;亦即所有單元測試都必須獲得通過,才認定該工作依規劃執行結束。最後,在每一個物件的實做告一段落時,以檢視程式的設計進行回顧,指出問題點,作為下一個解題循環的工作規劃參考,如有找出明確的工作則將之列入工作庫存。整個程式設計的工作在工作庫存中的工作完全去化之後宣告完成。
在一個學期中,我們至少在課堂上以How to solve it的框架完成三到四個完整的程式設計範例,並讓學生以同樣的模式完成八到十個程式作業。在這個過程結束後,學生不僅寫完物件程式碼,亦進一步獲得單元測試碼、工作規劃、工作庫存去化紀錄等產出物。在完成本課程後,學生將能具備足夠的物件導向程式設計基礎,修習大二下的物件導向程式設計實習,目標是在應用框架(application framework)下撰寫一個規模約為2000~3000行的2D的互動遊戲[3]。
==
過去兩年的OOP的實施上,我只花了一堂課談CRC,學生應當只知道皮毛,遠遠不足。事實上,我非常認同黃教授modeling first 的見解,因此,下學期我打算以2~3堂課談CRC,並讓學生有機會在課堂/作業中練習。不知道軟工教育界的先進們,有無實施CRC的經驗可供借鏡?
鄭教授既然談到CRC cards用於北科大的教學,我想針對CRC cards簡單說幾句話,我希望有機會寫一篇文章比較詳細介這種有趣,但在國內不太引起注意的工具,或稱之為方法。
回覆刪除話說,有人問發明Responsibility-Driven Design(RDD)的Rebecca Wirfs-Brock:CRC cards是否有用,為甚麼UML工具並不將其納入,她的回答是:CRC cards大部分是用來做訓練,有時也用來做分析與設計,至於UML工具不將其納入,是因UML工具並不支援模式原素在各種抽象層次(level of abstraction)的behavior 與characteristics的描述,所謂抽象層次可以很多,不過依照Martin Fowler的說法,你的設計抽象層次包括:conceptual view,specification view,以及implementation view,而CRC card的層次對conceptual view 的描述最佳,這個view主要是描述所謂key abstractions(構成問題範疇部分字彙的類別或物件),事實上,其貌不揚的CRC cards,其功能恐不止於此,可以用來發展軟體,其程序大致如下:(Use Case Model + UI Prototype) → CRC Model → Class Model (以上是Scott W. Ambler的說法,我加上 "→ Code")。我在TCSE2010投了一篇小文章,名為"From CRC Cards to MDA: A Software Development Process",主要精神是要顯示,Informal的CRC cards可以作為Formal Methodology的input,似與Wirfs-Brock說法有些吻合。我覺得鄭教授團隊使用CRC cards大慨止於訓練之用,並未將其導入implementation(coding)的層次。
抱歉打擾,文章回覆的行距實在太窄了,很難閱讀,不知道能不能調整一下? 設定 line-height: 1.4em; 就好的多。
回覆刪除