BUAA_OO_UML_OO总结
（1）总结本单元两次作业的架构设计
对于uml每个类型都进行构建，发现class和inference可以公用
继承和接口实例化数据结构一样
然后进行构造首先将所有模型输入都存入
参数传入函数
函数带入类或者接口
构建关联关系，构建接口实现关系，构建继承关系
UMLClass
举例：{"_parent":"AAAAAAFF+qBWK6M3Z8Y=","visibility":"public","name":"Door","_type":"UMLClass","_id":"AAAAAAFqpiMge7NXBnk="}
- _parent 对应的是父类的id，如果是顶层父类，对应的是一个特定的值
- visibility对应的是类的可见性
- name对应的是类的名字
- _type对应的是该标签的类型，在这里UmlClass对应的是类
- _id对应的是类的id
UMLOperation
举例：{"_parent":"AAAAAAFqpiMge7NXBnk=","visibility":"public","name":"Door","_type":"UMLOperation","_id":"AAAAAAFqpiQWH7O0bzI="}
- _parent对应的是该操作所在方法的id
- visibility是该操作的可见性
- name是该操作的名字
- _type对应的是该标签的类型，在这里UMLOperation对应的是操作
- _id对应的是该操作的类型
UMLParameter
举例：{"_parent":"AAAAAAFqpiRcY7O7pzM=","name":null,"_type":"UMLParameter","_id":"AAAAAAFqpim3MbPYrBA=","type":"boolean","direction":"return"}
- _parent对应的是该变量对应的操作的id
- name对应的是变量名称
- _type对应的是该标签的类型，在这里UMLParameter对应的是操作变量
- _id对应的是变量的id
- type对应的是变量的数据类型
- direction对应的是变量的方向，如果是参数，则是in；如果是返回值，则是return
UMLAssociation
举例：{"_parent":"AAAAAAFqpiMge7NXBnk=","name":null,"_type":"UMLAssociation","end2":"AAAAAAFqpyLHQ1BBCwQ=","end1":"AAAAAAFqpyLHQ1BA8jU=","_id":"AAAAAAFqpyLHQ1A\/uHQ="}
- _parent对应的是相互关联的两个类中的其中一个的id
- name对应的是关联名称
- _type对应的是该标签的类型，在这里UMLAssociation对应的是关联
- end1对应的是其中一个UMLAssociationEnd的id
- end2对应的是另一个UMLAssociationEnd的id
- _id对应的是关联的id
UMLAssociationEnd
举例：{"reference":"AAAAAAFqyyuTsa1CnU8=","multiplicity":"1","_parent":"AAAAAAFqpyLHQ1A\/uHQ=","visibility":"private","name":"locker","_type":"UMLAssociationEnd","aggregation":"none","_id":"AAAAAAFqpyLHQ1BBCwQ="}
- reference对应的是该UMLAssociationEnd所对应的类的id
- multiplicity对应的是该关联端对应的个数
- _parent对应的是所在的关联的id
- visibility对应的是该关联端的可见性
- name是该关联端的可见性
- _type对应的是该标签的类型，在这里UMLAssociationEnd对应的是关联端
- aggregation由于本次作业没用到，单纯根据英文的话是聚合
- _id对应的是关联端的id
UMLInterface
举例：{"_parent":"AAAAAAFF+qBWK6M3Z8Y=","visibility":"public","name":"Interface1","_type":"UMLInterface","_id":"AAAAAAFq5hWfnsrejMQ="}
- _parent对应的是父接口的id
- visibility对应的是该接口的可见性
- name对应的是该接口的名字
- _type对应的是该标签的类型，在这里UMLInterface对应的是接口类
- _id对应的是该接口的id
UMLInterfaceRealization
举例：{"_parent":"AAAAAAFqpyKBqVAUSAo=","name":null,"_type":"UMLInterfaceRealization","_id":"AAAAAAFqyz3DUrUBj9E=","source":"AAAAAAFqpyKBqVAUSAo=","target":"AAAAAAFqyyuTsa1CnU8="}
- _parent对应的是该接口实现所在的类的id
- name对应的是该接口实现的名字
- _type对应的对应的是该标签的类型，在这里UMLInterfaceRealization对应的是接口实现
- source对应的是实现该接口的类的id
- target对应的是实现的接口的id
UMLGeneralization
举例：{"_parent":"AAAAAAFrAn2LyzRtr9Y=","name":null,"_type":"UMLGeneralization","_id":"AAAAAAFrAn4MhTUNujA=","source":"AAAAAAFrAn2LyzRtr9Y=","target":"AAAAAAFrAn2lWzSXWGM="}
- _parent在这里等于子类id，但是子类id最好从source中获得
- name对应的是该泛化的名字
- _type对应的对应的是该标签的类型，在这里UMLGeneralization对应的是泛化
- _id对应的是该泛化的id
- source对应的是子类id
- target对应的是父类id
（2）总结自己在四个单元中架构设计及OO方法理解的演进
第一单元
第三次作业我依旧想继承第二次作业的思想，我用加号分割项用乘号分割因子，但是因子遇到了嵌套的情况，所以用括号再递归分割因子
Pol类用来把顶层类我们的表达式用加号分割成每一项
对于每个项求导我们要用到链式法则和复合函数求导规则，我用用乘号分割因子，每个因子构造顶层Po用一个循环实现链式法则求导
如果遇到符合第二次作业的PolyTerm没有出现嵌套规则的可以直接求导
如果遇到嵌套我们利用复合函数求导规则f(g(x)) ' = derva(f(x))derva(g(x))
我用一个简化算法节省复杂度把g(x)替换成x既可f(x)可以直接构造PolyTerm求导，然后再替换回来可以节省复杂度
首先为了防止因为括号内的加号和乘号或者sin(x)*cos(x)，影响我的分割我采用一个堆栈维护括号匹配
第二单元
电梯运行一个线程Elevator,输入控制一个线程Call
一个物理电梯控制表可以完成移动和进出人功能，一个电梯请求表用来调度和存储请求
电梯运行利用状态机OPEN,CLOSE,WAIT,UP,DOWN,STOP,GO，每个楼层电梯都会STOP判断需要开门如果开门
刚开始写没有考虑电梯系统终止的条件，因为我们存在上上下下的情况
第三单元
第一次采用hashmap以pair<>为key存储边，value存储边的个数，同样点也这样存储。
对于removebyid和removebypath，采用双向hashmap，path为key存储边，value存储边的值，另一个反之
第二次加入了图
用佛洛依德算法，利用边集重构
每次加入和删除操作重新构建最短路径
第三次综合了地铁路线
我们构建不同的图，最短路径，最低价格，最低满意度，构建不同的权重图，但是用一样的迪杰斯特拉算法
对于换乘采用了拆点算法
OO方法理解的演进
oo从直接实现到设计架构数据结构，我感觉数据结构决定代码效率和代码数量，优良的架构会有很好的拓展性和算法效率
对于多个数据结构，那些我们能整合，或者继承，组合，使结构清晰简单。
（3）总结自己在四个单元中测试理解与实践的演进
测试是考验程序鲁棒性的重要手段，刚开始测试在于找一些临界值，非法输入，以及不易出现的特殊情况，
由于互测人数较多，后来学着用脚本，大量自动随机测试，比对输出结果
对于多线程的测试，评测机是很难模拟每次测试环境，经常线程的不安全竞争造成测试的多样性
后来学习利用junit进行类的测试
（4）总结自己的课程收获
oo课程提升了我对java语言，面向对象语言的认识，对于程序设计结构的能力，以及debug和调试能力，
工程的维护，继承，接口，函数工厂，以及多线程，线程安全。
（5）立足于自己的体会给课程提三个具体改进建议
1.互测的设计，我感觉很鸡肋，多线程的评测会很玄学，一个room大量的人数不利于我们阅读理解别人代码
2.课上实验，能对课上学习知识温习一下，我大概就是边上机边学习，感觉任务量很大，完成效果会不尽人意
3.理论课，我感觉有一些java的设计模式还是有必要介绍的，jvm之类的
