OO第十五次作業
一.測試與正確性論證的效果差異
測試和正確性論證分別是從理論和實踐兩個角度去規範程序的正確性的，我認為其主要的區別在於對於程序透明度的需求上，
測試作為一種實踐手段，他的實施的要求是比較低的:在完全了解程序的結構下可以進行針對性的覆蓋測試，在對程序一無所知的時候依舊可以進行壓力測試和黑盒測試，但同樣的，作為實踐手段的測試無法從邏輯上完全的自洽，哪怕是覆蓋性的測試，在論述其測試覆蓋性的時候其實也經過了很多正確性論證的過程。簡而言之，測試能為任何程序都提供一定限度的保證，但這個保障幾乎不可能是完備的。
正確性論證是從理論原理和邏輯上證明程序的正確性和可行性，他相較於測試而言需要獲得程序自身的全部信息，只有從邏輯層面到設計層面都通透的人才能對程序寫出一份有效的正確性論證。其二，正確性論證往往也需要被測試所輔助，因為正確性論證本身的論證過程和實際實現過程都是可能出現人為的受迫性失誤的。如果說測試是對程序現象的直接客觀反映，在進行正確性論證的過程中的主觀部分是很難以摒除的。概而論之，完成一份完美的正確性論證需要的是程序設計規程中的所有資源和細節，而且完美本身就是不可能達到的，但一旦完成了一份正確性論證，程序的邏輯正確性就被完備的保障了，無論程序以後再做何調整，這個單元是不會受到影響的。
測試的優點：
1.種類多樣，開始測試的必要條件很少
2.針對性強，可以驗證程序對某一類型的輸入的處理能力
3.需求指向，可以模擬操作的實踐情景
缺點：
1.缺乏邏輯和理論上的可靠性
2.難以獲得完備的保障
3.針對性和覆蓋性依舊需要正確性論證的部分內容進行輔助
正確性論證的優點：
1.一旦正確，便是邏輯上完全可靠的
2.通過邏輯耦合可以確保完備性
3.可以對每個獨立的論證單元進行程序間遷移，在條件不變的情況下正確性也不變
缺點：
1.需要對程序整體邏輯結構和設計結構的高度理解
2.論證過程中可能出現非受迫性失誤，需要測試輔助
3.實踐性差，某個單元的論證錯誤很可能導致程序所有樣例的崩潰
二.OCL與JSF的異同
同：
二者都是形式化，聲明，約束性語言，本質都是前置條件向後置條件的一個導向，對過程規格的關心程度有限。同時，二者都使用了數理化的邏輯，但是出於自然語言的轉化困境，二者也都創立了一部分數理邏輯語言之外的，便於規範的新語法。
異：
OCL語言有JSF語言所沒有的監控條件部分，使得作為一種約束語言的約束真值表達性更為強大，同時,OCL的語法結構相較於JSF更為復雜，這使得他更便於規格的書寫，但難於對於規格的驗證。
JSF語言比較於OCL語言多了Modifies域，更好的能夠讓書寫者完成變量監控，同時JSF語言對布爾表達式的數理邏輯依賴性更強，這對書寫者提升了抽象性的難度，但是在驗證正確性和進行遷移的時候更為方便。
三、UML
UML類圖
UML系統時序圖
UML狀態圖
學期總結
闡述四個單元模塊知識點之間的關系
四個單元是一個整體的學習流程，第一單元讓我們熟悉面向對象的概念思想，第二單元完成線程協調，第三單元和第四單元則是測試和正確性論證，從整體的規劃來說是先實踐後理論，倒置了一個實際工程的實現流程讓我們明白完成一個面向對象項目的四要素。
其實如果在默認同學們有一定的JAVA設計基礎的話從第一單元就開始滲透一部分的規格思想會更好一些?畢竟補充規格的過程和設計規格的過程差異還是較大的，聯系補充和調整可能並沒能達到預期的教學目標
自己在設計、測試和質量上的進步
在這個學期的學習過程中，個人抽象問題的能力和面向對象設計類和方法的能力肯定是有所提升的，在最後幾次對最初幾次作業代碼調整的過程中，都能夠在保證正確性的前提下對代碼進行大幅度優化。
這門課程是我第一次真正的接觸單元測試，先前進行的都是黑盒和完全覆蓋性測試比較多；Junit的功能不算強大，但是讓我們初窺單元測試還是足夠了。
著重考慮代碼上的魯棒性是這門課程給我最大的收獲，現在在寫代碼之前，的確會比先前在代碼的健壯性上考慮的全面更多。
對工程化開發的理解
一個規格，一個標準，工程化開發，流水化生產。易於分工，便與協作。高效，準確，可遷移。
對課程的任何期望或建議
課程兩頭松中間緊的情況太嚴重了，如果可能的話，能否從新平均分攤一下每一周的作業量和作業安排？
這屆實施的錯誤分支樹舉措給予好評，的確真正有效的限制了亂報bug的情況，但是現在先掛滿樹再等人申訴坐地還錢的情況依舊是一本萬利，希望課程組能夠給被申訴的bug一個閾值，如果某一次作業測試者被申訴成功的bug點超過一定數目，要對測試者予以相應的懲罰。
最後，還是規格這裏的教學方式問題，現在的課程安排的確很難讓大家意識到他的重要性並去自發的好好學習，況且補充規格這件事的確對設計規格起到的幫助作用有限，是否可以從新考慮一下這裏的作業和教學方式呢？哪怕是從規格設計起，用3次作業寫一個新項目也是可以的啊
OO第十五次作業