OO Unit3 UML conclution

总结本单元两次作业的架构设计

第一次作业类图

第二次作业类图

• 两次作业的不同之处

  我认为第一次作业主要针对类图进行详细而且周全的理解和分析，有各种UML元素的统计和建模。

  第二次作业主要在于广度，建立三个不同的UML图，并且有三个规则的check，这三个check可以乍一看比较复杂，其实都可以转化为图以较快地完成。

• 架构设计

  第一次作业，因为只有一种图，即所有的元素都属于这个图，并且一个图中有多个UMLClass类。所以我的做法是，将一个类中所有的成员——参数(Parameter)、属性(Attribute)、接口(Interface)、关联(Association)等都放进一个类(MyClass)中。类与类之间的关联，比如继承关系、接口实现关系、关联关系等，由于是两个或两个以上类参与的过程，因此在交互类(MyUmlInteraction)中实现。

  第二次作业，因为有三种图，因此，用三个类：MyClass、MyStateMachine、MyInteraction来建模三种图；用三个交互类MyUmlClassModelInteraction、MyUmlStateChartInteraction、MyUmlCollaborationInteraction分别来协调类图、状态图、顺序图之间的关联。

• 流程设计

  主要是第二次作业的架构相应的代码流程实现。

  1. 根据每个diagram出现时，在最开始会有UMLClass元素或者UMLInteraction元素或者UMLStateMachine元素，以此来分割每个图及其对应的元素。

  2. 当收集完一个图的元素时，开始建图，建完图后将一张图表示的这个类放入对应的交互类中。设置好对应的查找方式。

  3. check并开始指令。

• 主要算法

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

    • 初始化：有直接继承关系的类或接口其矩阵元素为1，即matrix[i][j]=1表示i直接继承j。

    • floyd：当i是mid的其中一个子类，mid是j的其中一个子类，那么i是j的其中一个子类，则将i继承j的元素置1。即

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

    • 运算结果：矩阵对角线元素为1的表示成继承环，包括自环。

  • 到达路径数的floyd(用于checkForUml009())

    • 初始化：直接继承或直接接口实现的次数，即matrix[i][j]表示i直接继承j的次数，或i直接实现了j接口的次数。

    • floyd：从i到j的可能数 = \old(从i到j的可能数) + 从i到mid的可能数 * 从mid到j的可能数。元素0表示从i继承或接口实现j的可能数为0，因此可以无条件执行更新语句。即

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

    • 运算结果：矩阵元素表示从i到j的可能数，即类或接口i继承接口j的次数，如果元素等于0，表示类或接口i不继承接口j。如果元素大于1，表示类或接口i多次继承接口j。

  • 继承关系dfs(用于找父类)

    • 初始化：matrix[i][j]=k表示类i继承的第j个父类为类k。
    • 递归：
      • 如果还未到j_max，则继续递归下一个父类。
      • 如果到达j_max，则返回，记录顶层父类，并且将父类的属性、参数、关联关系、接口等需要传递给子类的东西传递给下一层它的子类。
      • 以此类推，将上层父类的需要传递的东西一层层传递给他的子类，直到最底层。这样，递归一次，可以将沿途经过的类的继承关系都处理好。

总结自己在四个单元中架构设计及OO方法理解的演进

经过四个单元的练习，我对"面向对象”有了更加深刻的认识。

第一个单元表达式计算，因为题目本身难度不大，用什么方法、架构完成都可以，所以每个人的代码思路都不同。对“对象”和“类”的划分也各有各的逻辑，对我个人来说，在第一单元，面向对象的手法基本没用上，整个程序还是非常的面向过程，对象所拥有的属性、对象所属的类的划分都很混乱。虽然将表达式个体当成了分别独立的各个对象，但是计算处理过程还是很面向过程，以致于在化简、优化过程中碰到了很多困难。

