BUAA-OO-第四單元-UML層次化設計、課程總結

1、第四單元做業架構分析

　　面向對象-UML層次化設計

更多參考：http://www.javashuo.com/article/p-fgcthskj-da.html
http://www.javashuo.com/article/p-ovmgsvmj-cq.html

UML順序圖http://www.javashuo.com/article/p-xnhtilmq-cb.html
UML狀態圖https://blog.csdn.net/w36680130/article/details/81014032

　　經過StarUML和notepad++工具查看並總結

 

　　UML將類(class)、接口(interface)、方法操做(operation)、屬性(attribute)等都視爲對象元素（UMLelement），UMLModel容器管理着模型的全部元素

• • UMLClass 對應用戶所構造的類
  • UMLAttribute 對應用戶構造的類的屬性
  • UMLAssociation 對應用戶構造類之間的關聯性
  • UMLAssociationEnd 對應用戶構造類互相關聯性
  • UMLGeneralization 對應用戶構造類的泛化/繼承
  • UMLInterface 對應用戶構造的接口
  • UMLInterfaceRealization 對應用戶構造接口的實現
  • UMLOperation 對應用戶構造類的方法操做
  • UMLParameter 對應用戶構造類的方法操做的參數

何爲模型？

UMLModel描述各類<UML***>類型元素及其關係(一種圖數據結構）……圖片來自同窗大佬

UML與mdj代碼解析

• • 一個項目有一個Model容器，容器下直接有多個類和接口
  • 每一個類和接口下有孩子元素，其中Operation元素下還有Parameter元素，Association元素下有AssociationEnd元素
  • 每一個元素一般有成員_parentId, _id, _type, name, type, visibility, direction, source(源類), target(目標類), reference(相關的兩個類，正常狀況分兩個end元素), navigable(關聯方向)等property
  • 類和接口（在mdj代碼中屬於同一級別）的parentId老是一致的，而且類和接口的parentId爲Model的id(parentId不表明任何泛化，關聯等意義，僅表明層次結構關係，全部類和接口的parentId都是一個)
  • 那麼如何肯定頂級父類？
    利用id進行遞歸查找，或者並查集思想，主要是考慮遞歸邊界：頂級父類的Generalization元素爲空
  • 必定狀況下，生成的mdj代碼是具備必定順序的，類的操做元素和屬性元素都承接在類元素後
  • 實際的Operation出如今它本身的Parameter中，爲了區分參數和操做，可經過Direction標誌是否爲return來區分，(void)類型的操做的Direction標誌也是return，與具備返回類型的操做區分爲type標誌

類之間的關係

• • 泛化/繼承(Generalization)，Java單繼承，UML能夠多繼承
  • 接口(Interface)
  • 接口實現(InterfaceRealization)
  • 關聯(Association)是一種擁有的關係，它使一個類知道另外一個類的屬性和方法
  • 組合(Composition)是總體與部分的關係，但部分不能離開總體而單獨存在
  • 聚合(Aggregation)是總體與部分的關係，且部分能夠離開總體而單獨存在{none, shared, composite}
  • 依賴(Dependency)表示一個類A依賴於另一個類B的定義

UML：接口能夠繼承接口，也能夠實現接口；
Java：接口能夠繼承接口，但不能夠實現接口。

類屬性和操做的數量

• • 注意區分操做是類的仍是接口的
  • 類B經過繼承而自動得到父類A的全部屬性和操做（只是子類不能直接訪問父類私有屬性），所以
    B.attriCount = A.attriCount + B.self.attriCount (rule 1)
B.operaCount = A.operaCount + B.self.operaCount (rule 2)
  • 接口實現不會創建任何上層和下層在屬性、操做和關聯關係數量上的鏈接。類有多少屬性/操做/關聯時，能夠直接無視接口實現關係。

關聯關係

對於關聯下的元素

• • 一種是互相關聯Association 關聯正常狀況下會有兩個end元素，都是AssociationEnd類別
    • multiplicity對應的是該關聯端對應的個數
    • reference表明UMLAssociationEnd所對應的類的id
  • 另外一種是直接關聯Directed Association
    • navigable(關聯方向)，reference同上，navigable爲false(未打勾)的時候表明指向類，爲true(打勾)時表明可被指向類
    • 聚合aggregation
  • 兩個類關聯時，關聯信息出如今其中一個類中，另一個類須要經過Reference判斷是否被關聯
  • 關聯有兩個端點，每一個端點能夠有一個基數，表示這個關聯的類能夠有幾個實例。
    0..1 表示能夠有0個或者1個實例
    * 表示對實例的數目沒有限制
    1 表示只能有一個實例
    1..* 表示至少有一個實例
  • 在代碼層面，被關聯的類B以類屬性的形式出如今類A中，也多是關聯類A引用了被關聯類B的全局變量。
  • 在Java中，關聯關係是使用實例變量來實現的，類定義
  • UML和Java一致性：類可以和其餘類或者接口相關聯，接口也能夠

關聯性是否會被繼承下來

答案是確定的，子類擁有父類的全部關聯關係，類能夠自關聯，自關聯至關於兩次關聯
F.assoCount = D.assoCount + F.self.assoCount (rule 3)

依賴

• • 依賴關係時是單向的，也是弱關係，在代碼層面，A類中使用到了B類，類B做爲參數被類A在某個方法中使用
  • 在java中，依賴表現爲：局部變量，方法中的參數和對靜態方法的調用。

聚合關係是關聯關係的一種，是強的關聯關係

組合關係是關聯關係的一種，是比聚合關係還要強的關係

UML與Java具備一致性

• • 一個非抽象類必須實現接口中定義但未實現的全部操做
  • 一個類能夠實現多個接口
  • 實現類須要顯式列出要實現的操做，而繼承則不須要顯示列出父類的操做

將每一個類和接口做爲根節點創建樹結構

實質上，UML層次已經顯示出來了，經過ref（隱式指針）和_parentId來鏈接各個樹結構造成森林

順序圖Sequence Diagram -> UMLCollaboration

　　collaboration和Model同層次,Role與interaction（交互行爲）爲該順序圖的上層，擁有如下的交互對象,sequence,participant 參與交互的對象

功能：獲取參與對象數，獲取消息數，獲取對象的進入消息數

• • UMLLifeline 生命線
  • UMLMessage 消息傳遞
  • UMLEndPoint 順序圖終結點

計算總的參與對象

每條生命線對應一個對象

計算總的交互消息

UMLMessage的數量

計算制定對象的incoming消息

接收到的消息數量

順序圖與mdj代碼解析，並創建關係圖

• • UMLInteraction的下一層有UMLLifeline，UMLMessage

狀態圖StateChat Diagram -> UMLStateMachine

　　StateMachine和Model同層次

狀態圖表示一個類的行爲，功能：獲取狀態數，獲取狀態機轉移數，獲取後繼狀態數

• • UMLRegion 狀態圖範圍，包括狀態和轉移信息
  • UMLState 在UMLRegion下一個層次
  • UMLPseudostate 初始狀態，獲取kind可獲得initial標誌
  • UMLFinalState 結束狀態
  • UMLTransition 和UMLState同一個層次
    • UMLEvent 轉移的響應事件
    • UMLOpeaqueBehaviour 狀態轉移的結果

狀態的計數（包括初始和終態且只算做一個）

UMLState元素，可直接得到狀態名稱

一個狀態的不一樣的後繼狀態（可達的狀態，一樣包括初始和終態，且只計算一次）

又是一個遞歸建圖的問題，經過該狀態UMLTransition元素查找
只要可達的狀態都算後繼狀態，注意處理同名同類型的狀態（有可能同名但不一樣類型）

狀態轉移計算

UMLTransition元素，source&target
- triggers中的UMLEvent 表明轉移觸發條件，可從UMLEvent元素中得到轉移標誌名稱

狀態圖與mdj代碼解析，並創建關係圖

• • 頂層UMLRegion，其parent_id爲UMLStateMachine
  • 下一層有UMLPseudostate，UMLState，UMLFinalState，UMLTransition
  • UMLTransition的下一層有UMLEvent

模型有效性與一致性問題

具備UML檢查規則，即應當知足狀態圖自身、順序圖自身、類圖自身、三個圖之間的對應規則

UML基本標準預檢查功能
- UML002：不能含有重名的成員。針對類圖中的類（UMLClass），其成員屬性（UMLAttribute）和關聯對端所鏈接的UMLAssociationEnd不能有重名
- UML008：不能有循環繼承。該規則只考慮類的繼承關係、類和接口之間實現關係，以及接口之間的繼承關係。
- UML009：任何一個類或接口不能重複繼承另一個接口。該規則考慮類之間的繼承關係、接口之間的繼承關係，以及類對接口的實現關係，包括直接繼承或間接繼承。

 

---

 

第一次做業——UML類圖解析

任務

　　實現一個UML類圖解析器UmlInteraction，能夠經過輸入各類指令來進行類圖有關信息的查詢。

　　查詢指令：模型中一共有多少個類、獲取類中指定類型的操做(本類本身定義的)數量、類中的屬性有多少個、類有幾個關聯、類的關聯的對端是哪些類、類的操做可見性、類的屬性可見性、類的頂級父類、類實現的所有接口、類是否違背信息隱藏原則。

設計思路

　　UML交互接口的實現類MyUmlInteraction
* 經過className創建樹結構，每一個class對本身類進行相應的計算
* 經過className映射類元素
* 經過元素自身id映射元素(id不會重複的原則)

架構設計

基礎層

• MyUmlInteraction 交互接口的實現類

數據結構層

• ClassTree 類結構樹。經過className創建樹結構，並對樹結構內進行相應計算

　　* 一個項目有一個Model容器，容器內有多個類、接口等
　　* 每一個class下有孩子元素，其中Operation元素下還有Parameter元素
　　* 每一個元素都有成員_parentId, _id, _type, name, type, visibility, direction, source(源),
　　* target(目標), reference(相關的兩個類，正常狀況分兩個end元素), navigable(關聯 方向)等property

• InterfaceTree 接口樹，功能同ClassTree類
• AssTree 關聯樹，僅保存關聯對端，而忽略類自己
• OperaTree 操做樹

緩存計算層

• MyUmlInteraction類經過關聯其餘數據結構類，當數據結構創建後得到數據結構得出計算結果並保存，方便下次查詢。

應用層

• UmlInteraction類圖指令查詢功能的接口

Debug

　　本次做業的bug：並不保證輸入元素具備順序性，id是惟一區分元素的標誌，類和接口會同名（java中不一樣包內容許），父類和子類的屬性可同名不一樣可見性。

　　容易出錯：類實現的全部接口，包括接口的多繼承接口，包括同名不一樣id的接口也要列出來；繼承父類的關聯（父類也可能有繼承）。

　　大多數問題是對類圖層次分析不夠明確和完全，對mdj代碼和UML圖型的對應關係沒有理解透徹，形成不少考慮沒到位，或者理解錯誤的地方。

度量分析

類圖

　　自己實現接口的類很少，只有一個實現接口的類，知足用戶查詢需求。但須要創建數據結構的類很是多，也是本次做業的重點，查詢功能的代碼不難寫，難在創建數據結構和UML層次關係的解析。只要創建好了數據結構，計算結果很容易得出。

 　　

代碼分析

 

複雜度分析

　　經過樹和圖創建數據結構，經過遞歸或者dfs搜索計算，代碼深度和類圖層次關係較爲複雜。

 

 

---

第二次做業——UML類圖、順序圖、狀態圖解析及基本規則驗證

任務

　　在第一次做業基礎上，實現一個UML類圖、狀態圖、順序圖解析器UmlGeneralInteraction，能夠經過輸入各類指令來進行類圖有關信息的查詢，並可以支持幾個基本規則的驗證。

　　查詢指令：除第一次外還有：給定狀態機模型中一共有多少個狀態、給定狀態機模型中一共有多少個遷移、給定狀態機模型和其中的一個狀態，有多少個不一樣的後繼狀態、給定UML順序圖，一共有多少個參與對象、給定UML順序圖，一共有多少個交互消息、給定UML順序圖和參與對象，有多少個incoming消息、模型有效性檢查（針對下面給定的模型元素容器，不能含有重名的成員(UML002)、不能有循環繼承(UML008)、任何一個類或接口不能重複繼承另一個接口(UML009)）。

設計思路

　　UML交互接口的實現類MyGeneralInteraction
* 經過className等信息創建樹結構，每一個class對本身類進行相應的計算
* 經過className映射類元素
* 經過元素自身id映射元素(id不會重複的原則)

　　實質上，UML層次已經顯示出來了，經過ref（隱式指針）和_parentId來鏈接各個樹結構造成森林。

架構設計

基礎層

• MyGeneralInteraction 交互接口的實現類
• UmlRule002 規則檢查類
• UmlRule008 同上
• UmlRule009 同上

數據結構層

• ClassTree 類結構樹。經過className創建樹結構，並對樹結構內進行相應計算

　　* 一個項目有一個Model容器，容器內有多個類、接口等
　　* 每一個class下有孩子元素，其中Operation元素下還有Parameter元素
　　* 每一個元素都有成員_parentId, _id, _type, name, type, visibility, direction, source(源),
　　* target(目標), reference(相關的兩個類，正常狀況分兩個end元素), navigable(關聯 方向)等property

• InterfaceTree 接口樹，功能同ClassTree類
• AssTree 關聯樹，僅保存關聯對端，而忽略類自己
• OperaTree 操做樹
• MachineTree 狀態機結構
• Region 狀態機層次結構
• State 狀態樹
• Interaction 順序圖交互結構
• Lifeline 生命線（交互對象）樹

緩存計算層

• MyGeneralInteraction類經過關聯其餘數據結構類，當數據結構創建後得到數據結構得出計算結果並保存，方便下次查詢。

應用層

• UmlClassModelInteraction類圖指令查詢功能的接口
• UmlStandardPreCheck 規則檢查（預先）接口
• UmlCollaborationInteraction 順序圖交互查詢功能的接口
• UmlStateChartInteraction狀態圖指令查詢功能的接口

Debug

狀態圖：

　　1.計算狀態數量的時候初始和結尾狀態只算一個

　　2.一個StateMachine下保證只出現一個Region，且final和pre狀態都只做爲一個，且一個Machine中狀態不重名

　　3.若是初始或者結尾狀態是後繼狀態算

　　4.每一個State Machine中，從某個狀態到另外一個狀態的直接遷移均具備不一樣的Event或Guard，即從某個狀態到另外一個狀態的直接遷移如有多個，則這些遷移必定互不相同。

　　5.transition的parentid爲region，所以用source。

　　6.容易爆空指針以及遞歸棧溢出，沒有處理好遞歸邊界（循環繼承的例子）。

順序圖：

• • 對象和lifeline是否對應，多個lifeline能夠引用一個對象，但保證Lifeline和其Represent均一一對應。

規則驗證：

• • 重複實現也算，經過實現繼承也算。
  • associationEnd可能name爲空

　　大多數問題是對類圖、狀態圖、順序圖層次以及規則分析不夠明確和完全，對mdj代碼和UML圖型的對應關係沒有理解透徹，形成不少考慮沒到位，或者理解錯誤的地方。

度量分析

類圖

　　自己實現接口的類很少，有實現4個接口的類，在第一次做業上增長狀態圖、順序圖交互、規則檢查接口，知足用戶查詢需求。但須要創建數據結構的類仍然很是多，總共達到13個類，也是本次做業的重點，查詢功能的代碼不難寫，難在創建數據結構和UML層次關係的解析。只要創建好了數據結構，計算結果很容易得出。

 

代碼分析

 

複雜度分析

　　模型圖增長了狀態圖和順序圖，範圍廣了，但創建數據結構的方法相似第一次。

 

 

---

 2、OO做業四個單元的架構設計及其面向對象構造的演進

　　第一單元：

　　面向對象設計的初步，剛開始還不太會運用面向對象思想編程，對於求導問題仍是很直接地寫面向過程的代碼。架構設計幾乎也沒有，很亂，沒有交互層面。一次做業僅僅3-4個類：表達式、主函數、求導、數據結構類。

　　第二單元：

　　多線程程序不只有數據結構類、輸入輸出類，還增長了與需求交互的類，還有多個線程併發的狀況——線程類，還有管理（調度）類。第二次做業逐步體現出抽象的過程，將需求和功能分別對應。

　　第三單元：

　　JML設計，在這次做業中主要是實現功能接口，也學習到了部分軟件工程設計模式（工廠化模式）。這個單元對類的抽象和封裝有更高的層次，咱們根據官方接口，實現本身的容器，用於用戶查詢等操做。在架構設計上，還增長了緩存計算層，將數據層與應用層獨立開來。

　　第四單元：

　　同第三單元相似，只是在數據結構層上增長了深度和難度，結構觀察視角和行爲觀察視角。設計模式和第三單元差很少，都有緩存計算層，實現接口功能的應用層則更好地體現了用戶需求與數據的交互，但不會影響數據結構層。

　　做業採用了迭代增量的方式每一個單元的三次代碼做業，都是基於本來功能進行擴展，增長更多需求和操做。

 

---

 

3、OO做業四個單元的測試方法與實踐（bug修復）的演進

第一單元：

　　測試沒有太多技巧，主要是經過肉眼觀察表達式匹配的字符串，以及碰撞邊界特殊表達式的狀況，同時，手寫評測器瘋狂對代碼進行測試，雖然效率增長了，但很難保證測試範圍和測試質量。

第二單元：

　　本單元加入多線程，調試難度加大，甚至沒法用斷點調試以及找出死鎖問題。做業的調度算法增長了難度，須要考慮時間優化，因此邏輯上、優化上出現了不少問題。線程調度、線程安全是測試的重點，但測試方法沒有找到很合適的。對於輸出結果能夠利用對拍器自動比較。

第三單元：

　　經過學習JML語言後，運用jmlunitNG等工具編寫測試類進行代碼測試。這個單元的bug主要是第三次做業，需求增長到四個計算，顯然不少Bug，中測倒數第二個最後關頭都沒找出來，因此沒進互測，而後時間複雜度特別高，對於強側的數據，簡直爆炸了。

　　修復過程當中，改進了求最短路的算法，修復了超時的問題。對於最低票價和不滿意度是最容易存在Bug的，而對於並查集求解基本沒有問題。最低票價我採用上文的思路，仍會出現問題，有這幾種：單條路徑存在環路須要更新權值；每條路徑都須要求最短路；新增路徑與原有路徑存在相同節點也須要更新。

第四單元：

　　學習了UML模型圖以及運用starUml工具進行模型圖構建、生成mdj代碼，方便觀察和測試，同時可使用前幾回做業的測試方法和測試類。

 

---

4、OO課程收穫與體會

　　學期剛開始，甚至還沒開學（還在家裏）的時候咱們就接收到本學期面向對象課程預習做業的通知，我也是本學期才接觸到Java編程及其面向對象編程思想，整體上的感受就是，這門課程讓我從一無所知變成學會了不少編程思想、測試、調試、架構設計、多線程、軟件工程設計模式等方法（不過我依然是一個菜雞）。那麼具體來講一下這門課程中個人收穫，以下：

　　一、熟練掌握Java語言及其IDEA編譯器的使用。雖然一個學期的時間很短，可是課程任務不是通常的重，而是超乎常人的重。每週都有相似於大做業、大工程的代碼項目，那就是必須在每週前三天較好、較快地完成代碼編寫、調試和經過基礎測試，在經過基礎測試後，接着兩天內進行同窗之間的匿名互測（互相hack，我學會如何作一名hacker哈哈），最後官方評測系統再根據較強測試進行評分，最後還有幾天的bug修復環節。除此以外，每兩週有一節上機實驗課和一節研討課，每一單元做業完成後對單元做業進行總結的博客編寫（例如如今寫的就是）。對於咱們來講，每週都是緊張的狀態，每週的代碼量也都充足，因此短短地一學期，可以熟練運用IDEA和Java面向對象設計是一大收穫。

　　二、我的的自學能力和思惟能力獲得提升。我我的（或者說大多數人）在這門課程的做業上花費的時間應該是最多的了，這門課程也是最燒腦、最磨時間的課程了。每一個人對程序、工程都有本身的獨立思考和轉化，能完成這些代碼量的程序說難不難，說易也不易，也挺佩服你們的毅力。

　　三、課程帶來了面向對象編程思想和軟件設計模式這些新編程方法。這些思想方法更貼近軟件的設計和用戶的需求，掌握多種設計方法，可以讓咱們（程序員）更好地應對客戶需求。一開始從面向過程編程到面向對象編程不免會有不適應，沒法理解類的封裝與獨立，熟練以後，以爲每一個功能、每一個類別的東西獨立開來，還能夠互相交互更方便設計。之間加入多線程則更是符合實際生活需求，生活中多線程的例子不少，滴滴打車，銀行排隊等，這些也在實驗課中完成過，多電梯多調度做業也編寫過。

　　四、掌握多種程序測試方法及其本身編寫評測器還有bug修復方法。寫程序固然少不了測試，誰的程序都避免不了出現bug，bug修復也是一個難題，甚至連bug在哪都有可能找不到。課程增長了同窗之間的hack，不只須要找本身代碼的bug也要構造測試用例找別人的bug，在此過程當中也學會了編寫基本的對拍器，自動評測器，加快hack效率和質量。在學會jml以後，還運用jmlunit等測試類工具進行測試代碼。bug修復不比寫代碼花的時間少，其實寫完代碼後發現連基礎數據都過不了很正常，如今的程序代碼複雜度高，肉眼沒法再觀察獲得了，只能經過調試、結果輸出、猜測斷定等方法找出bug。

　　五、如何在短期內寫出上千行代碼（哈哈哈，這多是程序員最驕傲的收穫了，一週內寫了上千行代碼，是又想吐槽又驕傲又禿頭~警告）。

 

---

 5、OO課程評價與建議

　　我對本課程滿意度仍是挺高的，雖然確實折磨人，不事後來稍微下降了一點難度，內心暢快多了，以前的多線程單元確實頭疼，基礎測試都沒過。高強度、高難度才能訓練出好的工程師，這句話實測無錯。

提點建議：

1. 之後的互測，你們別先忙着寫評測機如何如何「坑」別人，這樣真的好嗎？有的時候全部人平均hack次數2-5次，你一我的上百次（甚至是同一個bug），好玩嘛？純屬找娛樂感和自豪感。其實程序寫完美類，徹底不擔憂互測的問題，畢竟互測真正的目的是經過本身思惟而不是寫評測機自動hack（雖然這個沒錯）。
2. 實驗課有的時候感受不知道要幹嗎，或者說實驗課作了太多好像沒有意義的事。其實實驗課沒有必要安排在理論課的下一節，畢竟才上完理論課，還沒弄明白，接着實驗課就作實驗，會比較迷茫。
3. 理論課可能須要更具體更實際一點的講解，或許有點過大、過寬、過深了。