OO博客做業4：第13-14周做業總結

1、論述測試與正確性論證的效果差別，比較其優缺點

測試是設計若干組測試用例，運行程序並檢驗其是否完成預期功能。測試是一種直接發現BUG的方法，能夠準確判定什麼樣的BUG會發生，並經過輔助調試進一步肯定發生BUG的代碼位置。測試效果取決於測試者設計測試用例的覆蓋面和針對性。

正確性論證是根據規格化設計原則，逐個檢查每一個類的屬性、方法代碼是否有違設計規格和數據保護原則，從而肯定程序的正確性和錯誤發生的位置。這種方法相對測試，其隨機性會小一些，效果主要取決於規格是否真實反映了客戶端需求以及論證者的邏輯嚴密程度。

總的來講，測試的優勢是發現BUG的證據相對確鑿，效果直接明顯。缺點是測試過程不可避免具備隨機性，並且發現BUG以後的定位工做也須要花費必定時間。正確性論證的優勢是論證體系嚴密，下降了隨機性，並可以作到更加精準的錯誤定位。缺點是對程序員的邏輯嚴密程度提出了更高的要求，且對規格的準確性有必定要求。

 

2、調研OCL語言，並比較其與課程所介紹的JSF規格之間的類似和不一樣之處

對象約束語言(Object Constraint Language, OCL)是一種用於施加在指定的模型元素上約束的語言。它是用來進行約束定義的，形式化的，無二義的語言。

類似：

二者均採用了布爾表達式來表示約束條件。

對於方法約束，兩者均借鑑了規格化設計思想，設計語法表達前置、後置條件。

不一樣之處：

JSF的語法風格接近一階謂詞邏輯公式，OCL的語法風格接近C語言。

JSF對方法規格和類規格作了嚴格的格式規定，例如方法規格必須有

/**

 * @REQUIRES:

 * @MODIFIES:

 * @EFFECTS:

 */

3個內容（前置條件、修改對象、後置條件），寫在每一個方法代碼以前。

類規格OVERVIEW必須寫在每一個類內部第一行。

而OCL在格式上靈活一些。首先利用context指明適用的類（對象），以後能夠補充關於某個屬性的約束，或是關於某個方法的前置、後置條件。換言之，OCL裏面寫些什麼，徹底是看編程者須要讓調用者明白什麼，顯得不那麼死板。

應用場景上，JSF主要做爲註釋添加在源代碼中，與特定方法或類代碼綁定。OCL能夠插入在UML圖中，或是單獨成文檔。

 

3、第15次做業：單電梯系統的UML表示

UML類圖：

UML順序圖（調度器的調度過程）：

UML狀態圖（電梯運行中的狀態轉換）：

上面UML類圖的圖表示：

4、整理總結一個學期所學所練

一、闡述四個單元模塊知識點之間的關係

第一單元 初識面向對象

本單元經過3次做業的開發，使學生熟悉面向對象式程序的基本寫法，瞭解類、對象、實例變量、方法、繼承、接口、多態這些基本概念及其實際應用。

第二單元 多線程設計與面向對象設計

本單元一是經過多線程電梯、文件系統監控這兩次做業的開發，使學生熟悉多線程程序的基本寫法，瞭解線程、線程狀態、鎖、同步化這些基本概念，體驗線程安全設計。

二是經過城市出租車調度系統開發，使學生學會根據客戶需求提煉出需求文檔，並體會SOLID設計原則對工程化開發的幫助。

第三單元 規格化設計

本單元經過在以前做業基礎上新增功能，並撰寫規格，使學生掌握規格化設計思想，實踐LSP原則，感悟客戶需求發生變化時如何儘量少地調整本身代碼以適應變化。

第四單元 測試與正確性論證

本單元基於以前做業，要求學生撰寫測試代碼以尋找以前做業的BUG，並撰寫文檔證實該程序的正確性。

 

