測試和論證都是驗證程序正確性的方法。git
測試是在一組測試用例上執行一個程序,並將實際結果與指望結果進行比較以揭示錯誤的存在,但不會精確地揭示錯誤所在之處。若是可能輸入的集合很小,進行完全的測試時可能的,但若是輸入集合很是大,則完全的測試時不可能的。測試的優勢是易於實施,工程廣爲採用,缺點在於其不能徹底確保程序的正確性。編程
論證針對格式化的規格和代碼實現,人工方式對代碼邏輯進行分析,確認是否正確。論證能夠對代碼進行全面地分析,能夠肯定錯誤的存在範圍。論證是形式驗證與天然語言層次邏輯推理的結合,缺點是沒法確保天然語言層次邏輯推理的嚴謹性。安全
UML圖表例如類圖可用於描述規格,但還不足以描述規格的所有內容。對象建模中須要描述對對象的約束條件,一般用天然語言來描述。因爲天然語言老是有二義性的,人們就使用無二義性的形式化語言,形式化語言對數學要求較高,對普通的從業人員來講有必定難度。OCL就是在這樣的背景下誕生的,OCL也是形式化語言,但它易於閱讀和編寫,而且語義清晰。微信
1) 初步認識面向對象程序的結構特色併發
2) 區分過程式程序與面向對象程序在結構上的主要差別gitlab
3) 初步認識面向對象程序的運行行爲和調試學習
4) 初步認識輸入處理與程序魯棒性的關係測試
5) 初步掌握結構化輸入的處理技巧網站
1) 如何把程序功能「均衡」分配給多個類spa
2) 如何讓多個類之間進行協同
3) 初步熟悉基於隊列的調度
1) 進一步理解調度邏輯及其設計
2) 開始掌握如何使用繼承構造邏輯處理層次
3) 進一步訓練類的均衡設計
4) 開始瞭解針對狀態的測試設計
1) 理解和實踐線程交互
2) 線程交互模式識別
1) 識別程序併發特徵
2) 實踐線程的主從協同模式
3) 基於鎖的線程同步設計
4) 實踐線程安全設計
5) 使用代碼進行測試
1) 實踐面向對象分析
2) 認識和實踐線程交互的動態性
3) 實踐線程工做狀態控制
4) 實踐設計原則
5) 繼續實踐線程安全設計
1) 熟悉過程規格的內涵和書寫
2) 初步實踐基於規格的方法實現
3) 實踐基於異常處理的防護編程
4) 初步實踐基於過程規格的測試設計
1) 熟悉類規格的內涵和書寫
2) 實踐基於規格的類實現
3) 實踐契約式設計方法
4) 初步實踐基於類規格的測試設計
1) 實踐類型層次下的規格設計
1) 設計測試數據
2) 設計測試場景
3) 基於規格設計測試
1) 軟件正確性內涵
2) 類實現的正確性論證
3) 方法實現的正確性論證
4) 子類實現的正確性論證
每次做業的關鍵要點用藍色粗體字標出。
第一單元(1-3)初始面向對象,掌握類、繼承等基本概念,練習均衡設計、類間協同。
第二單元(5-7)掌握線程設計、線程安全以及設計原則。
第三單元(9-11)學習規格設計的方法。
第四單元(13-14)練習程序測試、程序正確性論證。
每一個單元的知識點相對獨立又相互聯繫,例如第四單元的代碼測試,在前三個單元都有所涉及,又如第二單元設計原則,在第一單元的均衡設計部分有所體現。四個單元內容井井有條,按部就班,從開始的面向對象基礎,到進階的線程設計,再到更高層次的設計原則與規格化設計,最後到程序的測試與論證,構成了一個統一的體系。
在設計上,一開始毫無頭緒(很慶幸作第一次做業時看到了教材上的部分代碼),後來漸漸地可以理清要求,尋找出其中的對象,對象間的關係。測試上,最初是想到什麼測什麼,沒有邏輯,後來可以按照分類樹劃分輸入,分類測試。
做業上我以爲能夠有一次獨立的規格設計做業,從設計,編寫規格,到實現做爲一個完整的過程。 第九、十、11次做業是在已有實現的基礎上補充規格或者增長新的方法和規格,若是有一次一開始就用規格化設計的做業,也許能加深對規格化設計的理解。
每次做業的答疑若是能統一就行了,如減弱微信羣的答疑功能,只在gitlab網站上答疑,而且對做業發佈後的變化用單獨的一個版塊來更新。否則,同窗們既須要關注微信羣,又要閱讀全部的答疑帖才能知道做業要求的改變,耗費時間精力。
除了講課和做業的制定上,老師能夠參與更多,例如在gitlab上答疑等。「OO不易,和諧6系」這句話可能蘊含着一種較強的對立關係,若是老師的更多參與可以給同窗以引導,更多關注學習自己,而不是如何團結起來應付課程組,或許有更好的效果。
若是有同窗與老師或助教的面對面答疑時間就更好了,這樣對同窗和助教的能力應該都有提高。