OO UML總結暨課程總結

時間 2019-11-12

標籤 uml 總結課程简体版

原文原文鏈接

OO UML總結暨課程總結

1、架構分析

兩次UML解析程序，主要是遞進式的，第一次解析了類圖，第二次在類圖基礎上，增長檢查規則和順序圖及狀態圖。java

整體架構思路主要有五點：算法

一、儘可能還原圖自己的結構（組裝）json

二、分類（狀態圖、順序圖、狀態圖）設計模式

三、元素與關係分離安全

四、對同一類element進行合併數據結構

五、抽象Element多線程

先從類圖來說：架構

一、還原框架

每一個class有attribution、operationide

每一個operation有parameter

所以有

UMLPARAMETER-->UMLOPERATION + UMLATTRIBUTION -------> UMLCLASS

對接口有相似操做，繼承Class便可

簡單的畫個類圖他們關係大概就是這樣

咱們只需經過json中的_parent和id就能夠把他們聯繫這一塊兒，至此重組完成。

針對第二次解析程序這裏有一些小改變（元素重名檢查）：

因爲類圖檢查須要檢查Class對端的asscociationEnd與自身Attribution的重名問題。也就是說associationEnd也會屬於Class，所以AbstractClass中的內容須要增長asscociationEnd的存放(只需增長一個容器和規則檢查方法，總體難度不大，算是作了一次小拓展)

二、關係與元素分離

關係主要是類之間的，有繼承、實現、關聯。

因爲UMLClass是咱們元素組裝的最上層，天然關係與其同層次，放在任何一個裏面都不太合適，所以選擇了將他們分離的策略。

咱們單獨創建一個Relation來存放他們。

解析json-->識別type-->分類存放便可。

針對第二次解析程序這裏有一些小改變（關係檢查）：

不管是循環繼承的檢查仍是重複繼承的檢查，都整合了這兩種關係（繼承、實現），所以爲了操做方便，這裏選擇增長一個RelationCheck類，構建一個繼承和實現關係構成的圖。而後用上各類搜索方法（如DFS）就能夠輕鬆解決上述檢查。

由此能夠看出，在這種架構之下，兩次解析程序的遞進針對類圖都不會出現重構的狀況，只需作少許拓展，便可完成。

再討論下狀態圖吧

一、還原

跟類圖同樣，按照層次關係：（關係比類圖要簡單點）

UMLState + UMLTransition --> UMLReion --> UMLStateMachine

重組便可

public class AbstractStateMachine {
    private String name;
    private String id;
   
    //Region
    private String regionId;
    
    // UMLTransition
    private HashMap<String, UmlTransition> idToTranstion = new HashMap<>();
    private HashSet<AbstractTrans> transHashSet = new HashSet<>();
    
    //UMLState
    private HashSet<AbstractState> states = new HashSet<>();
    private HashMap<String, AbstractState> idToState = new HashMap<>();
    private HashMap<String, ArrayList<String>> nameToState = new HashMap<>();
    
    //RELATION
    private HashMap<AbstractState, HashSet<AbstractState>> transRelation
            = new HashMap<>();
    private HashMap<AbstractState, Integer> idToSubCount
            = new HashMap<>();

可能會發現Region怎麼彷佛和State平級，主要是因爲Region實在對查詢功能無大用，更像是StateMachine的傀儡？？？

二、合併

這是我針對本次做業想重點討論的話題。

也是我認爲本次設計成功的點之一：爲了易修改，易拓展而設計

State

狀態機中有三類狀態：UmlFinalState、UmlPseudostate、UmlState，狀態統計須要考慮這三者，同時狀態轉移也是在這三者中進行，所以咱們能夠採用一個AbstractState類來代替這三種。

public class AbstractState {
    //0: state -1:init 1:final
    private int type;
    private String name;
    private String id;
    
    public AbstractState(int type, String name, String id) {
       ...
   }
    
    @Override
    public boolean equals(Object obj) {
        if (obj != null && obj instanceof  AbstractState) {
           ...
       }
        return false;
   }
    
    @Override
    public int hashCode() {
        return type;
   }
   ...
}

這樣作有良好的可修改性，咱們能夠自行定義，什麼是共同狀態？。

好比針對以前一直比較有爭議的是否合併起始狀態等問題，只需修改重寫的equals方法便可。

一樣，對Transiton也採用一樣的方法。

package stategraph;

import java.util.ArrayList;

public class AbstractTrans {
    private String id;
    private String name;
    private AbstractState source;
    private AbstractState target;
    private String guard;
    private ArrayList<String> triggers;
    
    public AbstractTrans(String id, String name, AbstractState source,
                         AbstractState target, String guard,
                         ArrayList<String> triggers) {
       ...
   }
    
    @Override
    public boolean equals(Object obj) {
        if (obj != null && obj instanceof  AbstractTrans) {
           ...
           }
            return false;
       }
        return false;
   }
    
    @Override
    public int hashCode() {
        return 1;
   }
   
   ...
}

一樣，什麼是相同狀態，咱們就能夠在此定義，一旦規則有變，也只需修改這一處便可。（雖然最後限制了測試數據，這個地方沒有了大用）

三、分離

在這裏，相似於類圖中的操做，把轉移關係存儲爲圖架構。須要注意的是，因爲考慮了合併問題，所以能夠經過一個類AbstractTrans來封裝它，經過重寫equals方法便可實現合併。

最後是最簡單的順序圖：

順序圖整體比較簡單。

一、還原

跟類圖同樣，按照層次關係：

UMLLifeline + UMLMessage ----> UMLInteraction

重組便可

public class AbstractInaction {
    private String name;
    private String id;
    //UMLLifeline
    private HashMap<String, UmlLifeline> idToLifeLine = new HashMap<>();
    private HashSet<String> represent = new HashSet<>();
    private HashMap<String, ArrayList<String>> nameToLifeLine = new HashMap<>();
    //UMLMessage
    private HashMap<String, UmlMessage> idToMessage = new HashMap<>();
    //RELATION
    private HashMap<String, Integer> messageIn = new HashMap<>();
   ...
}