第十五次oo做業

做業十五

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

程序的測試須要經過輸入特定數據等方式，檢查程序是否和預期相同，由於測試不可能窮舉，致使了不窮舉的測試不可能驗證程序是徹底正確的，只能驗證程序在測試時沒有發生錯誤，儘管如此，測試依然是一種高效的檢查程序的方法，經過輸入數據或復現現場，直觀的發現代碼的問題，進而在代碼中找到問題的來源並修正。

程序的正確性論證是在用戶提出需求後，進行規格撰寫後，論證程序是否符合規格的過程。由於規格每每是布爾型或天然語言，對程序員來講並不如代碼和測試數據直觀，且工做量巨大。但相應的，好處是對代碼總體進行了具體的剖析，在規格符合需求的前提下，可以發現程序與規格間的邏輯上的不符。

兩者相比較而言，測試是一種較爲簡單，較爲直接與直觀的方法。經過編寫測試數據就能夠對於程序進行黑盒測試，不須要花大量時間在理解程序自己上。相比之下正確性論證就須要測試者對於程序自己就很細緻的瞭解，對於要求功能有很細緻的瞭解，每一部分的測試都會顯得十分麻煩，尤爲是在面對一些邏輯較爲複雜的代碼，正確性論證的工做量呈指數型增加。

OCL語言和JSF規格的對比

OCL語言全拼爲objective constraint language，中文叫作對象約束語言，是用來約束定義的，形式化無二義的語言。OCL語言是一種聲明式語言，用來描述應用於UML模型的規則，如今是UML標準的一部分。OCL語言和JSF都是聲明式語言，但OCL通常與UML圖相關，語法更規範。

第十四次做業

UML類圖

UML順序圖

UML狀態圖

總結

闡述四個單元模塊知識點之間的關係

本學期所學內容大概可分爲如下四個單元。

1、什麼叫作面向對象編程，面向對象和麪向過程的區別在哪裏。主要是第一次至第四次做業。

2、多線程編程，多線程編程的運行特色及調試方法。主要是第五次至第九次做業。

3、規格設計，如何在宏觀上對於程序進行設計與調試，爲之後大規模的軟件開發打基礎。主要是第十次至第十三次做業。

4、正確性論證，從科學理論的角度去評價一個程序的好壞，改變以前黑盒測試的邏輯習慣。主要是第十四次做業。

四個單元深刻淺出，從全面講解java知識，深刻多線程設計，到較爲輕鬆的測試和jsf論述，咱們體驗了從語言學習、構建工程到單元測試的完整過程。

梳理本身所設計實現的程序，分析本身在設計、測試和質量上的進步

應該說OO這門課給我帶來了很大的提高。一是面向對象的編程，二是多線程的相關內容，三是工程化開發的相關知識。在閱讀博客，進行互評，與室友同窗的交流過程當中，我學到了不少東西，簡單的如常量的定義（其實很想叫他宏定義，由於主要做用其實相似於宏定義），大到編程風格，編程結構，能夠說，沒有與同窗們之間的大量交流，我是難以得到這些提升的。在面向對象課程以前，雖然我也編寫過一些小型的程序，基本沒有接觸過測試方面的內容，測試時也更多地根據本身想固然的方式來測試，沒有一個規範的，高效的方式，在如今看來，之前本身的測試也略顯笨拙。

闡述本身對工程化開發的理解

軟件開發無疑須要大量的團隊合做，工程化代碼就尤其重要。代碼規範、JSF規範，都是方便工程化開發的實用工具。工程化之因此出現，也是由於計算機行業從量變到質變的一個過程，一我的編寫代碼，只須要本身可以編寫時讀懂，甚至不須要考慮維護。幾我的開發的程序，須要有必定的規範，方便他人閱讀，對接。幾十上百人的工程，須要的則是一個高效的開發規範，不只須要考慮到當前的開發成本，甚至須要考慮到多年後，其餘人閱讀並維護代碼的代價。我的代碼的可閱讀性，魯棒性，與整個工程息息相關，一我的的不留意可能會帶來整個團隊很大的困擾。工程化開發正是適合當前的大規模計算機開發的一個有效手段。

對課程的任何指望或建議

首先不可否認，OO這門課有必定的不足，通過一個學期的學習，你們也能體驗到很多。但總的來講OO這門課，是利大於弊的，對咱們我的能力的提高很是巨大，因此我的仍是認爲能夠保留當前OO的主要形式，但也不能否認須要一些改進，好比受到不少人吐槽的指導書常常修改，助教的解答甚至互相矛盾等等，這些也須要助教團隊和老師們多總結之前的同窗們的常見問題，以減小沒必要要的工做量

同時，對於很多同窗惡意的查找bug，亂報bug的行爲，我的認爲能夠採用同窗們曾經提到過的，每次測試後，由被測者給測試者打一個印象分，對於亂找bug的同窗報以相對較低的分數，除了段位匹配外，也增長印象分的匹配，從而能夠必定程度上限制一些同窗亂報bug的風氣。