OO第四次作業總結
OO第四次作業總結
一、測試與正確性論證
- 當我們在進行一個項目時，我們有兩種方式來驗證自己的項目是否符合自己的預期。他們分別是測試與正確性論證。在我們進行對比分析之前，我們先來了解一下他們各自都是什麽。
（一）測試
在編寫軟件的過程中，測試永遠是一股強大的而且並不神秘的力量。很多大牛都曾經分享過自己的測試歷程。測試二字，說簡單也簡單，就是編寫測試用例，比較代碼運行結果與預期結果。說難也難，因為隨著工程項目的增大，想要進行完整的覆蓋性測試是有難度滴。覆蓋性測試會需要十分龐大的測試樣例，往往需要十分精巧的設計測試樣例或者采取其他的方式進行妥善解決。
為什麽我們要進行測試呢？測試的目的只有一個，那就是讓我們的代碼更加出色。展開來說的話，大致可以分為以下兩點。【1】如果你的代碼連進行測試都十分困難的話，那麽你的代碼必然是不好的。【2】在進行設計並實現項目的時候，我們不是每次都可以一次性對問題的方方面面想的十分透徹。總會有些特殊情況我們未必會考慮到。當我們在測試的時候，我們可以對邊界情況進行特殊值測試與壓力測試，觀察我們的代碼是否符合預期。如果不符合，那麽恭喜我們，我們發現程序的bug了。這是好事。
（二）正確性論證
- 正確性論證與程序正確性理論相類似。據百度百科，程序正確性理論有兩種途徑，其一為程序驗證，研究如何使用數學推理來嚴格論證程序是否符合要求，其二為程序綜合，研究由給定目標出發，如何一步步正確地構造出正確無誤的可運行的程序。我們OO課程所學習的正確性驗證即與程序驗證相類似。具體到OO課程的正確性論證概念，其應該是如下所示：
正確性論證是從程序的規格出發，基於規格對代碼進行邏輯上的論證，從而確認某一類或某個方法是否正確。
——OO課程同學計庭瑜
（三）效果差異
【二者共性特點】在對兩者的區別進行比較時，首先說明二者的共性特點，那就是代碼的——單元編寫。以功能單元為單位編寫代碼，不論對測試還是對正確性論證，都具有極其重要的意義。良好的編寫習慣，可以讓代碼的測試與正確性論證更具有針對性和有效性。不高的代碼質量，對於測試或者正確性論證而言，都將面臨較大的阻力。
【測試的優點&缺點】測試操作簡單，易於嘗試。我們編寫測試樣例，將運行結果與預期結果相對比，便可判斷代碼編寫是否正確。如果不正確則再從代碼中尋找bug。當工程項目龐大時，進行整體的功能測試難以生成覆蓋所有代碼的測試樣例。因而往往采用單元測試的方法。
【正確性論證的優缺點】正確性論證通過明確單元的前置條件與後置條件，再對代碼的實現過程進行理論分析，判斷代碼是否正確。這種方法在理論上十分有效，因為可以很輕易地遍歷所有可能的情況。然而問題在於如果我們采用手動分析，仍然無法避免思維盲區的存在；如果我們寫出邏輯表達式自動分析，可能在編寫的時候出現更多的錯誤降低效率。
【小結】通過上述分析，我們不難發現，測試易於操作但周期較長，正確性論證周期短但是可信度存在問題。因而在代碼編寫過程中，將兩種方法結合起來是一個可以考慮的嘗試。首先通過正確性論證尋找錯誤，發現錯誤並解決之後，采用測試提高代碼正確的可信度。
二、OCL語言與JSF語言
（一）OCL語言
OCL語言是一種對象約束語言，他是一種施加在指定模型元素上的語言。OCL表達式以附加在模型元素上的條件和限制來表現對該對象的約束，其中包括附加在模型元素上的不變式和約束的表達式，附加在操作和方法上的前置條件和後置條件等。對象約束語言是一種形式化的語言，與UML捆綁使用，主要用於表示UML模型中施加於模型上的約束。
——UML-OCL對象約束語言，百度文庫
【OCL語言的特點】
①OCL是一種精確的、無二義性的語言，易於使用和掌握。
②OCL是一種規範說明性語言，所有有關實現的問題均不能用OCL來表達。
③OCL是一種純表達式的語言，他是具有沒有任何副作用的聲明性語言。對OCL表達式的計算將返回一個值，計算不會改變系統的狀態。
④OCL是一種類型化語言，即OCL的每個表達式都是具有類型的。
⑤OCL不是一種程序設計語言，不能用OCL編寫程序邏輯和控制流程。
——UML-OCL對象約束語言，百度文庫
- 【OCL語言與JSF語言對比】從描述對象上對比，二者有明顯不同。OCL語言重在對象，描述對象內、對象間的數據項。而JSF則著眼於類與方法，描述類與方法的前置條件後置條件。由上述OCL語言的特點我們不難發現，相較於JSF，OCL語言具有更為出色的表達能力。然而，當語言功能強大時，與之而來便會有重量化的問題。相比之下，JSF就顯得更為輕捷方便一些。
三、單電梯系統的設計表示
類圖
順序圖
狀態圖
四、學期總結
【各單元的關系】在本學期的課程學習上，我們學習了如下四個單元模塊：一、Java與對象，二、多線程入門，三、抽象與規格，四、測試與驗證。各個模塊間呈現出一種層次遞進的關系。第一部分我們進行了Java語法與類與對象的編寫的初步嘗試；第二部分我們在單一線程的基礎上進行了擴展，嘗試了多個線程之間的協同合作；第三部分我們在編寫代碼的基礎上，通過對規格的約束，嘗試提高代碼的質量與正確性；第四部分我們學習了Junit自動測試方法，並對ALS電梯進行了自動化測試。從教學來看，各個單元的知識呈現出明顯的層次性與相關性，梯度上升的難度使得學生可以更加平穩地完成學習過程。
【各次程序分析】本學期的共有代碼作業9次。第一次是多項式的計算，然後進行了傻瓜式電梯、ALS電梯的編寫。之後，在學習多線程的基礎上，我們完成了多線程電梯，IFTTT文件系統與四次出租車問題。
在問題的設計上，我印象中很清楚，第一次多項式作業在完成時大腦中一片漿糊。對於這個問題左理右理都理不清，越想與煩躁。花了大量的時間才勉強完成設計的構思。這就是不懂如何拆分問題，將大的問題細分為小問題的典型癥狀。在接下來的作業中，我的設計能力逐步增強。我能清楚地感覺到，在設計階段，我可以更加明確的認識所研究的問題對象與數據間的關系，我所實現的各個對象的功能等。我的問題分析與設計能力不斷變強。
在測試階段，我必須承認，在多次作業的完成上，我的這項能力並未得到有效提高。原因也很簡單，作為一個DDL戰士，我總是在作業即將截止時才完成自己的項目。往往出現的情況是，我的代碼沒有測試或者只是進行了簡單的測試，抑或是采用同學構造好的測試樣例測試結果。自己分析問題構造測試樣例的能力並未增強很多。
至於代碼質量，我也能感受到自己的明顯進步。完成項目時，我的類與方法變多了，每個方法的代碼長度變短了。整個項目的結構更加清晰明了，更具有邏輯性。同時由於OS課程的輔助，在編寫代碼時，采用宏定義的方式來規定靜態常數，不僅代碼的可讀性更強，而且也更加易於調試。【工程化的理解】編寫代碼就像工廠生產一樣。過去的人們總是通過小作坊的方式進行生產，生產自由度高，但是產能較低。現在人們往往采用流水線等工業化生產模式，生產速度大大提高。代碼的發展也具有異曲同工之妙。過去人們可以按照自己的喜好實現自己的風格。但是這樣隨之而來的問題是，當多人協同合作完成同一個項目時，各部分代碼之間耦合度低，可能會出現各種各樣的問題。模塊化與規格化的設計與實現便應運而生。大家都按照一種規範來完成代碼的實現可以提高不同代碼的耦合度，進而提高代碼的質量。
五、課程建議
經過一學期的學習，在OO課程的互測機制上進行過分析，思考過多種可能的解決問題的辦法。但是發現很多方法最後都要落腳於【人】上，即要依靠人的主動性。然而這樣的課程設計自然是不魯棒的。之前閱讀了昂神的建議，覺得深受感觸。完善公測的評測機制，平衡公測與互測的地位是一種比較好的策略。
另外呢，個人認為，OO課程與OO實驗可以增強聯系。JUNIT的使用即為一個樣例。實驗課上的Junit的使用方法的pdf可以在OO作業之前發出來！實驗課上的Junit的使用方法的pdf可以在OO作業之前發出來！實驗課上的Junit的使用方法的pdf可以在OO作業之前發出來！
重要的事情說三遍。大概就是如此了。
OO第四次作業總結