OO第四单元+课程总结

本单元架构设计

　　第四单元任务旨在实现一个UML类图、状态图、顺序图的分析器。MyUmlGeneralInteraction作为入口，其中分别创建了一个类图分析器MyClassMedelInteraction、一个状态图分析器MyUmlStateChartInteraction、一个顺序图分析器MyUmlCollaborationInteraction。总体架构如下：

• MyUmlClassModelInteraction

  • Class(Base)

    • UmlAttribute

    • Operation

      • UmlParameter

    • Association

      • UmlAssociationEnd

  • Interface(Base)

    • UmlAttribute

    • Operation

      • UmlParameter

  • UmlGeneralization

  • UmlInterfaceRealization

• MyUmlCollaborationInteraction

  • Interaction

    • UmlMessage

    • UmlLifeline

  • UmlAttribute

• MyUmlStateChartInteraction

  • StateMachine

    • UmlRegion

    • UmlPseudostate

    • UmlFinalState

    • State

      • UmlState

      • subsequentStates

    • Transition

      • UmlEvent

      • UmlTransition

　　首先第一次作业在类图分析器中通过三次扫描，第一遍将UML_CLASS、UML_INTERFACE、UML_ASSOCIATION；第二遍将UML_OPERATION、UML_ATTRIBUTE、UML_ASSOCIATION_END；第三遍将UML_PARAMETER、UML_INTERFACE_REALIZATION、UML_GENERALIZATION类型元素放入其对应容器。

　　Base类拥有Class和Interface类的公共部分：属性、方法、继承的接口。Class在其基础上增设了父类superClass和关联关系对端Associations。Operation类除了umlOperation本身外，设置了参数parameters。只需要通过三次扫描，将各类参数放置在自己应处的位置处，就完成了对类图的结构化存储。

　　MyUmlStateChartInteraction类似地通过三次扫描，层次化地存放了7种相关类型的element。一个StateMachine只拥有一个UmlRegion，在region中，分别存在一个初始状态、一些中间状态、很多状态转移和一个终止状态。有特殊之处就是要分开存放1.初始状态为起点的转移 2.State之间的普通转移 3.终止状态为终点的转移，以便后续查找使用。

　　MyUmlCollaborationInteraction通过两次扫描，建立好UML_INTERACTION、UML_LIFELINE、UML_MESSAGE、UML_ATTRIBUTE之间的层次关系。这一模块功能点最为简单，只要通过第一次上机时提供的样例，理解了几类元素之间的层次关系（谁是谁的parent），就很好实现。

　　架构完成后，三次功能点的实现基本都是用一些简单的图算法完成，其中BFS使用频次最高，在遍历图之前，每一步都要对应抛出不合法的的Exception，这里一般使用单独一个读取结点的方法实现。

 

架构设计及OO方法理解的演进

第一单元多项式求导：

　　前两次作业按照ppt中作业提示，按照形式化定义分别实现项和多项式类，结构简单；最后一次作业按照指导书建议进行了一次重构，构建了一个表达式树，以Operator作为树节点组织整个表达式。

第二单元多线程电梯：

　　本单元主要学习并运用了生产者消费者设计模式，这也是继工厂模式之后学习的第二个设计方法。本单元最重要的是学习应用了线程安全的保障：保证所有可能存在的多个线程共享访问的地方都加了锁；保证只在必要的地方加锁，尽量缩小锁的范围。

第三单元JML：

　　这一单元基本不需要考虑架构的设计，是在设计好的架构骨架上添加血肉，但在MyNetwork中的sendMessage方法编写过程中，还是很好地将多个不同类之间的关系清晰地梳理了出来。对于官方给出的Runner类数据读取、处理方式的阅读也促进了下一单元几个分析器类的编写。

第四单元UML:

　　最后一单元综合地考察了对抽象、继承的理解，因为没有整体架构的提示也不是代码填充，在编写之前需要把整体架构画出来，在编写中遇到小问题还要增加、调整原本设计类的属性，比如Base类就是开始设计时没有的，但因为在处理OPERATION类的元素时其既可能属于类也可能属于接口，因此又抽象出了这一个抽象类，让Class和Interface来继承。

 

测试理解与实践的演进

　　第一单元使用了自动化生成测试数据利用随机数生成1000个合法表达式，再利用java输出与sympy得到的求导结果相比较确认目标是否存在bug；第二单元主要手动设计极端条件如捎带超载测试点考察人数上限、TLE的测试点考察电梯性能；第三单元同样侧重考察性能，极端数据会让复杂度不够低的算法TLE。整体调试+单个方法的调试是我主要修复bug的办法。

 

课程收获

　　从时间占比来看，这门课几乎是一门实验课，每周课下写代码+测试+debug的时间绝不少于计组实验，当然通过四个单元的大量练习，也让我收获了不少。从java的基本语法学起，常用容器、好用的对象类，到几种经典的设计模式，到线程之间的安全保障，再到将抽象、继承、多态的设计思想贯彻到每一次设计中，以类的方式组织代码，以对象的形式封装数据，将每个功能需求发配到最合适的类中实现；当然配合使用的工具也都更加熟练，git的穿越、Typora的各种小技巧等等。

 

改进建议

　　1.八次上机实验下来，观感是几次上机难度实在差异过大，有简单的最快可以半小时提交，有困难的最后都因为commit的CD，未及时提交到最后还在写、修改的answer导致没有在规定时间内提交。希望对于困难的上机，比如可以先做预告，如：(1)在训练单元中先行简单练习 (2)在周三理论课最后增加上机内容预告（类似于讲解作业预告） (3)上机前一天提前开放代码库让同学们熟悉上机整体代码架构。

　　2.第一单元、第二单元在第一次作业指导书中就提前预告后两次大概需要完成的功能，这样可以减少推翻重构的概率，从第一次就开始整体思考架构的设计。

　　3.每单元结束后可以发一篇负责本单元的自述，内容可以包括但不限于：(1)三次弱、中、强测测试点的构造思路、每个测试点的打击目标 (2)助教设计的优秀代码架构及开源源码 (3)本单元题目背后真正的考察点（可以让同学们逐一比对自己是否掌握）

 

结语

　　我们路过高山，我们路过湖泊，我们路过森林，路过沙漠，终于到了这里。但也入吴际老师所说，OO不是结束，只是个开始，我们要带着这门课的收获，继续前行，不断精进！

 

 

标签：OO,架构,上机,分析器,课程,设计,UML,单元
来源： https://www.cnblogs.com/chidwick/p/14939141.html