OO UML总结暨课程总结

桃扇骨 2021-12-21 06:41 221阅读 0赞

## OO UML总结暨课程总结 ##

### 一、架构分析 ###

两次UML解析程序，主要是递进式的，第一次解析了类图，第二次在类图基础上，增加检查规则和顺序图及状态图。

总体架构思路主要有五点：

1、尽量**还原**图本身的结构（组装）

2、**分类**（状态图、顺序图、状态图）

3、元素与关系**分离**

4、对同一类element进行**合并**

5、**抽象**Element

先从**类图**来讲：

**1、还原**

每个class有attribution、operation

每个operation有parameter

因此有

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

对接口有类似操作，继承Class即可

简单的画个类图他们关系大概就是这样

我们只需通过json中的\_parent和id就可以把他们联系这一起，至此重组完成。

**针对第二次解析程序这里有一些小改变（元素重名检查）：**

由于类图检查需要检查Class对端的asscociationEnd与自身Attribution的重名问题。也就是说associationEnd也会属于Class，因此AbstractClass中的内容需要增加asscociationEnd的存放(只需增加一个容器和规则检查方法，整体难度不大，算是做了一次小拓展)

**2、关系与元素分离**

关系主要是类之间的，有继承、实现、关联。

由于UMLClass是我们元素组装的最上层，自然关系与其同层次，放在任何一个里面都不太合适，因此选择了将他们分离的策略。

我们单独建立一个Relation来存放他们。

解析json-->识别type-->分类存放 即可。

**针对第二次解析程序这里有一些小改变（关系检查）：**

无论是循环继承的检查还是重复继承的检查，都整合了这两种关系（继承、实现），因此为了操作方便，这里选择增加一个RelationCheck类，构建一个继承和实现关系构成的图。然后用上各种搜索方法（如DFS）就可以轻松解决上述检查。

由此可以看出，在这种架构之下，两次解析程序的递进针对类图都不会出现重构的情况，只需做少量拓展，即可完成。

再讨论下**状态图**吧

**1、还原**

跟类图一样，按照层次关系：（关系比类图要简单点）

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的傀儡？？？

**2、合并**

这是我针对本次作业想重点讨论的话题。

**也是我认为本次设计成功的点之一：为了易修改，易拓展而设计**

**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;   }     ... }

同样，什么是相同状态，我们就可以在此定义，一旦规则有变，也只需修改这一处即可。（虽然最后限制了测试数据，这个地方没有了大用）

**3、分离**

在这里，类似于类图中的操作，把转移关系存储为图架构。需要注意的是，由于考虑了合并问题，因此可以通过一个类AbstractTrans来封装它，通过重写equals方法即可实现合并。

最后是最简单的**顺序图**：

顺序图总体比较简单。

1、**还原**

跟类图一样，按照层次关系：

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<>();   ... }

**2、关系与元素分离？？？**

（1）Interation跟message是从属关系，不是同层次

（2）查询命令简单，无任何图算法相关操作

因此，这里不采用，只是加两个容器储存和统计一下即可

### 二、架构设计总结及ＯＯ方法理解的演进 ###

四个单元对ＯＯ的架构设计是从面向过程到面向对象的一个巨大的转变。

第一单元，设计之初过多考虑功能性问题，导致多项式求导的设计非常没有层次感（把因子，项等杂糅在一起，通过递归处理，这样非常不ＯＯ）

第二单元，电梯的设计主要是多线程的安全性问题。我遇到了比较大的困难，不好的架构导致了线程不安全的可能性增加。但是经过参考多线程各种设计模式，并且把电梯调度分部分考虑，架构有了一定提升，但代码杂糅的程度还是比较高的。

第三单元，ＪＭＬ部分由于助教提供了一个大体框架，我也更多去思考设计的层面，整体的思路和结构都好转。

第四单元，ＵＭＬ是我考虑拓展性和架构设计优劣性最多的一次。更多注重下一次功能能否轻而易举增加的内容，并且在自己的ｄｅｂｕｇ和修改的过程中，体会到了非常大的好处。

我认为ＯＯ设计一开始不能一味考虑算法（功能性）和ＡＣ的问题，更多应该聚焦在层次拆解。

以第四次单元为例