一、UML作業架構設計

1、第一次作業

?其中 Main 是入口類，MyUmlinteraction實現了接口，UmlInteractionBase為MyUmlinteraction實現提供了底層功能，MyClass和MyMethod是一些UML元素的包裝。下面是具體實現。

?

2、第二次作業

自己對三類不同的UML圖分別進行了建模。另外自己將接口實現和核心功能提供分開處理。最后運用組合設計模式來實現總的功能。

?

二、四個單元中的架構設計及OO方法理解的演進

1、第一單元

自己第一單元并沒有使用什么框架，主要是使用了接口作為各種函數的類型而可以統一處理，這樣節省了許多無聊代碼。

2、第二單元

自己的設計基于 blockqueue 框架。且三次作業都是同一個設計策略。

核心數據結構是一個阻塞隊列，用于保存請求隊列，其他模塊主要是與該隊列交互。

請求生成器：用于獲得請求，并將請求加入請求隊列。

請求調度器：用于將請求派給不同的電梯。

電梯：用于處理被分配的請求。

在第二次作業時，只是修改了電梯對于執行請求的策略，增加了捎帶功能。

在第三次作業時，只是復制了兩部電梯，其行為模式完全相同，但是請求調度器給其分配的請求種類有差別。另外，乘客在下電梯時，若其沒到最終目的地，則由電梯修改其出發地后將請求加入隊列。請求調度器無法區分由電梯加入的請求和請求生成器加入的請求。

3、第三單元

自己使用了分層接口來分解功能，并分層實行，使得可以把一個復雜的功能分解為從低層到高層的功能來逐步實現，易于實現和維護。

4、第四單元

自己將三種UML圖分別建模，然后在一個總UML模型類中組合這些不同的UML圖。

三、四個單元中測試理解與實踐的演進

1、第一單元

自己沒有采用系統性的測試策略來覆蓋所有代碼執行路徑，只是隨機想了幾個數據點。在代碼簡單時這種策略似乎還可以，但是在代碼稍微復雜一些時，我為此吃了苦頭：自己互測時被?的好狠啊，結果只要一行代碼就全部搞定了。如果自己做了覆蓋性測試，就不會這樣了。就是這個單元，讓我明白了測試的重要性，讓我明白了測試是代碼編寫的不可分割的重要一部分。

2、第二單元

這個單元我用了單元測試，可是對于多線程測試，確實發現其測試非常棘手。并且對于互測中發現的bug自己無法復現。這讓我明白，如何做好測試也是非常需要思考的。如何看出bug樣例的模式，并用最簡單的樣例復現錯誤，這是非常功夫的。

3、第三單元

第三單元我用了單元測試，并且使用了一定的測試策略，這次的效果還是可以。但是這個單元其實是JML的形式驗證，但是自己感覺這個并不能很好發現bug。往往寫出正確的規格需要對問題的很好理解，而bug的原因有很多是對問題的理解程度不夠，因此我感覺JML規格除了讓機器幫忙檢查代碼一致性問題外，在自己手中并不能發揮很大的作用。

4、第四單元

由于是在考期，自己沒時間進行覆蓋性測試，第一次還好，第二次就果然涼涼！看來自己必須把測試看作是編碼的一部分，或許可以考慮先寫測試。

四、課程收獲

這學期的OO自己感覺學到了不少東西。首先自己學會了java語言的基本操作。并且自己學會了OO的思想，學會了多線程編程，還了解了JML和UML。回想自己奉獻給OO的多少個周末，多少個凌晨，現在回想起來，感覺還是頗值。

五、具體改進建議

1、實驗作業的定位不夠清晰。這學期早上學習新內容，下午做實驗，但是自己做完實驗后是懵逼的，感覺時間很緊。個人覺得如果實驗的目的不是考核，而是幫助理解所學內容的話，應該允許實驗內容沒有做完的可以課后繼續做，且給出答案，這樣利于進步。

2、JML單元感覺有些不夠完善。自己是體驗了不少內容，可是只是限于體驗而已。

3、研討課交流環節互相可以改為小組交流或者代碼評審。

轉載于:https://www.cnblogs.com/yorkyer/p/11079169.html

總結

以上是生活随笔為你收集整理的OO第四单元博客作业的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。