論證與測試，誰才是真正的不二法門

第十三次作業的時候，我們開始使用Junit對代碼進行測試，主要是測試代碼的覆蓋率，以及分支的覆蓋率。（主要是檢查JSF寫的是否是符合規範，……）。

這裏我給出我測試的結果，可以看出測試的結果還不是很理想的，是因為在Override中，測試代碼的覆蓋率沒有達到100%。

這是為什麽呢？在我的測試運行之後，我的代碼顯示的是全部都允許了。問題是，在我們看來確實是每一步都執行了，但是實際上是這樣嗎？當然不是，否則我的覆蓋率為什麽回事99%，而不是100%呢？這說明有些部分代碼看起來執行了，但是實際上並沒有。那麽測試代碼給我帶來了什麽呢？對於我的代碼來說，當我盡可能的考慮所有情況的時候，還是有一段代碼沒有執行，這是說明我那一段代碼本身就是多余的。可能有設計上的問題，這種問題常會出現在這種情況下，那就是在之前我們以及限制了變量的範圍，但是在接下來的代碼中，還是習慣性的多寫一個else，所以根本不可能出現的情況在else裏面出現了，這就導致了代碼的多余。

測試的功能遠不止這些，對於程序來說，雖然用戶是最好的測試，但是不可能將還沒有完全完善的程序給用戶拿去測試，所以大規模的自測是對程序的保證。那麽論證又有什麽用呢？

個人感覺其實沒多大用，但是結合測試的時候我發現，只有測試的話，我們往往能過發現問題在哪？測試者怎樣去發現問題呢？感覺這就與論證有關了，如果一個程序怎麽都測不出來bug，那麽問題可能有兩種，一是程序本身就沒有bug，但是也有可能是測試的不完備，導致沒有發現bug。如何快速的讀懂代碼，然後發現問題，最後進行測試呢？論證文檔不是寫給自己看的，是寫給別人看的。所以通過論證文檔理解程序的框架，以及發現問題的所在是最快の方法。論證文檔給出了編程者自己的思想以及每一個方法的實現，但是又與代碼有多區別，代碼難以直觀的反應出程序的構架以及實現方法。

所以論證與測試都不是不二法門，只有將其結合起來才是王道。

調研OCL

這次真的是自己打臉了。我記得我再上一篇博客裏面說到，我可能再也不會寫JSF。然後就被報了10個左右的incomplete。所以對JSF簡直反感到爆。但是最後一次作業，我還是老老實實的重寫了我所有的JSF，≡(▔﹏▔)≡

這個臉打的我好痛啊，（；′д｀）ゞ

然後我們來調研一下OCL語言吧，OCL語言是約束（Constraint）語言和查詢（Query）語言。一個約束就是對一個（或部分）面向對象模型或者系統的一個或者一些值的限制。這一點與JSF類似，JSF中requires必須要有一定的限制才行。UML類圖中的所有值都可以被約束，而表達這些約束的方法就是 OCL。在UML2標準中，OCL不僅用來寫約束，還能夠用來對UML圖中的任何元素寫表達式。在JSF中就是對每個方法中的過程寫表達式，然後每個OCL表達式都能指出系統中的一個值或者對象。因為 OCL表達式能夠求出一個系統中的任何值或者值的集合，因此它具有了和SQL同樣的能力，也就是說OCL也是一種查詢語言。這一點是JSF所不具有的。

OCL的基礎是數學中的集合論和謂詞邏輯，並且它有一個形式化的數學語義，但是它並沒有使用某種數學符號。因為雖然數學符號能夠清晰的、無歧義的表達事物，但是只有極少的專家可以看懂。所以數學符號並不適合用於一個廣泛應用的標準語言。自然語言是最易懂的，但是它是含混不清晰的。OCL取了自然語言和數學符號的折中方案，使用普通的ASCII字符來表達數學中同樣的概念。如果你不喜歡當前的OCL表達方法，OCL規範還允許你定義自己的OCL符號集，這點是可以理解的，因為OCL有一個清晰的數學語義。這與JSF中的表述方法一致。

使用EA畫uml

大家都在用什麽工具化uml圖呢？Staruml，eclipse？ 給大家介紹一個工具，Enterprise Architect，是工程化的很好用的工具，給出破解版的鏈接，（大家要多多支持正版呀，( ??? )?）。 https://pan.baidu.com/s/1eRElJcm#list/path=%2F

然後我們就用它來畫圖吧，至於怎麽畫圖，網上教程很多的說：

使用EA自動生成類圖： https://blog.csdn.net/zhouyong0/article/details/8281192/

使用EA畫類圖： https://blog.csdn.net/cfeibiao/article/details/8545083

使用EA畫序列圖： https://blog.csdn.net/craftsman1970/article/details/70877530

使用EA畫狀態圖： https://blog.csdn.net/craftsman1970/article/details/78276479

拿走不謝，(●ˇ?ˇ●)。

然後看一下小編生成的類圖吧。

然後是順序圖。看這裏，d=====(￣▽￣*)b

然後是狀態圖，嘿哈。

這門課程讓我學到了什麽

考完離散，沒事的時候接了個活兒。內容就是設計一個簡單的電梯，然後需要使用一種設計模式，在這種設計模式下設計該電梯構造的uml圖。包括類圖，狀態圖，時序圖，還有用例圖。一拿到題，沒有使用過設計模式的我，花了兩三個小時就隨便畫好了。結果可想而知，被退回來了，原因就是沒有使用設計模式。然後在網上看了一些教程之後，使用設計模式中的狀態模式完成任務。就簡單說一下自己的理解吧。

如果沒有這門課的學習，以及對電梯的深入編程，我連這個活兒都不敢接。然後是發現任務要比我們實現的電梯簡單很多，那我就說一下設計模式吧。我們平時寫的作業程序，並沒有考慮到設計模式的問題，也就是說可以自由發揮設計方法。但是這只限於我們自己的程序，如果用於工程開發，用於多人之間合作，用於較大的工程的時候，如果每個人的設計方法不一樣，最基礎的構架不一樣，那麽就可能導致工程維護起來十分的困難。很多同學都會吐槽JSF，與方法論證，在使用設計模式之後，我才意識到JSF使用到設計模式的時候，可以讓我們更好的理解以及設計程序。如果硬要說四個階段，11次作業讓我學到了什麽，那就是寫代碼，debug，工程化設計，工程化測試。但是學的都很菜， ┭┮﹏┭┮

課程建議，建議下一屆整一個大作業，兩三周才能完成的那種，hhhhh，~~~///(^v^)\\\~~~

論證與測試 + 用EA畫uml