OO第四次博客做業

OO第四次博客做業

對比測試與正確性論證

這一階段的兩次做業分別經過編寫測試代碼和書寫正確性論證文檔檢查了ALS電梯程序的正確性。

直接測試的方式曾經是過去本身檢查本身代碼正確性最經常使用的方法，由於這種方式最爲簡單直接，但只限於發現實際結果與預期結果不符的狀況。

第13次做業所要求的測試與過去本身所作的測試有明顯的差別，須要對每一個方法，根據方法的規格進行測試，避免了原來測試的盲目性，而且使用junit自帶的一些功能能夠一次跑多組測試樣例相比手動測試節省了大量的時間。

可是測試畢竟只是測試，只能證實程序有問題，而不能證實程序沒問題，特別是在規格寫的並怎麼詳細的狀況下，根據規格設計的測試代碼也就沒法徹底驗證程序，即便把代碼覆蓋率和分支覆蓋率都作到100%，也不能說明程序是徹底正確的。

而寫正確性論證文檔能夠作到幾乎全覆蓋，我在寫正確性論證文檔的過程當中，常常發現本身原來規格中寫的不怎麼全面的地方，並且還找到了程序結構以及邏輯上的一些不合理的地方，並進行了修改，正確性論證明際上是對本身所寫程序的一次解剖，能夠深刻程序的細節進行分析，然而代價也是巨大的。

爲了這兩次做業我重構了以前的ALS電梯做業，把整個程序設計得儘量簡潔，即便如此這個正確性分析文檔最終寫成後體量仍然十分龐大，有一萬兩千字三十頁，寫了幾乎是整整兩天，寫完之後本身都不想看(心疼一下檢查的老師)。

OCL語言調研

OCL(object constraint language)對象約束語言，一種用來進行約束定義的，形式化的無二義的語言。包含四種基本語言要素。

1. 類型(基本類型，高級類型)
2. 操做
3. 表達式(由操做數和運算符構成)
4. 語句

OCL中涉及到上下文，不變量等一系列規範，爲了保證無二義性，相比咱們所使用的JSF更加複雜和精細化，OCL中自己定義了基本數據類型和一些高級數據類型，還有運算符和表達式中的一些書寫規範，幾乎算得上是一種編程語言，這也正對應OCL的實際含義。

OCL和JSF中都有對前置條件和後置條件的說明，能夠說JSF是一種極大簡化以及自由化了的OCL。

第十四次做業UML圖

UML類圖

UML順序圖

UML狀態圖

總結

知識點

從第一部分的Java面向對象基礎開始，到第二章的多線程，再到第三章規格化設計，再到最後一章的測試與論證，第一第二章之間還算有些聯繫，可是跨度極大，有些偏離面向對象的軌道，第三章開始直接跑偏，第四章在第三章基礎上在順着這條跑偏的路繼續狂奔。

第一章是課程的基礎部分，讓咱們對Java語言和麪向對象有了初步的認識。緊接着從第二章開始就踏入了一個未知領域，多線程編程，這與咱們過去所編寫的程序大不相同，在學習了多線程編程以後，許多過去用單線程沒法解決的問題迎刃而解。第三章開始談設計，可是說實話我並不知道這些所謂的設計原則以及煩人的JSF在咱們的做業中能有什麼體現，更多的感受是在沒事找事。第四章在第三章的基礎上根據規格進行測試以及論證，從這算是看到了一些設計原則以及jsf的用處。

回頭來看，OO課程的知識體量十分龐大。

進步總結

程序結構和質量上的進步是明顯的，過去我寫的代碼一直十分臃腫，前幾回做業的代碼中也有體現，雖然功能正確，可是結構上十分混亂，屬於典型的想一步寫一步，而後回過頭來修修補補，最後的程序可讀性極差。

隨着程序體量不斷增大，原來的編寫方式難以適應，在ALS電梯做業中體現尤其明顯，那次做業的代碼繼承自上一次做業原本就很臃腫，再加上編寫過程當中考慮不周，完成後bug不斷，再加上代碼結構混亂debug十分困難，彷彿是在補丁上打補丁。從第二章開始轉變了模式，先設計再編寫。先打一個基本框架或是流程，而後根據這個框架進行細節擴充，不只縮短了編寫代碼的時間，也減小了bug的數量，同時debug的過程也相比原來更加簡單，代碼的質量有了明顯的提高，可是多線程自己的不肯定性也帶來了許多問題，如何發現bug成了關鍵。

談到設計，上面所說的設計與第三章講的設計模式沒有任何關係，在我看來第三章的內容十分雞肋，浪費時間浪費精力，根據代碼寫jsf已經喪失了jsf原本用途，使用jsf描述設計規格遠不如流程圖結構圖的宏觀把控，也不能像代碼同樣準確描述，因爲是根據代碼寫的jsf，轉化過程當中可能存在問題，代碼正確jsf出錯的狀況層出不窮，再加上jsf可讀性極差，我真的是寧願讀代碼也不想去看jsf。

至於測試和論證總算是給雞肋的jsf一點用武之地，junit測試工具能夠說是開啓了一片新天地，過去的測試過程基本上都是本身構造測試用例而後是轟動測試，偶爾有精力用python寫個腳本自動生成一些測試數據來測試，不過這些方法仍是比較原始。我深刻探究了junit的各類使用方法，收益頗豐。

在互評階段，閱讀別的同窗的代碼，對本身閱讀代碼的能力也是一種鍛鍊，同時也能夠發現其餘同窗在程序設計過程當中的優缺點，從而能夠在本身從此的程序設計中注意這些問題。

工程化開發

