第四次博客做業

第四次博客做業

16061189 於金澤

1. 測試與正確性論證

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

測試：

我的理解測試的做用是經過構造相應的測試用例。實現對代碼中的語句和分支的覆蓋，以此證實代碼的實現的正確性，測試代碼執行的結果與預期數據相匹配。重點在於測試樣例集的正確性以及構造樣例的複雜性和邊緣數據等，所以測試依賴於測試數據的覆蓋率以儘量實現更加充分的測試，若是測試不充分，則沒法發現隱藏的bug，同時即便測試經過也沒法證實沒有bug的存在。

正確性論證：

正確性論證依賴於代碼邏輯和算法的正確性，經過論證，證實本身代碼的實現與所預期的正確的算法過程相匹配。所以，經過正確性論證理論上能夠保證代碼中沒有bug的存在。可是，正確性論證須要的時間成本和人力成本太高。

2. OCL語言

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

對象約束語言(Object Constraint Language)，簡稱OCL，是一種指示用戶建模系統中的限制方式。 在對象約束語言中，對象表明了系統的組件，它定義了完善的項目，約束表明限制，而語言並不是是指一種正式的計算機語言。

OCL是一種形式語言，能夠應用於任何實現方式的非正規語言。對象約束語言對UML中圖形或其餘組件都沒有控制權，它只是在使用時返回值。OCL並不能修改對象的狀態，而是用來指示對狀態的修改什麼時候發生。

OCL表達式以附加在模型元素上的條件和限制來表現對該對象的約束，其中包括附加在模型元素上的不變量或約束的表達式、附加在操做和方法上的前置條件和後置條件等。

OCL語言雖然是一種形式化語言，可是它既具備形式化語言無二義性的特色，又消除了形式化語言的複雜性。

OCL與JSF相比，約束條件更加充分並且有更高的要求，可是與JSF相比，較爲臃腫，JSF更爲簡潔可是在各方面的要求不高並且不夠明確。

3. 第十四次做業

根據第十四次做業的單電梯系統，針對調度器、電梯、請求隊列和請求，至少整理出一幅UML類圖、一幅順序圖和一幅狀態圖，並使用圖(graph)來表示出模型

4. 整理總結

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

本課程的四個單元：

1. java基礎語法和麪向對象基本思想
2. 多線程程序設計
3. 抽象和程序規格
4. 單元測試和正確性論證

四個單元的知識點由淺入深，逐漸從入門向深，從簡單的程序逐漸向一個較爲完整充分的小型項目遞進

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

在本學期以前，由於已經選過面向對象的先導課而已經接觸了一些面向對象編程的思想，可是當時尚未接觸過項目開發等方面的內容，並且對於編程理解等內容也不夠深。

所以，在程序設計方面，經過一整個學期的折磨，在程序設計、代碼流程設計等方面有了一些進步，在第十四次做業重構本身第三次做業的代碼時，感受本身第三次的代碼不管是風格，單個方法代碼行數等方面都不如如今，每一個類的功能、屬性等不夠明確，對於java自帶的一些方法的使用也不夠靈活。

在測試和質量方面，穩定性和可讀性都有所提升，雖然我的以爲在算法等方面沒有什麼進步，依舊是靠本身幹想實現的，可是和之前相比，由於更爲了解一些可能出現的問題、可優化之處，因此從代碼來看應該是有所提升的，尤爲是多線程編程方面。

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

1. 在工程開發時，須要注意代碼的可重用性和可讀性，所以在代碼構建的過程當中須要注意在以後本身閱讀代碼、重構代碼時的可行性，不要給本身增長負擔；並且也要考慮到在讓別人後續閱讀、維護本身代碼的負擔，影響遵照必定的規範
2. 本身編寫的程序，須要提供較爲完整的文檔說說明，以供後續的編程人員維護，以及使用者使用
3. 爲了團隊協做和我的開發等方面，

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

1. 雖然以前學習過面向對象的先導課，可是仍是要說，一上來就假定全部人都瞭解java語法，會使用java進行編程真的是太折磨了
2. 課上對於JSF的講解徹底不夠，不知道怎麼寫，應該是怎麼樣的，而是「到時候會發JSF的說明，大家本身看就行了」一言以蔽之。可是JSF的說明中，只有關於JSF的內容而沒有與代碼的結合，並不能體會到如何將JSF與代碼對應。並且通過一節課，而後就要求同窗們可以徹底理解並使用JSF，使用規格設計的相關內容徹底是不現實的，只是加以介紹而後就要求徹底掌握並可以給已有代碼加上JSF的要求我的看來是難以理解的。
3. 但願老師和助教可以明確做業指導書的要求，即便沒法作到徹底消除二義性，也請有統一的、明確的理解與要求，在有人提出issue時有明確、先後不產生矛盾的回覆，而不是有人提出一個issue，說是否是怎麼怎麼作更好啊，而後就要求全部人按照他的理解進行實現。
4. 另外，也請維護一個實時更新的在線文檔等，把全部的補充內容進行明確，在已有的基礎上不斷修改，而不是像如今這樣，這種要求散落在各個issue、助教羣回覆等內容中，常常致使有些測試者死摳issue、面向文檔debug，以及不一樣班級要求不一樣的問題，例如，對於紅綠燈而言，有四個班要求全部紅綠燈的方向一致，即全部紅綠燈都爲東西方向容許經過，而咱們班的要求是全部紅綠燈的變化時間一致，可是初始狀態隨機指定，即同一時刻有些紅綠燈容許東西方向另外一些容許南北方向。而後在和助教確認要求究竟是怎麼樣的時候，助教回覆「哦，readme「。

強烈建議助教維護一個在線文檔或者公開置頂的討論帖，實時更新新增和修改的內容，以供助教本身和學生查驗。