OO Summary Ⅳ

測試與正確性論證的效果差別

        測試，或者說用斷言進行黑箱測試，用大量的數據進行「覆蓋性測試」，目的是當分支覆蓋率達到100%也就是理論上來講全部可能的輸入都已經測試過了，而輸出結果均是正確的，那麼咱們理論上能夠說這部分程序是沒有問題的。這種測試方法的好處就是，問題暴露得十分明顯，某一組數據錯了，就知道問題發生的狀況是什麼了，復現性也很強。其實平時咱們本身debug的時候用的就是這種方法，只不過那時咱們測試量比較小，並無作到全覆蓋，而是向着咱們感受可能會出錯的方向進行測試，致使測試之後仍然感到不安，懼怕仍然存在着某些bug本身沒有發現。如今有了全覆蓋的測試，這種方法比較好實現，效率也比較高，只是不能夠徹底驗證程序邏輯的正確性。

        正確性驗證，就是經過分析需求寫出正確的規格，而後論證程序在規格的任意劃分下，都符合規格所要求的過程。這種驗證方法偏向於驗證程序的思路、邏輯是否正確。嚴格按照這種方法執行，能夠驗證程序是否有按照咱們所但願的那樣執行，但因爲是理論上的分析，因此須要嚴謹細緻的推論，所以可能會比較耗費時間。

        不管是這兩種哪種測試方法，都讓我學會了如何準確性較高的測試本身的程序（發現更多的bug），都使我受益不淺。

---

 OCL語言和JSF規格的對比

        對象約束語言，即OCL語言是一種形式化語言，它主要用於表示UML模型中施加於模型上的約束。OCL具備以下特色：

一、OCL是一種精確的，無二義性的語言。

二、OCL是一種規範說明性語言，全部有關實現的問題都不能用OCL來表達。

三、OCL是一種純表達式語言，它是具備沒有任何反作用的申明性語言。

四、OCL是一種類型化語言，即OCL中的每個表達式都是具備類的。

五、OCL不是一種程序設計語言，不能用OCL編寫程序邏輯和控制流程。

        它和JSF規格的相同點在於它們都是形式化的約束語言，在程序中唔二義性，結構上也具備類似性，OCL主要包括的不變量，前置條件，後置條件，監護規則分別對應JSF對應着repOK()，REQUIRES，EFFECTS和MODIFIES。

        他們的不一樣點在於做用的時間不一樣，OCL主要是在編寫程序前，理論建模時刻對每一個類進行明確的約束，而JSF主要在功能實現前進行約束以確保程序邏輯實現正確。

---

 第十四次做業模型圖

1. 類圖

2. UML時序圖

3. 狀態圖

---

課程總結

1. 四個單元模塊知識點之間的關係

        第一章的多項式計算和傻瓜電梯，主要是爲了使咱們從面向過程編程轉變到面向對象編程，在寫代碼的過程當中體會面向對象的思想。

        第二章主要是線程安全的學習，引入線程的概念，運用多線程來提升工做效率，同時也就引入了線程安全的問題，如何保證進程互斥和資源共享是咱們本章須要思考的問題。

        第三章主要是抽象和規格化設計，經過寫規格來加強代碼的可讀性、可移植性，讓咱們寫的代碼能夠爲他人所用。

        第四章是測試與論證，隨着程序規模的逐漸增大，人工測試難以保證程序的正確性（其實哪怕程序規模小人工測試也很難徹底覆蓋），因此不管是自動化測試仍是正確性論證，都是爲了經過理論層面論證程序的正確性。

2. 梳理與進步

        程序確定是寫得比之前好不少，不管是在程序結構仍是可讀性上，從一開始的數量少但功能賊多的類（GOD類）到一點點每一個類的功能相對均衡，各個類可擴展的空間也多了很多。可讀性上，命名風格向大佬們學習基本也能作到精簡且明晰，同時也按照課程要求寫了詳細的JSF（雖然有些仍是很長很長很長很長），可讀性改觀了許多。

        測試方面，從一開始的只能靠亂想例子，寢室共享一波數據，到如今的覆蓋性測試，還有正確性論證，使得測試的過程更加有條理，結果更加可信。

3. 對工程化開發的理解

         emmmm工程化開發就是不少不少不少人一塊兒寫代碼，因此本身寫的代碼就會被本身的隊友所使用，所以本着「以人爲本」的思想，咱們就要讓本身的程序能夠很方便的被別人使用，就像一個很標準的、契合的齒輪，能夠幫助整臺機器運轉，與其它部件共同合做完成各項功能，而不是由於本身的不契合而致使整個團隊延緩開發速度甚至項目失敗。

4.  指望與建議

        首先感謝老師與助教這一學期以來的辛勤付出，使我在編程能力和思想上都有了很大的提高。指望的話，但願能夠明確一下教學目標，感受有些要求自己就相悖，好比說，一方面指導書併爲對全部狀況進行詳細的要求說明，是爲了鍛鍊你們理解自行設計的能力；而另外一方面，因爲互測這種競爭機制，同窗又會在issue或是助教羣中對每一種詳細的狀況應該如何處理進行詢問，但願獲得官方的回答，以此來規範本身或是挑別人的bug。竊覺得，若是真的爲了提高自行設計的能力，不如就不要在指導書已經發出之後，再進行各類要求，不然這和一開始就規定好有什麼區別？還大大增長了學生與助教、助教與老師之間交流的時間成本。若是說須要進行某些硬性要求，就在一開始的時候將指導書寫清楚，畢竟指導書永流傳，一次修改福澤學弟學妹。