在第二单元多线程电梯，我试图将电梯、请求、控制器、总交互平台分别划成各个类。但是在实现过程中，还是将本该交给控制器类的任务交给了电梯类或者请求类。虽然在建模的时候对整个程序有一个比较明确的计划和框架，但是在实现过程中还是碰到了诸多困难，以至于我选择将一些不该放在这个类的方法或者数据成员放在了这个类中，方便处理，但导致了架构混乱。

在第三单元JML主要是规格撰写，使我对测试方法有更深刻的认识。同时，因为规格的撰写，我更加熟练了将特定的任务群划分给某个类，将某一个任务划分给某个方法来完成。这一单元的层次非常清晰，可以说更加印象深刻地、直观地感受到了所谓的层次清晰。

第四单元UML，随着面向对象思想观念的深入，我开始思考如何用更清晰的、更简单的类来表示题目要求的各类对象。把实现的各部分划分成不同的责任单元，建立各个类来分别负责完成各自的任务，并合理交互。从架构方面来说，可以说是第三单元的延续，非常清晰的层次，即交互类和图类。

总结自己在四个单元中测试理解与实践的演进

在第一单元的表达式计算中，我对测试的理解仅限于构造完整的测试集，就是要走遍每一条代码、走遍每一个分支或者条件选择语句。在划分等价类的时候，要把各个可能的组合都划分开并且测试充足。

在第二单元的多线程中，因为多线程的特殊性，测试也更有难度，每次同样的测试数据跑出来的结果是不同的，所以在测试的时候要充分考虑到线程的执行顺序、速度等不可控因素的影响。很有可能某一种执行顺序是无法测试到或者无法重演的，那可以进行大规模的测试，或者先进行逻辑上的推演，并且加入一些语句来人为控制线程执行的顺序，确保在实际的程序运行过程中，每一种可能的顺序都不会导致结果出错。

在第三单元JML中，才算是对测试方法有了更全面并且正确的认识。尤其是对于等价类的划分，可以使得测试数据作用明确、定点投放、避免重复，实现更加高效的测试。并且，由于规格的撰写，可以很方便地罗列出可能会出现问题的输入可能、输出可能、以及方法内部的逻辑问题。在实现代码之前先进行规格和作用的设计，可以不受到代码细节的干扰，确保每个方法 的正确性。在测试时则根据事先约定的规格，对可能的漏洞进行针对性地设计测试集。

在第四单元UML中，它的测试主要是对于边界情况、复杂情况的处理。比如重复继承、循环继承等，在递归或者遍历算法的过程中要注意。相比第二单元的各种不可控、不可预知情况，第四单元更重要的似乎是逻辑和理解上的正确性，并且进行白盒测试。

总结自己的课程收获

OO课程如同登山，步步为营，一点点地提升，让人很有成就感。回首学习OO的一个学期，可以说每一次作业都做到了尽心，虽然有时候还有bug，但是总的来说还是相对完整的回忆。

相比完成了各个单元的那么多份代码，更重要的是确实学到了很多架构思想、测试方法、debug方法等在以后的写程序过程中非常有用的事情。

虽说自始至终我都喜欢把程序写得尽可能清晰并且逻辑简单，因为我认为越直白简单的逻辑越不容易出错，但直到现在，做完了最后一个单元的最后一次作业之后，回忆起第一单元的程序架构，还是觉得当时的想法还太复杂，还可以更加简单一些。这也可以认为是四个单元的训练之后，在实现自己的理想状态上的一些小进步吧。当然，从规格和规范性而言，并不是越简单越好，我只是就复杂和简单来说。

立足于自己的体会给课程提三个具体改进建议

1. 指导书明确。明确到不需要在讨论区对指导书定义的问题进行询问和讨论。
2. 要求每一次作业都写明自己的大体架构，方便互测时的同屋同学代码阅读与理解。
3. 及时公开优秀代码并且有相应的架构说明。有些同学的代码过于优秀，一下子难以理解。
4. 研讨课的讨论性不够，希望可以学习更多优秀架构和思想。