一、測試與正確性論證的比較java
測試:多線程
效果直觀,便於調試,可操做性強,可是覆蓋率不如正確性論證。框架
正確性論證:單元測試
覆蓋率高,可靠性高,可是可能會忽略代碼實現的錯誤細節,不夠直觀,篇幅過長,不易於閱讀。學習
比較:測試
測試和正確性論證都是測試工程的好方法,可是面向對象自己就是一種極爲具體化的簡單設計思路,正確性論證的必要性很小,大多數狀況使用單元測試就能很好的應付測試需求。線程
二、OCL和JSF的比較設計
OCL是一種對象約束語言,沒有二義性,可以完善建模元素的相關細節。3d
類似之處:思想相似,目標相同,框架相仿。調試
不一樣之處:OCL實用性更強,JSF不知所謂;OCL更加完善,JSF表達混亂;OCL用途普遍,JSF……不知道說什麼好,先點菜吧。
三、
類圖
時序圖
狀態圖
四、總結
四個單元模塊:面向對象基礎,多線程開發,代碼工程化,測試論證。
關係:多線程開發須要前一模塊的代碼基礎;代碼工程化須要有線程的代碼來工程化,前兩個模塊就是創造了足夠多的代碼;測試論證也須要代碼,第一個模塊提供了這些代碼。
梳理:實際上面向對象基礎的部分我基本沒學到什麼東西,寫代碼挺簡單的,也不會有什麼BUG,感受花費了不少時間卻沒有學到知識。多線程開發因爲指導書混亂的緣由讓人很痛苦,最終選擇了比較低劣的同時只有一個線程運行的模式,也沒有學到什麼東西,真的很慚愧。代碼工程化因爲JSF這個規格語言太愚蠢也只忙着互測撕逼了。測試論證部分讓我很滿意,學到了很重要的內容,可是一些同窗在互測中的醜惡嘴臉也盡收眼底,極大地增加了人生閱歷,認識到了社會的殘酷,改變了對一些平日裏看似友善淳樸實則陰險惡毒的同窗的第一印象,讓我不只學到了重要的測試方法(真的很重要),也看清了許多同窗的本質面貌,一箭雙鵰,大快人心。
整體來說,程序設計部分真的沒有學到多少東西,多是由於我自己的代碼水平就在平均之上。java的學習也很輕鬆,百度和谷歌是最好的老師。通過OO的鍛鍊,個人代碼能夠說有了必定程度的工程化改觀,至少不那麼難看了,這仍是值得欣慰的。可是本學期花大量時間的JSF在往後一點用處也沒有,除了能鍛鍊鋼鐵通常的意志以及百折不撓的心態之外我真的想不出這個規格有什麼意義。
工程化開發的理解:
你的代碼別的開發者能看懂,反之亦然。
你的代碼一年以後你本身還能看懂,而不會出現徹底難以維護的情景。
你的建模別的開發者也能看懂,反之亦然、
你的代碼簡潔而美觀,你的代碼可讀性強,讓人有閱讀的慾望。
可是OO課程的工程化實在是讓人不知道怎麼說……先點菜吧。
OO課程的工程化的核心是JSF,可是這個JSF具體怎麼樣上文已經描述過了,並且實際工做中也不可能有這麼愚蠢的規格寫法。
對課程的指望和建議:
但願課程組可以正視多年以來的普遍的批評,仔細思考並處理這些建議,同時要深刻羣衆,瞭解同窗們不滿的關鍵。攤開來講就是,惡意扣分並非同窗們厭惡這門課的首要緣由,首要緣由是由於課程評價機制的不完善,即課程組難以遏制惡意扣分現象。社會是複雜的,只要採用互測的機制就不可能杜絕惡意扣分,因此課程組的體系建設核心應該立足於讓惡意扣分的同窗得不償失,而非如今的試圖讓同窗沒辦法惡意扣分。要知道咱們北航的同窗一個比一個精明,鑽空子惡意扣分的本領真的是全國首屈一指,課程組的幾位老師就算再辛苦再強調也根本沒法撲滅互測下的惡意扣分現象。相反,惡意扣分的行爲不但得不到懲罰,連被糾正都很難。不少同窗徹底被惡意扣分以後,徹底就是雖然內心很不爽,可是找不到什麼反駁的理由,只能一邊大罵測試者一邊直接申請仲裁,給助教帶來了很大的工做負擔。另外一方面,有一些同窗心術不正,視規則如無物。有的同窗在發現對方暴露了我的信息以後,即便對面只暴露了學號,他也會不辭辛勞的查找各類資料,千方百計找出這個學號對應哪位同窗,而後還把這個同窗的名字打錯了,而後狠狠訛詐這名同窗,惡意扣上十多個BUG,卻不申報無效,還無理由的掛了一個CRASH,試圖混取大量分數。在遭到申訴以後,這名同窗居然有臉說出我本能夠報你一個無效,可是我如今還要處理你的申訴,你這我的怎麼能這樣呢?這種話。做爲一個有意違反了兩條規定(故意不申報無效,惡意扣分)的同窗,可以說出這種話也是讓人很服氣的。我相信若是一個同窗不慎暴露了我的信息,他心中是能夠接受被申報無效的,由於這確實是他作的很差。可是,每個有自尊,有契約精神的同窗,都沒法容忍上述行徑。上述行爲一來是對規則的熟視無睹,這樣的測試者理應受到制裁,我的認爲與「做弊」別無二致。二來是對認真完成做業,卻不慎暴露我的信息的同窗的侮辱,由於一份完成度很好的做業,卻莫名其妙被冠以十多個莫須有的BUG,這是任何一個有自尊的同窗沒法接受的。
所以,我提議,在之後的OO課程中嚴懲這種不守規則的測試者,對亂扣BUG的行爲一經發現,兩倍扣分;對故意不申報無效的測試者,直接記測試者無效,以儆效尤。