目錄

• OO Unit3 UML conclution
  • 總結本單元兩次作業的架構設計
  • 總結自己在四個單元中架構設計及OO方法理解的演進
  • 總結自己在四個單元中測試理解與實踐的演進
  • 總結自己的課程收獲
  • 立足于自己的體會給課程提三個具體改進建議

OO Unit3 UML conclution

總結本單元兩次作業的架構設計

第一次作業類圖

第二次作業類圖

• 兩次作業的不同之處

  我認為第一次作業主要針對類圖進行詳細而且周全的理解和分析，有各種UML元素的統計和建模。

  第二次作業主要在于廣度，建立三個不同的UML圖，并且有三個規則的check，這三個check可以乍一看比較復雜，其實都可以轉化為圖以較快地完成。

• 架構設計

  第一次作業，因為只有一種圖，即所有的元素都屬于這個圖，并且一個圖中有多個UMLClass類。所以我的做法是，將一個類中所有的成員——參數(Parameter)、屬性(Attribute)、接口(Interface)、關聯(Association)等都放進一個類(MyClass)中。類與類之間的關聯，比如繼承關系、接口實現關系、關聯關系等，由于是兩個或兩個以上類參與的過程，因此在交互類(MyUmlInteraction)中實現。

  第二次作業，因為有三種圖，因此，用三個類：MyClass、MyStateMachine、MyInteraction來建模三種圖；用三個交互類MyUmlClassModelInteraction、MyUmlStateChartInteraction、MyUmlCollaborationInteraction分別來協調類圖、狀態圖、順序圖之間的關聯。

• 流程設計

  主要是第二次作業的架構相應的代碼流程實現。

• 根據每個diagram出現時，在最開始會有UMLClass元素或者UMLInteraction元素或者UMLStateMachine元素，以此來分割每個圖及其對應的元素。

• 當收集完一個圖的元素時，開始建圖，建完圖后將一張圖表示的這個類放入對應的交互類中。設置好對應的查找方式。

• check并開始指令。

• 主要算法

  • 01矩陣的floyd(用于checkForUml008())

    • 初始化：有直接繼承關系的類或接口其矩陣元素為1，即matrix[i][j]=1表示i直接繼承j。

    • floyd：當i是mid的其中一個子類，mid是j的其中一個子類，那么i是j的其中一個子類，則將i繼承j的元素置1。即

    • if (check008floyd[i][mid] == 1 && check008floyd[mid][j] == 1) {check008floyd[i][j] = 1; }

    • 運算結果：矩陣對角線元素為1的表示成繼承環，包括自環。

  • 到達路徑數的floyd(用于checkForUml009())

    • 初始化：直接繼承或直接接口實現的次數，即matrix[i][j]表示i直接繼承j的次數，或i直接實現了j接口的次數。

    • floyd：從i到j的可能數 = \old(從i到j的可能數) + 從i到mid的可能數 * 從mid到j的可能數。元素0表示從i繼承或接口實現j的可能數為0，因此可以無條件執行更新語句。即

      matrix[i][j] += matrix[i][mid] * matrix[mid][j];

    • 運算結果：矩陣元素表示從i到j的可能數，即類或接口i繼承接口j的次數，如果元素等于0，表示類或接口i不繼承接口j。如果元素大于1，表示類或接口i多次繼承接口j。

  • 繼承關系dfs(用于找父類)

    • 初始化：matrix[i][j]=k表示類i繼承的第j個父類為類k。
    • 遞歸：
      • 如果還未到j_max，則繼續遞歸下一個父類。
      • 如果到達j_max，則返回，記錄頂層父類，并且將父類的屬性、參數、關聯關系、接口等需要傳遞給子類的東西傳遞給下一層它的子類。
      • 以此類推，將上層父類的需要傳遞的東西一層層傳遞給他的子類，直到最底層。這樣，遞歸一次，可以將沿途經過的類的繼承關系都處理好。

總結自己在四個單元中架構設計及OO方法理解的演進

經過四個單元的練習，我對"面向對象”有了更加深刻的認識。

第一個單元表達式計算，因為題目本身難度不大，用什么方法、架構完成都可以，所以每個人的代碼思路都不同。對“對象”和“類”的劃分也各有各的邏輯，對我個人來說，在第一單元，面向對象的手法基本沒用上，整個程序還是非常的面向過程，對象所擁有的屬性、對象所屬的類的劃分都很混亂。雖然將表達式個體當成了分別獨立的各個對象，但是計算處理過程還是很面向過程，以致于在化簡、優化過程中碰到了很多困難。

