OO做業總結報告3

規格化設計的發展史

      下面部分來源：http://www.javashuo.com/article/p-dvayqrwx-eq.html；

　　隨着計算機硬件的飛速發展,以及應用複雜度愈來愈高,軟件規模愈來愈大,原有的程序開發方式已經越 來越不能知足需求了。1960 年代中期開始爆發了第一次軟件危機,典型表現有軟件質量低下、項目沒法 如期完成、項目嚴重超支等,由於軟件而致使的重大事故時有發生。

       1975年，Liskov等人發表了論文Specification Techniques for Data Abstractions，從數據抽象的角度論述了規格的優勢、特性及重要性。

       1976年，在第二屆國際軟件工程會議上，Belford等人在Specifications a key to effective software development一文中從開發複雜系統的角度論證了完整的、一致的規格的重要性。在系統研發週期中，規格提供了在概念和定義階段的過渡。一個清楚、無歧義的規格是取得成功的關鍵，同時能減小開發過程當中的開銷。軟件需求自己具備模糊的特色，因此須要一個定義明確的規格來開發出可靠的軟件。

       1993年，Liskov等人發表了Specifications and their use in defining subtypes，從類型層次的角度進一步論證了規格的重要性。

       現在，北航的OO課程組也十分重視規格化的設計，提出了JSF規格設計，而且將其應用到計算機學院的面向對象課程中，讓同窗們更加深入的理解到程序規格化設計的重要性。

       可見，程序的規格化設計在計算機長期的發展中不斷的完善和受到重視。

BUG分析

1.bug記錄表

類型	方法代碼行數	產生緣由
EFFECTS內容爲實現算法	15	內容表達的有些多
不符合JSF規範	23	線程規格寫錯誤
REQUIRES邏輯錯誤	21	沒寫requires
不符合JSF規範	10	沒寫requires

 

 

 

 

 

2.功能性bug

　　出租車會回頭，緣由是GUI的流量刷新有延遲，出現線程不安全的問題，因此訪問的數據不是最新的數據，致使車會回頭；

　　出租車在去接單時沒有模擬乘客上車，緣由是沒有搞清楚具體要求；

　　出租車輸出的信息是搶單時刻的狀態信息，測試者說是搶單窗口結束時的出租車狀態，指導書中只說了輸出搶單出租車信息，可是issue中有提到，，認栽，，沒有勤刷issue.

　功能性bug和jsf在我這個水平的來看，，好像並無什麼較大的聯繫，可是我的以爲設計規格仍是十分重要的，若是有較好的規格的話，提供了從理論推理上來發現和避免bug的方法。

 

規格很差的寫法

1.缺乏REQUIRES

改進後：

 

2.後置條件格式錯誤

改進後：

 

3.前置條件書寫不規範

改進後：

 

 4.this使用未添加「\」

改進後：

總結與體會

　　從這門課裏，與其說是學到了不少技能，不如說是懂得了何爲重要。面向對象的編程思想很重要，規格化的程序設計很重要，設計原則很重要，工程化的思惟方式很重要。一學期的訓練中，咱們能夠看到老師們訓練的重點在哪裏，也獲得了較好的鍛鍊，可是因爲制度的不健全，可能在實施訓練計劃的時候每每會出現誤差。同窗中有部分遭到惡意扣分，固然這不是僅僅咱們這一屆有，指導書不夠明確，模棱兩可，助教很辛苦，同窗們的體驗不夠好，在這裏，我是十分贊同昂神（大佬）所說的關於工程的見解，可是OO這門課的相關測試有時候卻又讓人不得不去糾結一些細節，其實不少地方是能夠readme的。

　　有的時候說提出問題，發現問題是最重要的，但有的時候又說提出問題很簡單，真正解決問題纔是最難的，因此究竟是如何，不知。就這門課，同窗們在實踐中提出了不少問題，但我發現能想到一個真正完美的解決方案仍是挺難的。據說課程組最後會有一個最多BUG獎項，可是不知道有沒有最具建設性意見獎項，若是有，說不定哪位同窗就真的會提出很是不錯的意見呢，也許當同窗們知道解決問題難的時候，就會少一些抱怨吧。

　　學習是本身的，分數是別人的，最後仍是但願全部努力認真的同窗都可以取得不錯的分數。