一、測試與正確性論證差異對比

測試，顧名思義，就是用一些有意義或無意義的輸入去檢測程序的正確性或魯棒性，因其直觀明了所以在寫簡單的程序時我們能迅速找出bug并加以解決。并且，這種方式是絕對客觀的，只要和正確結果不匹配那么程序就一定存在一些問題。測試最大的缺點便是無法完全覆蓋所有情況，即使很大的測試數據也可能跑不出來某些細微的bug，但這種bug有可能是致命的。

正確性論證則是從代碼邏輯角度去分析代碼，它的好處便是可以完全覆蓋程序的所有情況并加以分析，只要分析不出錯就能保證程序不出錯，但這種方法的缺點也比較明顯，需要耗費大量時間和精力去完成這一工作，并且這種方法的正確性是建立在規格正確的基礎之上的，一旦規格不完善也將導致該方法出現紕漏。

總之，兩種方法各有利弊，在面對復雜程序時兩種方法都顯得比較吃力，但若只考慮正確性，那正確性論證無疑要比測試來的可靠。但如果程序本身實現的功能不多，那么靠測試用例轟炸一番基本就不會遺留bug了。

二、OCL與JSF的異同

　　OCL(對象約束語言)是一種形式化語言，它用于對設計對象進行約束，主要是在UML模型中施加于模型上的約束。OCL是一種精確的，無二義性的語言。其只是一種規范說明性語言，所有有關實現的問題都不能通過OCL來進行表達。另外，它是一種類型化語言，OCL中的每一個表達式都是具有類的。但是，不能用OCL編寫程序邏輯和控制流程。

　　與JSF的對比

　　相似的點：

　　(1) 都是一種約束語言，用于對程序的設計進行約束。

　　(2) 都具有統一的標準。

　　不同點：

　　(1) OCL語言是精確的，沒有二義性，而對于同一個程序不同人可能會寫出不同的JSF。即JSF具有更大的開放性。

　　(2) OCL主要是對對象進行約束，JSF的則是對類和方法進行約束。

　　同樣的，兩者各有優缺點，沒有明顯的優劣之分。

三、 類圖、順序圖、狀態圖

類圖

時序圖

狀態圖：

四.學期總結

（1）.

　　第一章介紹了一些JAVA語言的基本知識和簡單的面向對象思想，相對后面的課程來說可以算作一個小小的過渡（雖然相比計組的初始階段還是難上不少）。

　　第二章開始了噩夢一樣的多線程程序設計，從第五次作業的三電梯開始，生活對話中充斥著以“你三電梯會寫嗎”，“synchronized咋用”等開始的對話。正是在這一章的學習和多線程作業的編寫中讓我理解了多線程程序編寫的困難之處（我不會再罵那些多核優化差的游戲了），但也正是這一階段的訓練加深了我對多線程和并行的理解，在程序的設計上有了很大的提高。

　　第三章則在多線程程序的基礎上添加了規格描述的過程，主要介紹了JSF的規范書寫和程序的規格化設計，這一部分重點就開始從寫程序轉移到設計與規范了；

　　最后，第四章著重介紹測試，包括JUNIT測試和正確性論證，重點又從規格轉移到了測試。

?（2）.

　　總體上是從0學習了一門全新的語音，剛開始的時候，是很困難，因為一點java的寫法都不明白，所以第一次很吃力，但是后面慢慢適應了，感覺有些好轉，多線程可以說是又一場災難，又是一次從0開始的起步，所以第一次的多線程電梯寫的很爛漏洞百出，但是后面多線程的出租車慢慢的不斷優化，也算是有了一個很不錯的結果，總體上是學習了一些新產品。后面就是在代碼風格，規范性等等各方面的學習，了解了這些規范化的寫法。

?（3）

　　首先是開發上的問題。開發者一定要對程序進行規格化描述，這樣方便測試者對于代碼的測試。另外，需要遵循一定的設計原則，使得代碼的可移植性高，方便重構，否則會對之后的更新完善帶來不小的麻煩。然后是測試的問題。如何對軟件進行合理有效的測試也是工程化開發的重要問題。因為，一個軟件的測試所需要花費的時間往往是開發的數倍。進行高效的測試便可以大大縮短工程的時間。

（4）

　　oo總體上來說難度是很高的，尤其是第一次java作業和第一次多線程的作業，但是也很人性允許有幾次的無效。所以若是肯花一些時間的話還是能夠保證不被掛科的。若是能夠在入門的時候講的更加的詳細，更加的平滑的提升難度可能會好一些吧。互測的話，可以加入一個類似隱藏分的東西吧，把那些亂胡扯的人的隱藏分降低（根據被申訴的次數判斷或者別的什么）。可能現在的罵聲會少一點吧。

轉載于:https://www.cnblogs.com/lyffff/p/9224898.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的OO学期总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。