oo第四单元作业总结&学期总结
一、第四单元架构设计
1.1 UML类图
由于本次作业增量开发十分平滑，基本没有经历重构，故仅展示最后一次作业的UML图。
1.2 架构分析
需求理解
本单元作业的需求是实现一个UML 解析器，使其支持对 UML 类图、状态图和顺序图的分析，可以通过输入相应的指令来进行相关查询，并能根据 UML 规则进行一定的规范性验证。
整体架构
本单元作业的关键是实现对UML类图，时序图，顺序图中不同元素的层次化建模；最终依据各元素之间的依赖关系将所有元素分为5个层次，并在MyImplementation中对elements中元素进行分析与封装，管理查询方法和规范性验证内容。
对于类图，共封装了四个类：MyClass,MyInterface,MyOperation,MyAssciation;
对于顺序图，共封装了两个类：MyInteraction,MyLifeline;
对于状态图，共封装了三个类：MyStateMachine,MyState,MyTranstion 。
查询与异常抛出层次化
为尽量减少MyImplementation的代码量，以及优化整体代码层次结构，我在设计中尽量将每次查询操作层次化，将主要操作都分散到各个封装的元素类中；对于异常处理，方法仅处理本层次的异常，通过调用下一层次的方法将其他异常交由下一层次处理。这大大优化了代码的层次结构，并减少了单个类的复杂度。
例如在顺序图的getParticipantCreator查询中，将操作与异常处理分三次进行：
public UmlLifeline getParticipantCreator(String interactionName, String lifelineName)
throws InteractionNotFoundException, InteractionDuplicatedException,
LifelineNotFoundException, LifelineDuplicatedException,
LifelineNeverCreatedException, LifelineCreatedRepeatedlyException {
if (countInteractionName(interactionName) == 0) {
throw new InteractionNotFoundException(interactionName);
}
if (countInteractionName(interactionName) > 1) {
throw new InteractionDuplicatedException(interactionName);
}
return getInteractionWithName(interactionName).getParticipantCreator(lifelineName);
}
public UmlLifeline getParticipantCreator(String lifelineName)
throws LifelineNotFoundException, LifelineDuplicatedException,
LifelineNeverCreatedException, LifelineCreatedRepeatedlyException {
if (countLifelineName(lifelineName) == 0) {
throw new LifelineNotFoundException(me.getName(), lifelineName);
}
if (countLifelineName(lifelineName) > 1) {
throw new LifelineDuplicatedException(me.getName(), lifelineName);
}
return getLifelineWithName(lifelineName).getCreator(me.getName());
}
public UmlLifeline getCreator(String interactionName)
throws LifelineNeverCreatedException, LifelineCreatedRepeatedlyException {
if (creators.size() == 0) {
throw new LifelineNeverCreatedException(interactionName, me.getName());
}
if (creators.size() > 1) {
throw new LifelineCreatedRepeatedlyException(interactionName, me.getName());
}
return creators.get(0).getMe();
}
代码风格问题
主要问题为MyImplementation文件的代码量过多，尽管从第二次作业开始注意将操作进行封装与层次化，最终代码量仍达到了670行左右，不得不通过一些不太优雅的方法（将尾部大括号放至上一行，并删除所有不必要的空行和注释）来通过代码风格检查，实在有些遗憾。
测试与bug分析
由于本次作业大部分时间与烤漆复习时间重合，且代码构造难度较小，故基本只靠肉眼debug，没有主动构造一些测试用例或设计测试程序。在实践过程中发现对着指导书中的要求将整个查询或验证方法过一遍，能够有效地de出在层次化较复杂情况下偶然诞生的小bug，且本次作业的使用的算法都较为简单，故而较少出bug，不再赘述。
二、面向对象架构设计思维总结
第一单元的主题为表达式解析与化简，在本单元中，我第一次接触了面对对象编程的层次化设计，相较于之前的面向过程编程而言，这次的作业设计算得上是为我建立了解决任务问题的一种结构化、程序化的新思路，感觉自己的代码结构由原来的”一波流”逐渐变得有层次、有主次、有详略，属实是为我打开了一扇面向对象的大门，不禁感叹java yyds。
第二单元的主题是电梯与多线程，刚接触多线程的时候对wait、sleep、notify的概念有些不明所以，在第一次作业的搭建中也屡屡碰壁，后来才逐渐理解了诸如生产者-消费者模式，锁的竞争与分配，规避轮询与死锁，输入流与调度流等概念，对多线程的设计有了初步的掌握。
第三单元的主题是JML规格理解与契约式编程，直接给出代码整体架构并让照着给出的JML规格写代码的操作让我感觉这门课的难度从本单元终于开始大幅降低。在实验课和研讨课试着写了一些简单的JML，感觉自己可能永远不会再去尝试写一些比较复杂的JML……通过了解契约式编程与防御式编程的理念，让我感觉到让自己的代码完美契合需求在团队合作编程中是一件多么重要的事。
第四单元的主题是UML解析器的实现，从本单元作业中体会到了java语言层次化设计的美妙，以及在大规模工程代码中使操作和异常处理具有层次化的重要性。同时这一单元要求我们精确地理解 UML 模型中各个元素的含义和父子关系，引入了属性耦合度、继承深度等概念，使我们真正对UML图有了比较深入的理解。
三、测试思想及方法总结
代码测试是开发过程中一个不可或缺的过程，如何根据需求构造出有效的数据也是我们在设计过程中不得不认真思考的问题。
在设计过程中，我主要采用的是手动构造特殊边界数据以及利用python程序来生成大量数据进行黑箱测试和代码对拍。在实践中取得了还不错的成果，但对一些隐藏较深的bug还是难以测出。
当然，除了测试之外，要想我们的程序少出bug，最重要的还是在设计过程和编写代码的过程中要认真思考，逻辑清晰，边写边测，这样才能减少我们程序出现bug的次数。
在hack过程中，除了一些共性的方法复杂度和边界条件bug，想要攻破别人的代码还是得靠观察代码，但我们在实际工作中不可能让别人来通过阅读完整代码的方式来帮我们debug；所以在经过初步充分测试后，在代码实际使用过程中不断发现新问题并及时修复可能是一个比较可行的策略。
四、课程收获
(1)思想上，学习了面向对象的代码设计思想，对代码规格化，层次化，工程化以及契约式编程的概念有了较深入的了解
(2)语言上，学习了java语言，并积累了较充分的java代码编写和测试经验；对表达式解析，递归下降，多线程的设计，图和树的构建与查询等内容有了较深了解
(3)在研讨课上积累了与他人共同交流代码设计的经验，意识到了相互交流对于程序员来说有着重要意义
(4)体会到了如Jetbrain所设计的现代化IDE的优越之处，在用idea编程的过程中使用了诸多插件，认识到白嫖的快乐
(5)由于理论课的教学内容更接近一种概述与抽象提升，对基础知识的自学要求较高，在编写代码的过程中查阅了大量资料并自学了诸如多线程设计的各种知识，提升了自行利用浏览器和网络解决问题的能力
(6)复习了关于图和树的一些算法，对于c语言和数据结构的理解更加深刻
五、对课程的建议
(1)希望增加关于如何构造测试用例和利用python代码设计评测机的教学或自学资料
(2)既然有研讨课这样一个不错的平台，希望能邀请一些现役程序员来介绍目前的程序员行业工作和薪资情况，讲述未来可能的程序员发展方向以及行业前景，增加或减少同学们对于未来发展的信心(
(3)希望能更新课程的具体教学内容，介绍一些常用的java工程开发框架，如Spring等
