面向對象課程第四次隨筆

1、測試與正確性論證

　　測試主要是對產品進行檢查和測試，及時地發現程序中的故障和邏輯錯誤，以保障程序的可靠性。測試能夠分爲許多種類。測試能夠爲黑盒，也能夠經過程序的邏輯結構進行白盒測試。經過測試用例來構造的測試，只能證實程序有錯，不能證實程序無錯。

　　正確性論證是從理論上對程序的正確性進行論證，經過證實能夠得出程序邏輯上是否正確。在許多狀況下，一個徹底的形式證實多是沒必要要的。在某些狀況下，若不能實現徹底測試，則也不可能實現徹底的形式證實。然而，咱們經常用程序正確性證實所開發的推理風格來指導測試過程，以加強對程序的信任,有時能夠把某些性質的程序證實和其餘性質的測試結合起來。

　　測試的門檻相較於正確性論證是比較低的。若是是進行黑盒測試，你能夠經過劃分等價類等手段覆蓋化測試，若是是白盒測試，則能夠經過對程序結構分析構造相應的測試數據。測試自己是一種很是直觀的判斷正確性的方法。而正確性論證自己難度比較高，不少時候難以論證。對比較大的程序，正確性論證也會很是複雜。當測試沒法覆蓋一些部分時，能夠考慮使用正確性論證做爲輔助與補充。

2、OCL語言

　　OCL（對象約束語言）語言是一種形式化，無二義性語言，它主要用於表示UML模型中施加於模型上的約束。一個約束就是對一個（或部分）面向對象模型或者系統的一個或者一些值的限制。UML類圖中的全部值均可以被約束，而表達這些約束的方法就是 OCL。OCL起源於1997年BIM公司爲響應OMG的"面向對象分析和設計標準"徵求稿所提交的"對象時間限制提議"，OCL是該提議的部份內容。 用OCL能夠描述四類約束，分別是不變量、前置條件、後置條件和監護條件。

與JSF的異同

　　類似之處：都用於表示面向對象中對模型的約束，都具備不變式，前置條件與後置條件。

　　不一樣之處：（1）OCL語言是基於數學基礎的，沒有二義性，不會像JSF同樣容易產生歧義

　　　　　　　（2）OCL語言沒有JSF中的MODIFIES，相應的，有一個監護規則，是對象可以從一種狀態轉變爲另外一種狀態前其值必須爲真的約束。

3、UML圖

4、順序圖

5、UML狀態圖

6、總結

一、四個單元模塊知識點之間的聯繫

　　四個學習單元相互聯繫。第一個單元主要介紹面向對象的基本知識，如繼承、多態、接口等面向對象基本知識與概念。第二單元學習了面向對象的一個重要應用，多線程編程，學習了多線程的基本模型，更加熟練了類的交互。第三單元介紹了程序的規格，學習如何先設計程序之處儘可能保證程序的正確性與規格化。第四單元主要着眼於測試與論證，經過單元測試與形式化論證來證實程序的正確性。

　　第三個單元所介紹的規格化設計與第一二單元是相互關聯的，在進行設計之初，咱們就要着眼於線程安全，繼承接口等設計，固定好規格。第四單元的測試與論證也是基於類和方法的規格來的。

二、本身設計、測試和質量的進步

　　這一個學期經過OO課程的學習，我對程序的設計能力確定是有顯著提升。最開始我不能很好地理解面向對象思想，設計的程序也比較亂。在進行多線程編程後，我真正認真學習了必定的設計模式，本身在寫做業以前也對程序進行了設計，代碼質量有了顯著提升。

　　測試方面，本身第一次進行了單元測試與正確性論證。雖然在以前也知道相關知識，但幾乎一直在採用覆蓋化測試。對測試程序有了系統化的理解，會對一些薄弱單元進行分析以後構造相應的測試用例進行測試。

三、工程化開發的理解

　　（1）工程化開發意味着程序體量很大，程序人員或許比較多。不進行系統化設計，規定好規格，可能致使程序各個部分的交互出現錯誤。

　　（2）工程化開發要求程序有容錯率與報錯機制。設計好程序的錯誤處理對後序的檢查十分有幫助。

　　（3）程序要有可移植性與可維護性。代碼要儘可能簡單易懂，設計上須要考慮代碼是否具備廣泛性，是否是容易更新換代。

　　（4）工程化開發的程序要進行動態測試，靜態測試，正確性論證等各類測試，來保證正確性。

四、對課程組的建議

　　（1）面向對象基本知識介紹的太少。咱們只有三節課的時間來介紹繼承，抽象，接口和多態等面向對象最重要的概念。這些概念的熟練運用也須要經過讀代碼，寫代碼來實現。課程對面向對象的介紹實在太少了。

　　（2）最後對於規格介紹和測試徹底能夠從新寫一份代碼，從頭開始。我認爲補充前面寫過的程序的規格是十分不對的，先寫代碼再寫規格徹底是本末致使。並且，剛開始學習時，寫出的代碼質量也不高，對這樣的代碼寫規格，作測試很是痛苦。我認爲能夠考慮從設計，寫規格，寫代碼，測試，論證的流程再從新完成一份做業，這樣或許更能體現規格設計的優點。