在第二單元多線程電梯，我試圖將電梯、請求、控制器、總交互平臺分別劃成各個類。但是在實現過程中，還是將本該交給控制器類的任務交給了電梯類或者請求類。雖然在建模的時候對整個程序有一個比較明確的計劃和框架，但是在實現過程中還是碰到了諸多困難，以至于我選擇將一些不該放在這個類的方法或者數據成員放在了這個類中，方便處理，但導致了架構混亂。

在第三單元JML主要是規格撰寫，使我對測試方法有更深刻的認識。同時，因為規格的撰寫，我更加熟練了將特定的任務群劃分給某個類，將某一個任務劃分給某個方法來完成。這一單元的層次非常清晰，可以說更加印象深刻地、直觀地感受到了所謂的層次清晰。

第四單元UML，隨著面向對象思想觀念的深入，我開始思考如何用更清晰的、更簡單的類來表示題目要求的各類對象。把實現的各部分劃分成不同的責任單元，建立各個類來分別負責完成各自的任務，并合理交互。從架構方面來說，可以說是第三單元的延續，非常清晰的層次，即交互類和圖類。

總結自己在四個單元中測試理解與實踐的演進

在第一單元的表達式計算中，我對測試的理解僅限于構造完整的測試集，就是要走遍每一條代碼、走遍每一個分支或者條件選擇語句。在劃分等價類的時候，要把各個可能的組合都劃分開并且測試充足。

在第二單元的多線程中，因為多線程的特殊性，測試也更有難度，每次同樣的測試數據跑出來的結果是不同的，所以在測試的時候要充分考慮到線程的執行順序、速度等不可控因素的影響。很有可能某一種執行順序是無法測試到或者無法重演的，那可以進行大規模的測試，或者先進行邏輯上的推演，并且加入一些語句來人為控制線程執行的順序，確保在實際的程序運行過程中，每一種可能的順序都不會導致結果出錯。

在第三單元JML中，才算是對測試方法有了更全面并且正確的認識。尤其是對于等價類的劃分，可以使得測試數據作用明確、定點投放、避免重復，實現更加高效的測試。并且，由于規格的撰寫，可以很方便地羅列出可能會出現問題的輸入可能、輸出可能、以及方法內部的邏輯問題。在實現代碼之前先進行規格和作用的設計，可以不受到代碼細節的干擾，確保每個方法 的正確性。在測試時則根據事先約定的規格，對可能的漏洞進行針對性地設計測試集。

在第四單元UML中，它的測試主要是對于邊界情況、復雜情況的處理。比如重復繼承、循環繼承等，在遞歸或者遍歷算法的過程中要注意。相比第二單元的各種不可控、不可預知情況，第四單元更重要的似乎是邏輯和理解上的正確性，并且進行白盒測試。

總結自己的課程收獲

OO課程如同登山，步步為營，一點點地提升，讓人很有成就感。回首學習OO的一個學期，可以說每一次作業都做到了盡心，雖然有時候還有bug，但是總的來說還是相對完整的回憶。

相比完成了各個單元的那么多份代碼，更重要的是確實學到了很多架構思想、測試方法、debug方法等在以后的寫程序過程中非常有用的事情。

雖說自始至終我都喜歡把程序寫得盡可能清晰并且邏輯簡單，因為我認為越直白簡單的邏輯越不容易出錯，但直到現在，做完了最后一個單元的最后一次作業之后，回憶起第一單元的程序架構，還是覺得當時的想法還太復雜，還可以更加簡單一些。這也可以認為是四個單元的訓練之后，在實現自己的理想狀態上的一些小進步吧。當然，從規格和規范性而言，并不是越簡單越好，我只是就復雜和簡單來說。

立足于自己的體會給課程提三個具體改進建議

指導書明確。明確到不需要在討論區對指導書定義的問題進行詢問和討論。

要求每一次作業都寫明自己的大體架構，方便互測時的同屋同學代碼閱讀與理解。

及時公開優秀代碼并且有相應的架構說明。有些同學的代碼過于優秀，一下子難以理解。

研討課的討論性不夠，希望可以學習更多優秀架構和思想。

轉載于:https://www.cnblogs.com/ffchyan/p/11047481.html

總結

以上是生活随笔為你收集整理的OO Unit4 UML的全部內容，希望文章能夠幫你解決所遇到的問題。

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