目錄

• OO Unit3 UML conclution
  • 總結(jié)本單元兩次作業(yè)的架構(gòu)設(shè)計
  • 總結(jié)自己在四個單元中架構(gòu)設(shè)計及OO方法理解的演進
  • 總結(jié)自己在四個單元中測試?yán)斫馀c實踐的演進
  • 總結(jié)自己的課程收獲
  • 立足于自己的體會給課程提三個具體改進建議

OO Unit3 UML conclution

總結(jié)本單元兩次作業(yè)的架構(gòu)設(shè)計

第一次作業(yè)類圖

第二次作業(yè)類圖

• 兩次作業(yè)的不同之處

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

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

• 架構(gòu)設(shè)計

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

  第二次作業(yè)，因為有三種圖，因此，用三個類：MyClass、MyStateMachine、MyInteraction來建模三種圖；用三個交互類MyUmlClassModelInteraction、MyUmlStateChartInteraction、MyUmlCollaborationInteraction分別來協(xié)調(diào)類圖、狀態(tài)圖、順序圖之間的關(guān)聯(lián)。

• 流程設(shè)計

  主要是第二次作業(yè)的架構(gòu)相應(yīng)的代碼流程實現(xiàn)。

• 根據(jù)每個diagram出現(xiàn)時，在最開始會有UMLClass元素或者UMLInteraction元素或者UMLStateMachine元素，以此來分割每個圖及其對應(yīng)的元素。

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

• check并開始指令。

• 主要算法

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

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

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

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

    • 運算結(jié)果：矩陣對角線元素為1的表示成繼承環(huán)，包括自環(huán)。

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

    • 初始化：直接繼承或直接接口實現(xiàn)的次數(shù)，即matrix[i][j]表示i直接繼承j的次數(shù)，或i直接實現(xiàn)了j接口的次數(shù)。

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

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

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

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

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

總結(jié)自己在四個單元中架構(gòu)設(shè)計及OO方法理解的演進

經(jīng)過四個單元的練習(xí)，我對"面向?qū)ο蟆庇辛烁由羁痰恼J識。

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

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

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

第四單元UML，隨著面向?qū)ο笏枷胗^念的深入，我開始思考如何用更清晰的、更簡單的類來表示題目要求的各類對象。把實現(xiàn)的各部分劃分成不同的責(zé)任單元，建立各個類來分別負責(zé)完成各自的任務(wù)，并合理交互。從架構(gòu)方面來說，可以說是第三單元的延續(xù)，非常清晰的層次，即交互類和圖類。

總結(jié)自己在四個單元中測試?yán)斫馀c實踐的演進

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

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

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

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

總結(jié)自己的課程收獲

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

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

雖說自始至終我都喜歡把程序?qū)懙帽M可能清晰并且邏輯簡單，因為我認為越直白簡單的邏輯越不容易出錯，但直到現(xiàn)在，做完了最后一個單元的最后一次作業(yè)之后，回憶起第一單元的程序架構(gòu)，還是覺得當(dāng)時的想法還太復(fù)雜，還可以更加簡單一些。這也可以認為是四個單元的訓(xùn)練之后，在實現(xiàn)自己的理想狀態(tài)上的一些小進步吧。當(dāng)然，從規(guī)格和規(guī)范性而言，并不是越簡單越好，我只是就復(fù)雜和簡單來說。

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

指導(dǎo)書明確。明確到不需要在討論區(qū)對指導(dǎo)書定義的問題進行詢問和討論。

要求每一次作業(yè)都寫明自己的大體架構(gòu)，方便互測時的同屋同學(xué)代碼閱讀與理解。

及時公開優(yōu)秀代碼并且有相應(yīng)的架構(gòu)說明。有些同學(xué)的代碼過于優(yōu)秀，一下子難以理解。

研討課的討論性不夠，希望可以學(xué)習(xí)更多優(yōu)秀架構(gòu)和思想。

轉(zhuǎn)載于:https://www.cnblogs.com/ffchyan/p/11047481.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。