接着繼續(OO博客第四彈)

、測試與JSF正確性論證

　　測試和JSF正確性論證是對一個程序進行檢驗的兩種方式。測試是來的最直接的，輸入合法的輸入給出正確的提示，輸入非法的輸入給出錯誤信息反饋，直接就能很容易的瞭解程序的運行狀況。可是，每次測試只是在程序涉及的整個問題空間取一個元素進行測試，一次測試只能確保程序對於測試中的樣例和同類樣例是正確的，並不能確保全局正確性。而爲了追求全局覆蓋性，就須要大規模的測試樣例轟炸了，可是這時測試的最致命缺陷就出現了，一是如何構造如此大量且屬於不一樣類別的測試樣例，二是如何確保構造的測試樣例可以覆蓋全部的語句和分支，三是對於一些複雜的，可靠性要求高的程序，這樣的測試級別還不夠，還須要更高級別的組合測試，例如，如今有兩個分支1和2，分支1有a,b兩種狀況，分支2有c,d兩種狀況，單純的分支測試只會保證a,b,c,d都被執行過，但對其中的組合狀況沒有考慮，而這正是實際問題中bug容易發生的地方，多重分支的疊加最後達到一個編程人員在設計很難預料到的情形，從而發生錯誤，而組合測試就須要將可能發生的組合：ac,ad,bc,bd所有測試一遍，而隨着問題規模的擴大，測試樣例的數目將呈指數級上升，這將帶來很是大的測試難度。

　　正確性論證是一個上限很高的方法，若是可以完整且正確地對一個程序完成論證，那麼這樣分析事後的程序的可靠性幾乎是100%，可以概括覆蓋整個問題空間。可是，正確性論證對於使用者的要求很高，一些複雜的論證須要很高的數學技巧，論證多分支狀況時也很難保證徹底不出錯誤不發生遺漏，這須要使用者對於該程序有很是高的熟悉度和強大的全局駕馭能力。此外，正確性論證須要的步驟不少，須要嚴格的證實，且主要是人來完成，所以須要大量的時間。同時，面對多分支組合問題，論證時也將面對指數級增加的劃分數，這致使工做量會變得更大，很是消耗時間。

　　所以，我認爲更合理的方式是結合兩種方法，即便用正確性論證的思想來進行劃分，對於每個劃分的狀況構造通用性高的測試樣例進行測試，最終獲得具備高覆蓋率的測試集。同時，應該作到測試與設計並行，在設計時也要適當考慮測試因素，對每一個類和方法作更多的規約和異常檢測，減少問題空間的維度，爲測試減少壓力。

 

2、OCL語言 VS JSF

　　OCL語言介紹：OCL（Object Constraint Language）語言，即對象約束語言，一般與UML一塊兒使用，用來表達對於UML圖的約束，而一個約束就是對一個（或部分）面向對象模型或者系統的一個或者一些值的限制。

　　兩者相同點：

　　（1）都是聲明式語言（Declarative），即表達式僅僅描述了應該去作"什麼"，而不是應該"怎樣"去作。由於OCL是宣言式語言，因此UML中的表達式被提高到了純建模的領域，而沒必要理會實現的細節和實現的語言。JSF也是說明了方法執行先後產生的影響，而不描述具體是如何產生影響的。

　　（2）都是基於數學（集合論和數理邏輯），取數學符號和天然語言的折中方案，使用邏輯表達式來描述約束內容，可是具體的元素可使用天然語言說明。

　　（3）都有不變式，前置條件，後置條件這樣的語法。

　　不一樣點：

　　（1）OCL是強類型語言，任何表達式的值都是屬於一個類型的。這個類型能夠是預約義的標準類型例如Boolean或者Integer，也能夠是UML圖中的元素例如對象。也能夠是這些元素組成的集合，例如對象的集合、包、有序集合等等。JSF中對此沒有很嚴格的規定和要求。

　　（2）OCL規定了不少具體的操做符，數據類型和表達式語法，而JSF中更着重於必定要按照邏輯運算規則進行推理，更加要求符合數理邏輯中的規則，而對於操做符沒有很嚴格的要求。

　　（3）OCL語言能夠對類，類的屬性和操做等等任意的進行約束，而JSF僅針對類和方法。

　　（4）OCL一般結合UML類圖使用，加之其支持對於各類上下文的約束，同時還要保證沒有二義性，因爲須要支持這麼多的功能，因此它是一門「重型」語言，不像JSF是輕量化的語言。

 

3、第十四次做業相關UML圖

　UML類圖

　　頂層package

　　package：helper

　　

 　　package：interface

　　package：model

　　package：model中Elevator類

　　

　　package：model中QuestQueue類

　　package：model中SchedulerAI類

　　　　

　　順序圖

 

 

4、總結

4.1本學期OO的四個模塊內容

• （1） Java與對象（java速成+面向對象程序設計入門）
• （2） 併發與安全（多線程程序設計入門）
• （3） 抽象與規格（規格化和設計方法學入門）
• （4） 測試與論證（單元測試+JSF論證）

