OO最後一次總結

測試與正確性論證

       Dijkstra說過：「程序測試只能證實程序有錯，不能證實程序正確。」所謂程序測試，其實是測試者特地挑出一批檢查數據，經過運行程序，檢查每一個輸入數據所對應的運行結果是否符合預期要求。正確性證實是論證程序達到預期目的的通常性陳述，該論證不與程序輸入的特定值有關，但可以表明窮舉性測試。

       測試相比於正確性論證來講，實際像是將程序看做一個黑盒，並不關注程序內部的實現。測試不只能快速地發現程序的bug，也能測試程序的效率，複雜度等屬性。可是缺點在於須要大量的數據，想要作到全覆蓋測試並不容易，甚至在不少狀況下根本沒法實現。

      而正確性論證則不同，若是說測試是從實踐方面來檢測程序的正確性，那麼正確性論證則是從理論上來證實程序的正確性。正確性論證在理論上來講能夠覆蓋整個程序，從而證實整個程序的正確性。比起測試來講，因爲是從理論上來證實程序的正確性，所以所須要的資源相對較少。可是其缺點也比較明顯，首先，正確性論證是從實現的角度去論證程序的正確性，只能證實程序實現的正確與否，若是程序一開始的設計就是錯的，那麼正確性論證不能發現這個問題。其次，當一個方法的實現過於複雜時（好比一個方法的代碼超過了50行），正確性論證難以進行。

OCL與JSF

       對象約束語言（簡稱OCL）是一種指示用戶建模系統中的限制方式。UML圖一般不夠精細，沒法提供與規範有關的全部相關部分。這其中就缺乏描述模型中關於對象的附加約束。OCL即是爲了解決這類問題應運而生的形式語言。

       與JSF相比，雖然二者都是一種約束語言，但OSL語言是一種無二義性規範語言，而且每個表達式都有本身的類型。JSF的主要服務對象是方法，而OSL的主要服務對象是每個類。

第十四次做業

  

 

 

學期總結

       不知不覺間已經度過了一個學期的漫長而痛苦的OO旅途。雖然說痛苦，可是收穫滿滿。

       第一個單元，咱們的主要目標是造成面向對象編程的思想。之前所學過的編程語言C語言是典型的面向過程的編程語言，而新接觸的Java語言則是一款面向對象的編程語言，這一單元主要是讓咱們熟悉面向對象的編程思想，而且以典型的電梯程序來輔助練習。這一過程當中，主要的問題是對Java語言的不熟悉，難以理解面向對象的編程思想。

       第二個單元是針對多線程編程的訓練。用一句通俗的話說，這一個單元是最折磨人的。首先在於咱們對線程絲毫沒有概念，也不懂得併發等術語的含義，所以在多線程編程中到處碰壁。其次，線程安全也是一個讓我很是頭疼的問題。在這一個單元中，主要出現的問題是如何設計，好比在出租車系列做業中，到底是一個線程管理一百個出租車仍是一百個線程管理一百個出租車方便實現？如何去保證出租車運行過程當中線程始終安全？這些問題是當時一直困擾着個人。

第三個單元着重於規格化的設計。這一個單元的主要目的是讓咱們意識到規格的重要性。儘管JSF一直在被吐槽，儘管你們對測試時測試者對JSF的扣分十分厭惡，可是，這一個過程確確實實讓咱們瞭解了規格的重要性。規格不只僅方便了程序的使用，它還可以讓其餘人更容易弄懂你的程序，這對於開發者來講十分重要。

第四個單元的重要任務即是測試和正確性論證了。到了這個單元，你們都已經可以理解面向對象的編程思想，也能寫出相應的代碼。可是如何保證本身寫的代碼是正確的呢？這一單元針對代碼的測試和正確性論證幫咱們解決了這個問題。也讓咱們可以寫出完善健全的代碼。

回看本身寫過的歷次做業，我發現本身的提升仍是很明顯的。最初的我寫的代碼，徹底是麪條式的，現在的代碼，具備了至關程度的可移植性。針對測試，已經學會了將輸入輸出劃分，以造成分類樹來對程序進行測試。

至於工程化開發，個人理解是首先開發者在設計方面要遵循必定的原則，其次要寫出可移植性高，可修改性強的代碼，便於修改和完善。再次對每一個類每一個方法的實現要規格化，方便測試。最後的測試階段中，要儘可能按照測試的分類樹進行測試，儘可能實現全覆蓋的測試。

咱們常常說的一句話是OO不易，和諧6系。其實我以爲這和課程組有很大的關係。很大的緣由是互相測試致使的。有一句網絡語是這麼說的：「我就這樣了，有本事你順着網線來打我啊？」的確，匿名的互相測試確實讓某些同窗過於「隨心所欲」，週五測試結果出來以後，看到被報的BUG又要與測試者爭論許久，最終還得靠課程組的仲裁。既破壞了同窗間的關係又加大了同窗和課程組的壓力。

我認爲一個很好的解決方法是加大公測力度，減小互測在分數中所佔的比例。實話說，互測有很強的主觀性，公測纔是真正公平的。但不少次做業公測，弱的驚人，把分數徹底交給測試者，難怪同窗們都說這是面向運氣編程。

雖然怨言很多，但始終仍是但願OO課程能愈來愈好吧，也但願這門課能成爲北航計院的特點課程（雖然已是特點課程了）。