測試與正確性論證

　　正確性論證:基于理論的,通過邏輯上證明程序的正確性.

　　好處:

　　　　測試不能包括無限的全集,但是通過正確性論證可以取到所有的數據情況,來從理論上證明程序的正確性

　　缺點:

　　　　不能嚴格保證程序的正確性,完全可能出現理論正確但實際上卻有實現錯誤的情況出現,正確性論證不能保證程序的實際正確性.理論論證過程較麻煩,其中可能出現邏輯錯誤而不自知,正確性論證較復雜,論證過程的正確性也難保證.

　　測試:通過給定,自己構造的數據集對程序進行測試,要求各種數據下都能輸出對應的正確結果.

　　好處:

　　　　能夠直觀的判斷程序的好壞,能夠通過測試直接來發現bug修改,測試能夠保證在大多數據情況下的正確性.

　　缺點:

　　　　測試不能包括所有的數據,所以測試并不能保證程序的完全正確性,完全可能存在邊界情況,特殊情況的錯誤.同時測試數據的來源不定,對于任一組測試數據,其對應的正確輸出也需要考量.

　　總結:

　　　　兩者各有千秋,在對于判斷程序的正確性上,一個處于理論另一個處于實際,兩者的功能有互補的地方.

OCL和JSF

　　ocl的作用在于對設計的對象進行約束，且保證不存在二義性。

　　jsf的作用是對目標類和方法的功能進行約束,要求變量滿足不變式,程序依照需求,改變,結果.

　　兩者約束的"力度",條件各不相同.可以把jsf認作為輕量級的ocl.

第十四次作業

　　作業類圖:

　　時序圖:

　　狀態圖:

學期總結

四個單元模塊知識點之間的關系

第一個單元是基本的java程序編寫,從零開始認識java,編寫一些單線程的程序,加強對于面向對象的編程習慣,掌握類屬性方法等元素以及繼承、多態等OO的基本思想.

第二次單元是基本的多線程,引入并行的概念,編程時候要做好同步.

第三個單元注重的是jsf,關于代碼規格的問題,

第四個單元是代碼的正確性論證和測試.

個人收獲與小結

個人以前沒有接觸過java,以前寫過的代碼也僅限于c/c++/python等,但都只是單線程的,面向過程的編程方式.

我覺得最大的收獲是學會了,熟悉了面向對象的編程思維方式,把結構作為對象,同時,還學習到了多線程的編程方式,

對于代碼注釋,規格的編寫,還有完成后的測試.從寫代碼的思想和方法到編寫完成后的測試和交互都有所成長.

對工程化開發的理解

感到工程化的主要目的是,把一份大的作業(工程)分成多個小塊,讓不同的人去完成自己的這一塊,所以良好的封裝和規格的書寫,很利于

同事之間的交互.特別是在代碼比較復雜,功能強大,代碼量大的時候,很難讓一個人去把這些代碼全都融會貫通,只是把這些當做一個個對象進而統一規劃.

要做好的話,首先要保證自己代碼的可靠性,在此之上,要保證代碼的可閱讀性(規格和注釋等)

對課程的期望和建議

這門課收獲很多但也有讓人不大舒服的地方,很突出的特色就是互測吧,其實互測能給人帶來的進步確實不小,獨立的代碼測試能力,對于"客戶""測試者"之間角色的溝通交流問題,

但是個人感覺機制并不夠完善,如果你互測的成績能夠保證百分之七十由你的實際代碼好壞決定,那我覺得是十分不錯的.但是實際上,你的分數往往掌握在你的對手和你的測試對象上,

好的代碼可能不一定能有好的分數,也確實存在部分很惡心人的現象,為了拿分不擇手段,公測全掛互測,私下交易,認定的錯誤該報一個的情況報了許多個.同時有些同學交流的時候說話

方式十分不禮貌,對別人的代碼表示鄙視,看低別人的能力,可能會引起爭吵.

但不否認,遇到不錯的測試對象,也是十分舒適的交流習慣,大家幫忙測試對方的bug并且交流,自己有得有失,互相幫助完善自己的代碼能力和思維能力,最后大家互相道謝也是很好的情況.

給出的具體建議:

　　公測的比重建議加重,有許多作業公測點太少,全看互測來決定.希望起碼公測能起到判定一個代碼基本好壞的程度.