C#【結對編程做業】小學數學習題助手

 1、軟件成品展現

---

 

• 軟件本體下載（包括程序及其更新日誌，源碼工程包，UML圖，API接口文檔，算法介紹文檔，算式計算excel實例，淺查重程序）
  • 　　連接: http://pan.baidu.com/s/1qWP5zmG 密碼: upc5
• 計算模塊
• 運算式及答案生成
  • 　　
• 批改模塊
• 異常報告

  • • 	Type:InvalidDataException 運算符數量過大, 容易致使程序在運行計算模塊生成答案時內存溢出，所以限定數量上限爲10
      	Type:InvalidDataException 數值上界與運算符數過大，易致使算式產生超long整型範圍的分數，致使計算出錯，所以限定: Log(數值上界，2)*2*運算符數目 < 64
      	Type:InvalidOperationException 括號不匹配，容易引起越界訪問問題，實質上對應非法棧操做，所以需檢驗算式並拋出該異常
      	Type:FormatException 算式格式不正確，沒法解析
      	Type:DividedByZeroException 算式中不能出現除0操做
      	Type:DividedByZeroException 算式中分數分母不能爲0
      	Type:InvalidDataException 算式中分數的分子或分母超過long整型範圍
      	Type:InvalidDataException 在生成算式時會進行查重操做，如重複則從新生成。若是5分鐘內程序沒法生成新算式，則程序斷定生成數量達到上界，僅輸出生產部分並報出異常，這裏只有6個式子： 1+1；1-1；0+1（或1+0）；1-0；0-0；0+0
      	Type:FileNotFoundException 執行批改程序時默認讀取當前目錄下的Exercise.txt和Answer.txt文件（固然用戶也能夠瀏覽選擇本身的文件，默認編碼爲Unicode），如文件不存在則會報相應的異常

 

 

2、結對編程感想及總結

---

•  合做照片展現：
• 結對編程的感悟
• 　　兩我的一塊兒合做編程是很是愉快的事情，固然，若是不用犧牲美好的國慶假期的話。
• 　　江昊同窗負責作前端，相應的我保證後端功能正確便可，設計整個計算核心大約消耗了整整三天左右，由於前一次我的項目中已經較好的封裝了計算核心模塊，因此這幾天就是不斷地加入新的參數控制，並排查錯誤，增添異常處理等等。期間經過江昊的測試反饋，找到了不少前一次做業中仍有疏漏的bug，可見結對編程仍是頗有效率的，更新好的後端馬上就能夠拿到另外一我的寫好的前端裏檢驗，有了未經處理的異常前端也能及時給出錯誤報告，不少參數範圍不須要在後端代碼裏進行有效性檢查，前端就能夠經過輸入欄進行限制，能夠說是方便了很多。江昊寫的前端我用起來也很舒服，若是發現了問題，直接用本身從新封裝好的dll替換程序包裏的dll就能用上新的。這樣一邊設計，一邊測試，一邊更新，頗有真正開發一款軟件的感受。兩我的協做編程，不只提升了開發效率，也有助於更好地維護程序，使得咱們可以更快速的發現問題並解決問題。不過結對編程同時也要求兩我的的工做時間儘量統一，而且須要大量的溝通來確保先後端的準確對接，不只須要後端充分考慮接口調用的簡易性，也要求前端寫的界面儘量兼容各類不一樣的後端類庫，可見若是兩人的合做時間僅佔據各自獨立開發一小部分，又不增強溝通的話，結對編程的效率會大大下降，若是把由於溝通問題而把大量時間花在理解對方的代碼上，結對編程的做用就再也不那麼明顯了。
• 　　江昊同窗的優勢在於，針對我對前端提出的要求，可以很快的相應並做出修改，須要增長相應的測試單元也能很快實現，能夠說執行力很是之高；此外，善於溝通，出現問題第一時間向我反饋，使得我能夠及時做出更新修改，而且在他的幫助下咱們得以和劉乾小組，楊墨犁小組實現先後端交換對接；並且作事也頗有耐心，期間咱們的程序從v0.9.0.0一路更新到v1.1.0.7,大大小小的修改更新也有二十餘次了，可以一次又一次不厭其煩的爲我後端的更新修改相應前端的說明和測試單元，這一點我很佩服，可以與這樣的同窗結對編程我十分榮幸。固然，若是在程序設計上更細緻一些，江昊同窗會是很是完美的結對編程夥伴的。
• 　　個人缺點在於太精益求精了= =。。。本身給本身整一堆沒用的功能而後又弄出一堆bug來，而後不停地更新後端讓隊友幫忙修改前端，說實話我本身都會以爲本身有點煩23333333 固然最後的效果還算不錯，也算是解脫本身了吧，優勢的話，時間多，熬得起，動力足。

 

3、 Information Hiding, interface design, loose coupling 的應用

 

---

 

