OO总结之UML与期末
OO总结之UML解析与期末总结
第四单元作业架构分析
架构设计及OO方法理解
测试理解与实践
课程收获
改进建议
线上学习oo课程的体会
一. 第四单元三次作业架构分析
本单元重在让我们理解面向对象编程非常重要的一种工具--UML模型，方法是通过让我们自己编译解析器来加深对各类图，元素，已及其关系。据说很符合以前OO课程的画类图考核方式。1.1 第一次作业
本次作业说实话是难度相对最大的，因为万事开头难，我们要从零开始建立起自己的UML体系，包括概念上的。我知道有的同学追求方便采用了现用现找的方式，有的建立了完美的，与UmlElement类一一对应的对应类（因为原来的类连构造方法都是private，一看就没想给我们用）。前者在后面的作业不可避免要重构，而后者会在第一次作业花费比较多的时间。
于是我采取了一种折中的做法，我将UmlClass与UmlInterface建立对应的IClass类，这样做的话可以最大程度迎合查询的需求。在IClass类当中对每个类当中的元素进行了索引（没错，是索引，因为咱们毕竟只是查询，不用具体的管理）。然后在大类当中建立IClass的索引，这样既不用重构，也可以节约一些时间。
具体结构大致如下：
public class IClass {
private HashMap<String, ArrayList> attributes;
private ArrayList<UmlAttribute> attributeArrayList;
private HashMap<Visibility, ArrayList> operations;
private ArrayList<UmlOperation> operationList;
private HashMap<String, ArrayList> parameters;
private ArrayList<UmlAssociationEnd> relations;
private ArrayList<UmlInterfaceRealization> realizations;
private String name;
private String id;
private ArrayList<String> parents;
private int opNum;
private int atNum;
private int asNum;
private boolean isInterface;
private ArrayList<String> duplicatedNames;
}
在下面的作业中，我发现这是一个相对幼稚的架构，后来的自定义类中采用了更完善的方案。
但是这个结构初步体现了缓存和索引的思想，可以通过一些查询方法查询hashmap直接得到结果，在需要遍历时有可以提供对应的ArrayList（相当于对HashMap的值做了缓存），同时对操作数，属性数等进行缓存。
我同时也对duplicated的各项元素做出了缓存，一旦查询的元素在duplicated当中有记录，则直接抛出异常，但是同时我们也并不妨碍其通过id访问，保证数据不会丢失。
1.2 第二次作业
本次作业增加了Uml状态图与顺序图的查询，有了上一个单元的经验，这单元的工作基本就是对上单元工作的移植，当然还有一些细节要调整，主要在构造方法及解析上，要注意某些元素的parent不存在以及UmlAttribute的“二义性”等。
本单元的索引结构进一步成熟，进化如下：
public class IInteraction {
private String id;
private String name;
private HashMap<String, UmlLifeline> lifelines;
private HashMap<String, String> name2id;
private HashMap<String, ArrayList> messageIns;
private ArrayList<String> duplicated;
private int mss;
}
public class IStateMachine {
private String id;
private String name;
private HashMap<String, UmlState> states;
private HashMap<String, String> name2id;
private UmlRegion region;
private UmlPseudostate pseudostate;
private UmlFinalState finalState;
private ArrayList<String> duplicated;
private HashMap<String, UmlOpaqueBehavior> opaqueBehavior;
private HashMap<String, ArrayList> transitions;
private int trans;
}
在上一次作业当中，我的架构最大的困惑，就是用什么作为元素索引的Key，开始时为了方便用了一些例如可见性之类的属性，结果有些弄巧成拙，因为查询覆盖了很多方面。
后来我选择了中规中矩的id索引，在实践中居然让我发现了一个巧妙的途径。例如我们在 后继状态可达性问题上，需要进行多次索引，我们通过name2id方法找到起点，查询transitions获得一个可达状态id的集合，此时我们不需要获取这个id对应的究竟是哪个状态，直接通过id就可以继续搜索。这意味着其实对于UmlState做建模其实是多余的（甚至做缓存都是多余的）。这也进一步证明了我在第一次作业时不需要对所有元素一一建模的理论。
本次作业对缓存采用了大量HashMap<id， id>结构，查询起来有OS的多级页表的感觉，而且还是TLB百分百命中的那种，很标准也很舒服。
1.3第三次作业
本次作业检查模型有效性，这次作业与其是考察编程能力更多还是加深UML理解更多一些，实现起来主要就是进行一些图搜索与汇总，主要是找环路，架构上并没有什么进展。
二. 本学期架构与OO方法理解
2.1 第一单元本单元的架构不大成熟，但是初具规模，主要应用工厂模式以及静态方法封装。第三次作业使用了树形结构求导。
2.2 第二单元
本单元主要是多线程实践，实验课学习了生产者消费者模式。我在作业当中采用抢占式地调度，LOOK运行逻辑以及静态换乘逻辑，本单元的重点在于多线程安全与交互，类之间的协作较多，聚合关系较重。
2.3 第三单元
本单元是JML社交模拟，基本架构已经给出，并且我也没有新建其他类，主要是效率问题。
2.4第四单元
本单元是UML解析器，需要自行架构一些结构方便查询（就是你画出什么图，就去查什么图），我的架构上文已有详述，总体看来分两大层接近树形结构。
三. 测试与实践
第一单元手动构造测试集，后来发现第一单元是最适合自动测试的（汗）。第二单元还是手动测试，因为多线程测试没太搞懂。
第三单元手测加Junit，因为JunitNG真的不好用。
第四单元时间紧张，主要通过手动绘图，导出测试，本质上是手测，但是实现了半自动化。
四. 课程收获
1. 编程规范化：CheckStyle！（yyds）作为之前从来没有注意过代码可读性的编程者，在经历了一个学期学习之后，我原来的代码都看不下去了。- 理解“面向对象”：其实我在本学期之前就接触过Java,还写了一些小游戏，但是那时还不知道什么是面向对象编程，导致过程极其混乱（因为没有封装），debug极其痛苦。现在理解了封装的思想，可以用很简单的代码和逻辑完成原来的功能。
3.多线程知识：早在上学期爬虫大作业时，我就试图使用多线程，可惜最后还是没太搞懂，现在已经对这方面有了基础的理解和应用能力。
- 工程化方法： 这一点在计组当中首先基础，OO中再次强化。
5.测试方法： 这一点也是本课程强调的点之一，包括黑盒，自动化，互测，单元测试等。
五. 改进意见
一. JUnitNG这种鸡肋的测试工具不建议作为推荐工具使用。二. 可以通过课外视频链接或者助教扩展的方式较为系统的教学一下自动化测试流程，因为自动化测试这个东西用的人也许大一就开始用，不会或者不想用的人到最后也不一定去用，且相关的教学几乎没有，全靠大神魔改，如果是这样的话这一点就不应该作为教学考察的一环（不教的话何言考察？），而是纯粹作为个人能力。
三. 添加实验课反馈：我们做过的实验很多都不知道结果如何。数据过于宽泛。
浙公网安备 33010602011771号