　　首先，四個模塊是按部就班，將整個工程化設計的內容劃分紅幾大部分，而後分部分進行學習和訓練。從你們最熟悉的程序語言開始，一步步深刻到面向對象程序設計思想，多線程程序設計方法，直到工程設計方法，總體相似於一個自底向上的過程。可是呢，我的觀點，在講課的時候當然分紅四個模塊邏輯清晰，可是實際應用中四個模塊的方方面面都是要涉及的，是否能夠設計一些單元之間內容交互的做業，或者是綜合做業，這樣更具備綜合性的東西纔會更加讓人感覺到工程化方法的重要性，不然每次只針對一個點會讓一些人可能產生應付該次做業的心態，固然這樣的綜合做業時間週期能夠加長，專項做業中穿插綜合做業，我以爲是更有意義的選擇。

4.2我的收穫與感悟

　　做爲一個從大學開始接觸編程的人，前一年半基本上是在面向過程語言中度過，寫了數不清的C代碼，因此不少時候腦子裏有不少C語言的設計思想，常常會想java中是如何提供這個語法功能的。本學期接觸面向對象程序設計，最大的感覺就是：原來編程語言相關的設計和思想這麼精彩。先說我的的程序吧，首先呢，得益於幾位大佬的幫助和課程的訓練，代碼能力上取得的進步是最大的，從命名規範，書寫格式，數據結構，類和方法的設計，再到線程的規劃與管理，都有了長足的進步。固然確定要貼圖對比才最直觀了：

第一次做業：

 

若是硬要評價的話，此次做業就是滿滿的C味java，徹底是C語言的設計思想，只不過僞裝創建一個類調了java類庫的一些方法而已。

那麼到了第十一次做業：

編程規範上已經有了長足的進步，同時也學會使用java的一些更加高級的語法，最重要的是，真正使用面向對象的思想來建模，逐步使用接口來對設計進行規劃。

到了最後一次代碼做業，即第十四次做業，即重構ALS電梯時：

代碼風格已經趨於穩定，算是比原來的本身上了一個大臺階吧。

　　關於文檔和規格，其實我一貫是很是支持註釋和文檔的書寫，代碼寫的簡潔高效易讀，同時輔以良好的註釋和說明文檔，就像本身寫的一篇文章同樣。不過說實話，我對於以JSF這種方式進行規格撰寫是不太支持的，我我的偏向於java類庫中那種javadoc的格式，這個想作到自動化太難了，從理解的直觀性來講，天然語言是要好過邏輯語言的，若是咱們在設計上加以優化，二義性的問題也能獲得很好解決，JSF的優點是能覆蓋到問題的各個方面，絕無二義性，因此我的以爲也能夠適當把JSF補充在可能出現二義性的地方。不過，規格書寫的重要性，或者更深層次，設計規約的重要性，我在第十四次做業中獲得了很是良心的體驗。在進行JSF論證以前，我對以前的代碼進行了不折不扣的重構，自認爲已經很完美了。可是在進行論證的過程當中，仍然發現了幾處很難表述的方法，而以後經過對劃分執行狀況，再對代碼做進一步分析後發現，個人設計思路中有不少交叉和冗餘地方，好比明明能夠經過維護隊列完成的功能，我在以前的設計中卻給隊列元素增長了兩種標記，標記之中還有小的分類，導致代碼功能雖然正確可是很臃腫，而經過論證時對於各種狀況的剖析與劃分，便能很容易的找出問題的緣由所在，這也再一次告誡我，必定要設計優先，不要直接上手寫代碼。

　　關於設計問題，我大約經歷了這樣一個過程：面向過程——無腦使用類，方法當函數用——抽象類+接口設計。僅憑大腦思考，基本是不可能駕馭大工程的，那麼經過設計方法學來首先作設計規約，並把全部的設計思路具象化，在java中使用抽象類+接口設計的方式進行初期規劃，並輔以文檔和規格進一步對類和方法進行規範化，作完全部準備工做以後再開始寫代碼，這樣，才能真正寫出大工程。

　　測試是個人一個很嚴重的弱項，老實說如今還處於對拍器對比輸出結果的階段。本學期初步接觸了單元測試，可是感受理解的還很不足，我的認爲這部份內容最重要的仍是在實際中使用，爲了完成做業去編寫單元測試意義不大，由於測試的代碼基本上都是已經修復完bug的版本，少了測試——發現bug——修復bug——再測試這一環節，就很難深入體會到單元測試的優勢，這部份內容結合在複雜的幾回做業中就更好了。

4.3 工程化方法之我見

　　工程化方法包括不少的內容，一一說下來要列好長的清單，其實核心就在於如何解決我的有限的能力和工程無限大的複雜度的矛盾。實際工做中大工程須要不少人來合做完成，而每一個人的能力，特色又不可能相同，因此1+1=2是絕對不可能的，那麼如何在這樣的狀況下，儘量的追求整體的最終的高效率和高質量，這就是工程化方法告訴咱們的事了。固然，如今的工程化方法大可能是創建在人的經驗之上的。說不定到了將來，因爲編程人員能力的提升（或者說機器自動生成底層代碼），相關數據分析能力的提升，工程化方法將變成數據導向的產物，人類的思考只需作最高層的設計。畢竟，最核心的永遠是解放生產力，讓人的思考用到最關鍵的地方去呀。

4.4 關於OO

　　關於OO課程，首先表示很是感謝這門課程，確實給我帶來了不少變化。這門課程雖然被不少人詬病，可是我以爲仍是頗有其存在必要的，只是一些具體實現的環節仍然存在問題，所以，我但願能成爲OO助教，真正去修補這些問題，而具體的建議，就經過實際工做來看吧，OO接着繼續！