總的來講，前兩個單元是本課程的基礎，而第三、4單元分別訓練了專業軟件工程人員兩個方面的能力。之因此說前兩個單元是基礎，一方面是後兩個單元的做業要在前面做業的基礎之上完成，另外一方面是學生只有熟悉了JAVA語言、面向對象和多線程的基本概念，具有了必定能力，才能經過後兩個單元的學習實現能力的進一步提高。第3單元訓練學生規範本身代碼的能力，以方便整個項目團隊的交流合做。第4單元訓練學生測試和論證的能力，以確保學生往後可以開發高質量的面向對象程序。

二、梳理本身所設計實現的程序，分析本身在設計、測試和質量上的進步

設計：從無到有

以前的「數據結構與程序設計基礎」課，佈置的做業都是考察特定數據結構的使用，根本不涉及程序「設計」的問題。只要看一眼題目，便大概知道須要作什麼工做。OO課佈置的做業更貼近實際工程開發，代碼規模遠超以前的程序設計課程。並且，不少做業以系列的形式呈現，更增強調一開始作出一個良好的設計。我在設計方面，能夠說經歷了一個從無到有的過程。拿到第一份做業時，我一臉茫然，由於本身已經好久沒接觸程序設計題目了，並且仍是綜合性如此強的題目。隨着本身自學JAVA語言以及學習理論課，我逐步掌握了從做業題中提取關鍵數據封裝爲類的面向對象思想，在設計之初就能大體肯定此次做業須要寫幾個類，分別完成什麼功能。

測試：逼上梁山

以前的程序設計課，在截止時間以前是能夠無限次提交的，所以本身以前通常不本身作測試，而是依靠OJ評測發現本身的問題。OO課不同，交上去只能顯示編譯經過，公測會在提交截止後進行，到那時候什麼都晚了。從那時起，我開始在提交以前測試本身的程序。可是前半學期主要是從指導書上找樣例，有時也去討論區看看別人提出的問題和測試用例，本身設計的測試用例仍是太少。進入最後一個單元，全部學生被要求使用Junit 4寫本身以前做業的測試代碼，而且還提出了覆蓋率要求。這個時候我開始苦心孤詣編寫測試代碼測試，以求達到那個覆蓋率目標。然而，本身最後仍是由於覆蓋率不足被扣了分，申訴到如今依然沒有結果。其中的緣由不得而知，可是本身在測試程序上還有很大的提高空間。

質量：更加負責

以前本身在設計程序時，基本上不考慮質量問題，由於也沒有人教給我高質量的程序應該怎樣去寫。本身對質量的認識，也只停留在程序崩潰時跳出的報錯界面。到了OO課這裏，質量問題被尖銳的提了出來，不crash成爲了基本要求。我經過聽課和自學，掌握了異常處理、數據封裝等提升安全質量的方法。同時經過第3單元的訓練，我開始在類和方法中添加註釋，幫助別人理解個人程序。

三、闡述本身對工程化開發的理解

特色1：規模大

一個複雜的軟件系統，其實現的功能是十分豐富的，這就決定了其代碼規模遠遠超過咱們所寫的任何一份做業。如何從整體上把握這項工程的脈絡，分解這一任務，顯得尤其重要。這就須要軟件工程人員準確提煉客戶需求，準確識別所需管理的數據並以類爲單位進行合理劃分，交由不一樣的人員予以具體實現。爲了保持工程總體的可維護性，也須要用到所講的SOLID設計原則。

特色2：重視合做

工程化開發的第一個特色，決定了它不可能由我的獨立完成，而必須依賴團隊的協同與合做。如何提升溝通的效率、使本身代碼被他人使用時不出問題，就須要規格化的設計與代碼實現。規格就像契約，規定了類的抽象或方法所實現的功能，並經過前、後置條件予以約束。它爲整個團隊提供了契約，使彼此合做有規可循。

特色3：存在BUG

