測試是根據程序的功能預判可能的輸入與輸出,分門別類,對一個完成了所有或部分功能、模塊的計算機程序在正式使用前的檢測,以確保該程序能按預約的方式正確地運行。算法
pros:編程
根據程序的用途設計,針對性強;網絡
一個好的測試用例有可能發現不少的錯誤,會很高效;多線程
cons:框架
設計感強,考驗測試人員的能力;學習
容易仍然遺留一些不易發現的bug;測試
正確性論證是論證程序達到預期目的的通常性論述,與特定值無關,甚至可以表明窮舉性測試。Dijkstra說過「程序測試只能證實程序有錯,不能說明程序正確」。這也就是正確性論證的重要性。ui
pros:線程
在須要絕對保證正確的領域中有很大做用;設計
更爲嚴密,至關於測試中的窮舉測試;
保證程序正確的惟一途徑
cons:
目前這種方法仍然不夠完善;
能真正掌握的軟件人員也很少;
OCL(Object Constraint Language)語言。一個約束就是對一個(或部分)面向對象模型或者系統的一個或者一些值的限制。UML類圖中的全部值均可以被約束,而表達這些約束的方法就是 OCL。
OCL取了天然語言和數學符號的折中方案,使用普通的ASCII字符來表達數學中一樣的概念。
OCL是一種聲明式語言,大部分表達式執行後會返回一個布爾值,也有一些表達式會用來選擇一個單一值或者一個對象/值的集合。
OCL結構
JSF(Java Semi-Formal Specification Language)是一種規格。與OCL語言有必定的類似之處,可是主要針對的是方法的規格,即過程規格。
從總體上把握住一個方法對外部的要求(Requires)、 對外部的承諾(Effects)和方法要修改的系統狀態和對象狀態(Modifies);
必定不能在Effects部分撰寫控制流程或算法流程,而是方法執行 後用戶得到的效果;
Effects必定要歸納方法在不一樣輸入形態下的多種執行效果;
UML類圖
時序圖
狀態圖
程序構造圖
4.1闡述四個單元模塊知識點之間的關係
最開始的一個單元先介紹了面向對象的設計思想,知道了它在程序設計上與過程式規劃有何不一樣以及魯棒性的重要性。以後就是很是重要的多線程設計,其中各類鎖的放置,同步機制的應用也是十分重要。後來逐漸抽象起來,將程序的過程進行抽象,即先搭起程序的框架,不在意具體的算法,所以,學習了JSF規格的撰寫,只爲將方法進行抽象。最後,程序完成後的步驟就是測試了,先是編寫測試數據來覆蓋全部的測試狀況,後來用形式化的語言進行論證。
4.2梳理本身所設計實現的程序,分析本身在設計、測試和質量上的進步
在一個學期的練習後,思考一個問題的解決辦法時,開始考慮如何用面向對象的思想去解決。思考與構建程序框架的時間會大於完善方法主體的時間,而且試圖構建出更好的方式,以便將來的擴展。
4.3闡述本身對工程化開發的理解
將系統化,規範的,可度量的方法應用於軟件的開發、運行和維護的過程就是程序的工程化開發。工程化開發的目的在於提升程序的質量,主要有如下幾個方面:
正確性(Correctness):依據規約 完成任務
魯棒性(Robustness):異常狀況 合理反應
完整性(Integrity):非法訪問或修改 合理反應
易擴展性(Extendibility):軟件產品應規約改變而改變
易複用性(Reusability):軟件模塊 用於構建多種不一樣應用
兼容性(Compatibility):軟件模塊相互組合的難易
高效性(Efficiency):儘可能少地使用硬件資源 處理器時間 內存 外存 網絡帶寬 等
易移植性(Portability):轉換到不一樣的軟硬件平臺上
易用性(Ease of use):不一樣背景的用戶學習使用軟件產品解決問題的難易
以及在Java開發中的六大原則:
單一職責原則(Single Responsibility Principle, SRP):一個類只負責一個功能領域中的相應職責,或者能夠定義爲:就一個類而言,應該只有一個引發它變化的緣由。
開閉原則(Open-Closed Principle, OCP):一個軟件實體應當對擴展開放,對修改關閉。即軟件實體應儘可能在不修改原有代碼的狀況下進行擴展。
里氏代換原則(Liskov Substitution Principle, LSP):全部引用基類(父類)的地方必須能透明地使用其子類的對象。
依賴倒轉原則(Dependency Inversion Principle, DIP):抽象不該該依賴於細節,細節應當依賴於抽象。換言之,要針對接口編程,而不是針對實現編程。
接口隔離原則(Interface Segregation Principle, ISP):使用多個專門的接口,而不使用單一的總接口,即客戶端不該該依賴那些它不須要的接口。
迪米特法則(Law of Demeter, LoD):一個軟件實體應當儘量少地與其餘實體發生相互做用。
要儘可能經過這些原則實現上述對程序質量的要求。
4.4對課程的任何指望或建議
在我看來,目前的機制也相對完整,可是很明顯,這門課程仍然在探索的路途中。
首先,關於指導書的問題。誠然,咱們以後不會遇到更好的指導書,可是,一個粗略的指導書勾勒出大致的框架,據此完成的程序天然是每一個人有不一樣的完成方式,甚至有不一樣的結果,天然,這門課的測試須要一個統一的標準,這是不可能用一個粗略的指導書完成的。那麼,在這個中間有一片灰色區域,就是readme。
我的信息的問題。提供統一的方式進行我的信息的刪除。
最後,我居然有個獎,抱枕超級舒服,game changer!