• Information Hiding
• 　　信息隱藏，與面向對象的封裝概念較爲相似，我做爲負責後端的程序員，主要作的就是封裝的工做，儘量避免重要信息外泄給調用者，從而引起不可預測的異常，我在本身編寫的後端dll文件中，經過如下幾種方式體現這一設計方法：
• 1.　　除了提供接口的core類外，其它類都用默認的internal修飾符修飾，使得除core類外，其它類都不可實例化，做爲dll應用時不可見
• 2.　　core類的全部屬性所有用private修飾，僅能經過接口函數select訪問並修改
• 3.　　儘可能避免經過返回值或ref修飾的返回參數來向外傳值，在內部處理產生的全部信息，向外部提供的信息僅限於拋出異常，設計接口時大部分爲void方法
• Interface Design
• 　　接口設計，接口是用於交互的，因此在設計接口時，主要須要考慮的是，「咱們會接受哪些信息」和「咱們須要反饋哪些信息」，有些接口，好比生成表達式，既不須要接受信息也不須要反饋（固然拋出異常除外），那就設計成不接受任何參數的void函數，我理解的接口設計圍繞兩個字展開，那就是「摳門」，既不過多向前端請求一些無用的信息，也不向前端反饋一些不便於處理的內容，將信息處理儘量集成到dll內部，全部的參數都設置的恰到好處。固然設計接口最後在瞭解用戶需求的狀況下與前端設計者達成協議，這樣也有便於本身的設計。C#能夠爲傳入的參數設置默認值，這樣傳入參數的時候若是少傳了也能夠正常使用，固然咱們也能夠經過重載函數來實現。靈活的接口設計，既要作到信息精簡，也要作到普遍兼容。我在最上面的程序包裏提供本身的API接口說明，試着寫這樣一份文檔也有助於我更好的幫助本身反思接口設計須要注意的一些地方。
• loose coupling
• 　　鬆耦合，鬆耦合要求最小化依賴，實現可伸縮性、靈活性和容錯。這一點不只僅是對於後端，對於前段也有很高的要求。對於後端而言。須要在API接口設計上作到普適，提供各類重載的方法來應對不一樣的應用場景，並在內部處理好異常信息，使得使用者調用時或者不出錯，或者一旦出錯，後端裏也爲其寫好了處理函數，獲得的是通過處理的異常信息，有明確的錯誤定位。對於前端而言，須要作好輸入規範，須要考慮從UI得到的各類信息並設計相應的數據結構，以便傳遞給不一樣的後端程序，對於後端拋出的異常須要採用統一的處理方案，並儘量避免本身發生異常，從而保證傳入後端的參數是始終有效的。只有作到這一點，後端才能對接更多的前端，前端才能應用於更多的後端。不過鬆耦合設計的代價會有不少冗餘性的工做，若是隻是開發私人項目，不須要作太多維護工做的話，鬆耦合並不是十分必要。
• 　　在咱們的結對編程項目中，實現了鬆耦合，咱們的後端與楊墨犁小組的前端，咱們的前端與劉乾小組的後端分別實現了完美的對接，下面是截圖：
  • 　　與楊墨犁小組的前端對接：
  • 　　
  • 　　與乾麻小組的後端對接：

 

4、Design By Contract

 

---

• 契約式設計，就是把類和他的客戶程序之間的關係看作正式的協議，描述雙方的權利和義務，被Bertrand Meyer稱做構建面向對象軟件系統方法的核心。

  契約式設計的提出主要基於軟件可靠性的考慮，包括正確性與健壯性。正確性指軟件按照需求規格執行的能力，健壯性指軟件對需求規格中未聲明情況的處理能力。健壯性主要與異常處理機制相關。契約即客戶按照需求規格使用軟件，軟件設計者按照需求規格設計軟件，需求規格以外的請求形成的軟件使用錯誤責任不禁軟件設計者承擔。契約式設計是一套機制，在客戶稱須要提供者之間明確地聲明雙方的責任與權力，即契約，並可以對這些契約進行驗證。

  咱們在「小學數學習題助手」軟件開發過程當中，對於絕大部分正常請求給予支持，並進行了正確性驗證。對於極端狀況的數據，好比生成題目數量很是大而生成數值上限與運算符數量很是小的狀況，咱們進行了響應的異常報錯處理機制，並設計良好的用戶交互，通知異常緣由。咱們的軟件開發過程實際上是在遵循契約式設計的原則。

  契約式設計的原則的優勢在於，確保了server與client地位的平等，雙方有各自的義務與責任，這樣就保證了代碼的質量，提升了軟件工程的效率與質量。

  契約式設計也有缺點，那就是契約式設計須要一種機制來驗證契約的成立與否，斷言就是最好的選擇，但並非全部的程序語言都有斷言機制，那麼強行使用語言進行模仿就勢必形成代碼的冗餘和不可讀性的提升，好比.NET4.0之前就沒有assert的概念。

 

5、 Unit Test

---

• 經過單元測試，咱們完成了對程序基本功能（計算，表達式生成，批改，讀入參數）的檢驗，併成功捕捉到錯誤輸入時相應的各種異常（見前面展現部分），展現圖以下所示：
• PS：UML圖和算法核心思想在頂部程序包裏，歡迎自取ww