在北航核心通識課「失敗的邏輯」上，潘星老師經過講解墨菲定律、海因裏希法則，說明了由人完成的工程項目中，錯誤和漏洞老是難以免的。工程化開發的第一個特色也決定了軟件不可避免地存在漏洞。一方面，工程團隊儘量去發現和封堵漏洞，即測試。另外一方面，工程團隊試圖經過必定論證手段，證實本身軟件的正確性，或是說明漏洞處於可控的範圍內。

 

4.4 對課程的任何指望或建議

一、備受爭議的互測機制與亂扣分現象

北航計算機學院的學生對這門課程廣泛評價不高，很大一個緣由就是尚不完善的互測機制。學生調侃這門課是面向「運氣」編程，由於課程成績一部分取決於本身分配到測試者的我的素質。測試者較爲仁慈或是測試能力有限，那麼本身有可能能獲得較高的成績。測試者道德淪喪，那麼本身就可能被瘋狂報BUG，甚至亂扣分。

當然，這些狀況課程組（尤爲是助教團隊）是清楚的。今年他們經過分類樹機制下降了功能BUG被亂報的可能。然而，對於沒法歸入分類樹的部分（尤爲是JSF規格），亂扣分的現象依然十分廣泛。這致使課程規定的訓練目標沒法定期達到，甚至出現了爲規避扣分而將大量代碼集中在一個類/方法中的現象。

建議課程組拿出「打虎拍蠅」的高壓態勢，對亂扣分者實行「封號」措施（無互測資格，甚至直接取消做業成績），起到震懾做用。學生「不想亂扣」的終極目標須要我國教育體制的深層次變革（特別是德育教育）予以實現，可是「不敢亂扣」、「不能亂扣」這兩個層次徹底是課程組經過制度完善可以實現的目標。

二、互測中的匿名機制與無效做業

爲了杜絕互測環節的權錢交易，今年課程組實行雙盲互測：要求全部提交內容必須刪除我的信息，不然測試者能夠申報無效做業。

今年測試者與被測者私下交易的狀況確實少了不少，這當然是可喜的。可是有些學生並未試圖私下交易，卻僅由於我的信息沒有刪乾淨而被報告無效做業，使人痛心。出現這樣的狀況必定是課程組制定規則時始料未及的，並且刪除我的信息也不是本課程訓練的重點，這就對這條規則的合理性提出了質疑。

改進措施1：規定發現我的信息時，必須至少找出一處BUG才能夠申報無效。

改進措施2：規定只有發現編程者的聯繫方式（手機號、微信號、QQ號、郵箱等）才能夠申報無效。

三、通知的下發

目前學生與課程助教的交流手段有兩種，一是每兩個小班創建一個答疑羣，二是經過gitlab的issue討論區。然而，課程組有時須要發佈一些對於做業的統一補充說明（如下簡稱「通知」），可是常常出現學生不能及時看到通知，做業出現一些本能夠避免的錯誤的狀況。

通知並不適合經過這兩種方式下發。答疑羣容易出現大佬水羣，並且微信羣的「羣公告」一次只能保存和顯示一條信息。ISSUE的功能偏向答疑，一些遺留問題比較多的做業都會有數十條issue，根本沒功夫看完。另外，計算機學院雖然有一個名爲「通知版」的微信羣，可是這些通知並不適合發佈在這裏，並且也沒有照顧外系的同窗。

我注意到課程網站上有「公告區」，可是自始至終這個公告區沒有發佈過一條公告，成爲了擺設。強烈建議助教團隊將它利用起來，在此區域發佈通知公告。

四、課程組對問題及時響應的問題

我理解課程組老師和助教都有本職工做，時間有限，但這不該該成爲響應不及時的理由。我遺憾地看到一些issue好久沒回復，一些申訴得不到及時回覆，問卷調查反映的一些問題課程組連個說法都不給。若是學生提出的改進建議老師連給出答覆都困難，那還作問卷幹什麼！