The UMLParser！

前言

　　我已听到假期的呼唤！　　　　　　　　

目录

一、架构设计

二、四个单元架构设计演变

三、测试的演进

四、课程收获

五、改进建议

一、架构设计

　　本单元对于需要频繁使用的元素类，进行了包装，例如讲UmlClass包装为MyCLass，将Attribute、associations等包装在内，便于进行查询与计算。

　　此外，对于每个部分，都加入了Manager便于管理，即：ClassManager、OperationManager、InterfaceManager、StateMachineManager。

二、四个单元架构设计演变

　　前两个单元架构设计更为复杂，因为完全由自己设计，所以刚开始是难免混乱，但经历了重构与调整后就主角变得条理清晰。第三个单元不需要自己设计架构，只需要实现即可，第四个单元虽然整体结构有遵照，但是各个元素的内在联系还是需要自己去设计。

　　在第一个和第四个单元中，架构设计的重点在于如何建立、存储、查询、更新元素之间的关系。在第一单元中是Term、Factor、Expr之间的组织关系，第四单元是Class、Atrribute等元素的组织关系。这一部分可以分为三步走。第一是弄清楚元素本身的关系，事实上，架构中元素的关系是对元素本身的关系的模拟与细微调整。比如Attribute、Operation、Association本身作为Class的内含元素，在MyClass中作为属性元素存在。而SuperClass、Subclasses、Interfaces都是Class与其他元素的关系，为了便于查询也可以作为属性元素存储。第二是决定好各种java中类的设定与如何联系，如果说刚才关注点集中于元素本身，第二步则关注于代码实现，比如Class继承的关系是指记录subClass还是双方都记录等等。第三部则是更细致的容器等的选择。

　　在第二单元中，架构设计的重点是模拟运行机制。难点在于良好的实现多线程以及性能。困难之处在于， 如何完成模拟过程，以及如何实现较好的调度换乘策略。首先是确定哪些部分作为线程、哪些部分是共享对象需要加锁，其次要注意多线程设计原则。同时，为了具有良好的可拓展性，要关注每个类的功能的良好接口与普遍性。

1. 表达式化简

　　将整体代码分为 读取、解析、合并 三部分。并且表达式的中心结构使用Expr - Term - TrianglePower + Expr。三次作业都通过拓展完成，在第二次拓展过程中由于新增三角函数所以改变了表达式的中心结构，花费了较大的精力。可见中心结构必须具有良好的拓展性。

2. 电梯调度

　　将整体代码分为 等待队列、调度、电梯运行 三部分。并且尽可能将横向电梯和竖向电梯做对称化处理，便于更好的实现与更清晰的结构。不过坏处在于失去了横向电梯循环的特性。调度策略采取改进的Look。线程间通过共享队列进行交互。第二次作业选择了重构，第三次作业则是拓展。

3. 社交网络模拟

　　本次架构JML已经帮助写好。主要也可以分为三部分 元素、关联、信息系统。每次拓展也都比较简便。不过为了提高性能在算法、容器以及过程的选择中花费很多精力。而这部分在其他单元却思考并不多。

4. UML解析器

　　将整体代码分为 类图、顺序图、状态图 三部分。这是由于UML元素本身性质决定。三次作业也均通过拓展完成。

三、测试的演进

1. 第一单元

　　由于第一单元测试数据并不复杂而且容易判断对错，对于表达式的测试仍局限于自己构造边界数据，写出可能出现问题的点，比如边界数据、复杂求和、三角等，将它们糅杂在一起徒手造出数据。

2. 第二单元

　　对电梯架构与实现本身花费了很多时间，导致测试包括构造数据等花费的时间大大压缩，加上自身的懈怠，几乎没有足够的测试，导致第二单元出现的bug是最多的。这也使我在后续加大了测试的力度。

3. 第三单元

　　第三单元我自己写了评测机。主要聚焦于两方面，一个是随机构造数据，用于检验各种奇奇怪怪的情况；另外是通过特定构造大量耗时的数据，来检测是否超时。正确性方面通过与舍友的对拍检验。每周每次作业基本上会拿出一整天跑自动评测机。所以正确性上没有出现bug，但是第二次作业中一个特殊指令我在写评测机时忽略了考虑。在第三次拓展评测机时，我更改了思路。用于测试性能的部分我不再是通过人为的干涉，而是遍历所有的数据，每一个都进行了大量的性能测试。这样避免了上次出现的问题。

4. 第四单元

　　第四单元的测试数据极其复杂，所以仍然通过评测机随机生成模型，不过在测试查询指令时，将所有指令进行遍历。将结果与舍友对拍。保证了正确性。

主要遗留问题时没有使用Junit工具进行测试，这一点可以再后续在进行深入学习与拓展。

四、课程收获

　　现在我们常说的艺术，往往具有技术性、形式性、审美性的特征，高德纳的巨著中也命名为《The art of computer programming》。我们该如何理解应用呢？对于每次架构其实我们都会有直觉似的美感，或认为是代码屎山，或成就感满满。而这种直觉的美感往往会影响到准确度上。而这种直觉的美感正式艺术的灵魂元素。

　　所以，我们应当像对待艺术一样，首先我们要整我好基本的形式、原理、技巧。很多设计模式，代码语法都是形式，而原理则是一些数学知识以及设计原则，技巧是我们在平常积累的用法或经验。更重要的是，我们要利用好这种直觉的美感。这样我们可以收获更多的快乐、动力与成果。

五、改进建议

1. 可以增加一些对于基础知识的讲述，或者给出更多的一些网站、博客。或者在预习课程中，或者在教程中，能够帮助同学们更好的理解，也便于查阅。比如：UML语言、设计模式、Junit以及其他拓展部分。

2. 实验部分可以能够及时反馈对错，并给出正确答案。

3. 第三单元训练我认为有两个主要问题。第一个是很多同学们仅仅根据JML描述去完成代码，而忽视了在整体架构中的作用与组成。我认为JML语言的优势不仅仅体现在实现“部分”上的便利，更在于最后整合架构时的清晰。而现在同学们只去体会实现上的便利。具体来说，由于整体设计已经由助教完成，所以只需要同学们完成每个方法的部分即可，这样导致很多同学只去看函数的要求，失去了关注JML为整体的结构带来便利的过程。在一定程度上失去了面向对象的意义而单纯变为算法题。我个人想到的改进措施是在前两次作业中，我们主要完成的是“部分”。针对我们的社交网络来说，在第一次作业中，我们可以完成整体的个人、群组以及相互关系的类，在测试时将学生完成的“部分”（也就是这些类）嵌入到我们的主类中进行测试（因为是查询类指令，可以通过完成方法来实现查询类的状态或属性）。在第二次作业中，则完成收发信息的部分。最后在第三次作业，让学生们自己完成最后的架构。比如如何增加人、如何增加群组、如何收发消息，通过调用那个方法实现。通过这样的方式，让同学们能够更好的体会到JML在工程中的优势，能够体会到将部分写好的重要性。第二个问题是关于JML的描述。由于JML描述由助教给出，所以限制了同学们对问题本身的思考。可以通过增加一次关于JML的讨论课或者实验课，让同学们针对某几个方法写出更好的JML描述。由于时间仓促，没有进行深入的分析与思考，可能有些部分不完善或者不全面，希望老师助教见谅。

六、结语

　　科学和艺术是一枚硬币的两面。——李政道