面向对象第四单元总结——UML

Posted 2022-02-04 lifeisagame

本单元构架设计

统一建模语言（英语：Unified Modeling Language，缩写 UML）是非专利的第三代建模和规约语言。UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效。

本单元作业的主要内容是对UML类图、状态图和时序图进行解析和查询，并依照某些规则对UML类图进行检查。其中，课程组已经做好了将原始UML导出文件，转换成为一系列可直接进行访问的类的工作，并提供了对整个文件中元素信息进行查询的未实现接口，我们需要做的工作即是实现抽象接口，以满足其预期提供的功能。

第一次作业——类图

第一次作业的基本思路是对UML_CLASS和UML_INTERFACE分别建立MyClass和MyInterface类，由于各元素id值唯一，故可将其保存在HashMap中，以便随时取用。较为复杂的是给Operation对象设定Parameter属性，由于各元素之间存在依赖关系，故在解析文件时需要注意先后关系，首先解析并保存类、接口对象，然后才是为他们添加关系联系。在查询方面主要采用递归深搜的思路即可完成。但因为某些原因，我在接口继承方面还是有一些判断失误，以至于在强测中显露出了一些bug。

构架图如下所示：

第二次作业——类图、状态图、时序图解析与规则检查

第二次作业在第一次作业的基础上增加了对状态图和时序图的查询功能，以及对整个文件中类图的默认规则检查，一旦不符合规则，则立即停止接下来对整个文件的查询，显示错误信息并退出程序。

对状态图和时序图的处理方法与对类图的处理方法类似，在读取文件时保存其中的关键对象MyState、MyInteraction入哈希表，并将相关属性内容添加给对应的主体对象。对于三条规则的验证，我分别创建了唯一的检查器RuleChecker1/2/3，在检查的思路方面，第一是解析类图元素时，将与规则相关的内容保存入检查器，第二是检查时主要采用的方法是递归深度遍历的方法，通过识别重复搜索的标志进行处理。

构架图如下所示：

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

总的来说，由于我是重修生的缘故，所以在演进的过程上并没有感觉到成长性，或者说，没有那么强的成长性，并且由于四个单元的详细构架都已经在各自的单元博客作业叙述了，所以接下来我就简单谈一谈自己对各个单元的面向对象构架设计特点的理解。

第一单元的内容是多项式的求导，在这一部分中，由于功能明确，相互较为独立（加减乘除求导），逻辑结构较为明显的缘故，进行对象化的构架设计的思路是比较明确的，表达式、因子之类的。他们的关系是相互嵌套的，也就是说这是一个树形结构，在进行计算时必然会面临一定程度的深度递归，这是一个难点，但同时由于所进行的计算方法只有单一的功能，并且副作用很小，所以也不算是令人头皮发麻。另一个难点就是这单元同样还考察输入输出与正则表达式的相关知识和技能，所以在对表达式进行规则验证的时候，也会有一些难度。

第二单元的内容是多部电梯的调度，在这一部分中，由于系统的功能增加，复杂性上升，导致其在构架设计时所需要花费的时间多于第一单元，我们得明确电梯、调度器和乘客的关系以及各自应当实现的功能，当按键被按下时，这条信息究竟保存在电梯对象中还是保存在调度器中？调度器是只起到计算新来的乘客应当被分配给哪一部电梯的作用，还是操控所有电梯的运行？除此之外的另一个难点即在于多线程的相关知识与技能，在未良好掌握的情况下，会对完成作业产生阻碍。

第三单元的内容是理解JML规格，综合设计数据结构，在规定时间复杂度的限制条件下完成作业。在这一部分中体现了数据结构和对象为功能需求而设计的应用原则，理解JML规则难度不高。第四单元则与第三单元类似。

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

在这四个单元的训练过程中，我主要在副作用静态检查、多线程动态检查和单元测试三个方面获得了一些进步。副作用静态检查是从第三单元JML规格中所得到的启发，通常来说，我写方法的时候是不会先认真地写上规格注释要求的，但这样的思路有助于在写完方法后进行代码的快速复查：我会不会在方法实现过程中修改了别的变量？这些修改过的变量在下一次运行该方法前需不需要清空？方法的副作用在第四次作业中让我产生了一些bug。多线程的测试方法我使用的更加熟练了。单元测试可以使用Junit对每个方法进行，并生成较为全面的测试集，虽然说这样做并不一定能发现隐含的设计逻辑偏误，但可以帮助我们发现一些隐藏的代码实现上的小bug。

课程收获

该课程对我主要有以下收获：
· 重修通过
· 获得设计与编程经验
· 学会使用更多的工具达成目标
· 克服恐惧，提升抗压能力

改进建议.

· 更多的代码分享与代码修正的时间：如果总是自己写啊写，那无异于闭门造车。
· 降低测试点耦合性：虽然一颗老鼠屎就能坏一锅汤，但我们无法否定这锅汤的劳动价值。
· 降低起点难度：虽然玩家的水平年渐提升，但仍有相当一部分玩家是从零开始。