實不相瞞，我對工程化開發沒多少理解，僅靠這種一週一次還不停改需求的趕工做業，就算有前期準備也不超過一天，根本不可能有太全局的設計，也不可能徹底像課上所講的設計原則那樣實現，這樣作只會給本身添麻煩。

通常狀況下週六發布做業，白天剛OS，先把OO放一邊，週六晚上分析指導書進行初步設計，並解決指導書中的一(da)些(liang)問題，週日早上進一步構思，進一步分(tu)析(cao)指導書，開始搭框架寫readme，週日下午和晚上基本能夠完成一大半，週一夜再修個仙基本能夠把代碼寫完，週二週三構造數據debug，順便再 改 改 需 求，這基本上就是個人開發流程。

指望和建議

在前幾回博客做業中相關的吐槽已經寫了太多了，在此作個總結。

1. 知識面的問題。OO課程涉及的知識面極廣，體量徹底能夠分爲兩門(甚至三門)3學分的課程，而且課時極少，一週只有兩小時，上課基本上只是描繪了一個輪廓(大概佔實際知識量的10%~20%)，大部分須要課下自學(這也是不少同窗以爲OO課上沒啥養分的緣由)。
2. 做業量問題。這與上面的問題十分矛盾，因爲大量的知識須要課下自學，這自己須要大量時間，然而巨大的做業量很大程度上影響了同窗們自學的熱情，被做業壓得喘不過氣還有什麼心思去自學，這也致使了學到的知識很是膚淺，獲得的提高也頗有限，更具體的描述在個人第三次博客做業中，在此再也不贅述。
3. 難度問題。這個問題是由上述兩個問題所共同致使的，在多線程電梯以及IFTTT兩次做業中表現尤其明顯，固然早就學習過多線程的大佬們能夠忽略此問題。多線程電梯給我印象頗深，那一週正值清明假期，我硬是在宿舍守了兩天，學習多線程的相關知識，而後纔開始編寫代碼。不過回頭來看這兩天真的很是值，認真閱讀了《Java併發編程實踐》中的三個章節，對其餘章節的部分重要內容作了簡單瀏覽，這讓我很快適應了多線程編程，而且對可能遇到的各類問題有個基本認識，在編寫過程當中就會繞開這些可能的問題，因此在後來的屢次做業中基本沒有碰到由多線程的併發性形成的bug。然而這是因爲那次做業正值清明節，有這個時間讓我自學，這在其餘周是根本不存在的，並且清明節部分同窗想出去放鬆放鬆，並無學習相關知識，致使了接下來的兩次做業雪崩，這並不能怪同窗們，這是課程設計上的問題，假如多線程的第一次做業不是在假期間佈置，問題可能比如今還嚴重得多。
4. 需求問題。這個我已經無力吐槽，是因爲指導書和同窗共同形成的。改需求對於先寫完的同窗的影響極大(我這種每次週一甚至週一以前就先寫完的真的是每次看到改需求都忍不住想罵人)，對於後寫完的同窗卻是沒多少影響，並且後寫的同窗常常會提出一些十分細節的問題，正順應了教程組但願找機會改需求的心理。從而致使最後同窗們都變聰明瞭，一開始都不寫，都拖到最後幾天突擊，從而減小改需求的概率，同時也讓先寫的同窗去踩踩雷，找個安全區出來。感受這門課就是在變相鼓勵拖延症。通過長期磨鍊，總結出來一個真理，指導書說不清楚的最好就別問，readme就行了，皆大歡喜，實在說不清也早點問，不要等到每次星期二了才臨時抱佛腳，可是理想和現實老是差距很大，總會有人在ddl以前一兩天還去問，而後就成了強制要求。若是下一屆仍是這個機制，在此提醒閱讀到此文的學弟學妹們不要重蹈覆轍。
5. JSF問題。繼續沿用我上次博客的說法，用一個詞形容JSF，絕對是「雞肋」，第三部分所學的JSF並無起到什麼實際做用，只是浪費時間浪費精力順便再引發JSF撕逼大戰，直到第四部分開始作測試和論證JSF才體現出了一點用途，更具體的JSF相關吐槽和建議見個人第三次博客做業。
6. 互測問題。這估計是大部分同窗最關心的問題了。我總結出來一點，敵意和流行病同樣，是會傳染的。前5次做業還好，我一直處於0分附近，基本不扣分也不被扣分，十分和平。從IFTTT以後開始第一個撕逼風暴出現了，但其影響力還比較有限，因爲個人段位都比較佛系，並無被這次風暴影響，可是此次風暴已經席捲了一部分同窗，大量扣分的苗頭已經起來了，從JSF加入後變得一發不可收拾，連我所在的那個佛系段位都不太平了，最後三次做業發展到什麼狀況你們本身都心知肚明。還好已經臨近尾聲，影響有限，若是後面還有幾回做業，不知道撕逼大戰會發展到什麼程度。這個問題是互測機制的先天性問題，不少同窗也在客服羣裏發表過本身的意見，可是並無什麼萬全的方法，目前我也沒有想到什麼有效的解決方法。

無論怎麼說，OO課程總算是結束了，度周如年的日子已通過去了，只是但願學院改變折磨下一代的想法(這種心理是極其變態的，只會致使惡性循環)，不知爲什麼這種思想還能拿出來大搖大擺的宣傳(難不成是爲了掩飾課程設計上的漏洞?)。雖然沒有報名助教團隊，但仍是但願可以針對以上問題對課程進行改良甚至大換血，放過下一代。

最後再次感謝在這一學期一塊兒探討OO相關問題，分享測試數據設計思路的各位大佬們。