一、第四单元作业总结
本单元罕见的仅有两次作业,经过三个单元的锤炼,阅读源代码、分析数据结构的能力终于随着课程的结束有了些许增长(笑哭)关于UML的两次作业主要考察了对java工程源代码的阅读与理解以及结合题目所给指令实现官方接口继承后接口的方法,首先需要对UML各部分结构内部以及之间的联系有所了解并掌握其特有属性后再入手指令的实现(菜菜的我只得在讨论区抱大腿)
UML第一次作业
- 需求说明
本次作业最终需要实现一个UML类图解析器,可以通过输入各种指令来进行类图有关信息的查询
具体需实现方法如下:
1 public interface UmlInteraction { 2 int getClassCount(); 3 4 int getClassOperationCount(String var1, OperationQueryType var2) throws ClassNotFoundException, ClassDuplicatedException; 5 6 int getClassAttributeCount(String var1, AttributeQueryType var2) throws ClassNotFoundException, ClassDuplicatedException; 7 8 int getClassAssociationCount(String var1) throws ClassNotFoundException, ClassDuplicatedException; 9 10 List<String> getClassAssociatedClassList(String var1) throws ClassNotFoundException, ClassDuplicatedException; 11 12 Map<Visibility, Integer> getClassOperationVisibility(String var1, String var2) throws ClassNotFoundException, ClassDuplicatedException; 13 14 Visibility getClassAttributeVisibility(String var1, String var2) throws ClassNotFoundException, ClassDuplicatedException, AttributeNotFoundException, AttributeDuplicatedException; 15 16 String getTopParentClass(String var1) throws ClassNotFoundException, ClassDuplicatedException; 17 18 List<String> getImplementInterfaceList(String var1) throws ClassNotFoundException, ClassDuplicatedException; 19 20 List<AttributeClassInformation> getInformationNotHidden(String var1) throws ClassNotFoundException, ClassDuplicatedException; 21 }
- 架构设计
- 第一次作业需要实现10个方法,主要是对类、类的属性、类的方法以及接口、类实现接口、类继承、接口继承的考察,针对其传入的不同的UMLElement分析判断其类型,利用HashMap储存映射信息如Id和name的映射、子类与父类的映射、类与其所含属性、方法的映射等,共有9类元素:UMLAssociation、UMLAssocciationEnd、UMLAttribute、UMLClass、UMLGeneralization、UMLInterface、UMLInterfaceRealization、UMLOperation、UMLParameter,分别对9类元素建Mybulabula类用以对HashMap等数据结构储存数据的完善,例如MyUmlClass类:
1 public class MyUmlClass { 2 private HashMap<String, Integer> classToNum; 3 private HashMap<String, String> classToId; 4 private HashMap<String, String> idToClassname; 5 6 public MyUmlClass(HashMap<String,Integer> classToNum, 7 HashMap<String, String> classToId, 8 HashMap<String, String> idToClassname) { 9 this.classToNum = classToNum; 10 this.classToId = classToId; 11 this.idToClassname = idToClassname; 12 } 13 14 public void add(UmlElement element) { 15 String name = element.getName(); 16 String id = element.getId(); 17 classToId.put(name,id); 18 idToClassname.put(id,name); 19 if (!classToNum.containsKey(name)) { 20 classToNum.put(name,1); 21 } 22 else { 23 int temp = classToNum.get(name); 24 classToNum.put(name,temp + 1); 25 } 26 } 27 }
MyUmlClass构造函数用以传入数据结构参数,HashMap、HashSet等等,add方法用以每次传入新元素时维护数据结构
- 根据需要实现方法所传参数找到对应的My类以及相应数据结构,进行操作即可
UML第二次作业
- 需求说明
扩展类图解析器,使得可以支持对UML状态图和顺序图的解析,并可以通过输入相应的指令来进行相关查询。
在所解析的UML模型基础上,按照规定的规则检查模型中是否存在违背规则的情况,并输出相应信息。
所继承接口扩展为MyUMLGeneralInteraction,这一总类包含四部分需要继承的接口:MyUMLClassModelInteraction(第一次作业类图解析器)、MyUMLCollaborationInteraction(顺序图解析器)、MyUMLStateChartInteraction(状态图解析器)、MyUMLStandardPreCheck(判断模型正确性),新增需要实现的接口为后三个接口,具体需实现方法如下:
1 public interface UmlCollaborationInteraction { 2 int getParticipantCount(String var1) throws InteractionNotFoundException, InteractionDuplicatedException; 3 4 int getMessageCount(String var1) throws InteractionNotFoundException, InteractionDuplicatedException; 5 6 int getIncomingMessageCount(String var1, String var2) throws InteractionNotFoundException, InteractionDuplicatedException, LifelineNotFoundException, LifelineDuplicatedException; 7 }MyUMLCollaborationInteraction
1 public interface UmlStateChartInteraction { 2 int getStateCount(String var1) throws StateMachineNotFoundException, StateMachineDuplicatedException; 3 4 int getTransitionCount(String var1) throws StateMachineNotFoundException, StateMachineDuplicatedException; 5 6 int getSubsequentStateCount(String var1, String var2) throws StateMachineNotFoundException, StateMachineDuplicatedException, StateNotFoundException, StateDuplicatedException; 7 }MyUMLStateChartInteraction
1 public interface UmlStandardPreCheck { 2 default void checkForAllRules() throws PreCheckRuleException { 3 this.checkForUml002(); 4 this.checkForUml008(); 5 this.checkForUml009(); 6 } 7 8 void checkForUml002() throws UmlRule002Exception; 9 10 void checkForUml008() throws UmlRule008Exception; 11 12 void checkForUml009() throws UmlRule009Exception; 13 }MyUMLStandardPreCheck
其中StandardPreCheck较为特殊,是对模型正确性的检验须符合002、008、009规则:
- 002规则
针对类图中的类(UMLClass),其成员属性(UMLAttribute)和关联对端所连接的UMLAssociationEnd不能有重名(比较坑的点是attribute和end的名字是放在一起算的,并不是分开计算是否重名,另外有的end名字为空,注意getName.equals方法的使用)
2. 008规则
该规则只考虑类的继承关系、类和接口之间实现关系,以及接口之间的继承关系。所谓循环继承,就是按照继承关系形成了环
3. 009规则
该规则考虑类之间的继承关系、接口之间的继承关系,以及类对接口的实现关系,包括直接继承或间接继承
- 架构设计
- 通过将GeneralInteraction的拆解,避免了单个文件行数过多的问题,这次同样和第一次作业的架构相同,通过对元素类My化的建立以及相应HashMap储存数据的结构的维护来进行查询等操作,以实现新增的方法:对顺序图、状态图、是否符合规则的查询
- 状态图中对后继状态的查询以及规则检查主要运用了bfs算法,优先广度遍历所需元素进行判断:
1 //方法通常如下 2 List<String> list = new ArrayList<>(); 3 list.add(element); 4 int begin = 0; 5 while (begin < list.size()) { 6 for (String elementNeed : needMap.keySet()) {//当前查询元素相关的关系Map,如类的继承关系、状态后继关系等等 7 if (something need) { 8 list.add(); 9 } 10 } 11 begin++; 12 }
二、四个单元作业架构设计及OO方法理解的演进
1、第一单元
第一单元是接触oo以来真正意义上的第一单元作业,主要是对多项式求导的考察,从第一次作业的对类使用的困惑、整个project只有一个类慢慢发展
到第二次作业将多项式的处理拆分成几个小类去处理,到第三次作业,沿用前两次作业的成果,利用递归下降的思想将大而复杂的任务进行降解,分成多
个小任务汇总完成。第一单元让我最印象深刻的是对任务的拆解处理,代码块的分工合作以及在初始完成任务时要有一个良好的架构,同时学会沿用、复
用代码,有现成的库函数不自己造车轮(BigInteger)
2、第二单元
第二单元是非常有趣的一个单元,它打破了我代码作业输入为数值的僵局(笑哭),这次作业的输入是用户的需求,更加贴近了现实生活,也扩展了
面向对象的“对象”在我心中的包含范围,体现出oo的良好适用性。第二单元的架构设计相对于第一单元要好很多,类的分解更加合理简洁且规范,尤其是
第三次作业的多部电梯的智能调度,输入类、分配器类、电梯类、主控制类的合理分配以及对前两次作业代码的复用让整个project更加清晰,也增强了每
个类的关联性和内耦合性。这个单元的作业让我印象深刻的是处理问题时边界数据的考虑要足够充分,以及测试样例的丰富性、全面性需要进一步加强,
从而增强代码的抗压性。
3、第三单元
第三单元也是很有意思的一个单元,之前接触过的“注释代码”被规范化语言JML取代,JML让我进一步意识到java的泛用性、安全性以及易维护性,在
相应的JML规则约束下,对自己每个方法、成员变量赋以逻辑严谨的JML语言描述,使得方法的逻辑更加明晰以及每个临界情况的触发条件、异常的抛出
条件简洁明了。本单元的任务主要是讲写好的JML语言翻译成相对应的代码,表面上看上去只是简单地翻译而已,但实际上JML语言并未对编写者使用的
数据结构种类进行描述,因此这一单元的存储数据的数据结构以及算法实现很是关键。第三次作业便是由于前两次作业对架构的把握不足,“走小路、钻牛
角尖”使得第三次作业的算法无法在前两次作业的数据结构基础上实行,所以在完成任务时不能只着眼于这一次的过程,要有可拓展性以及对将来任务的预
期,这也是oo为何叫面向对象而不是面向过程。
4、第四单元
第四单元主要是对UML图的解析,需阅读的代码量以及整个project的代码量都达到了四个单元作业之巅,这个单元的架构我事先做了较好的安排和布局,
虽然建的类的数量较多,但针对性较强,覆盖UML图涉及的每个UMLElement,同时捆绑HashMap及其嵌套记录多个一级映射以及二级映射关系方便查询,
这个单元作业完成质量较高,架构以及数据结构的考虑较为到位,也算是自己在这么多次的摸爬滚打中学到了些东西吧
三、四个单元中测试理解与实践的演进
之前对输入测试的理解十分简单,就是自己琢磨几个数据在控制台输入就完事儿了,随着单元作业的递进深入,表面上看测试样例越来越长,测试代码的方法
也越来越高比格,从第一作业的多项式求导利用Python的自带Xeger包进行随机字符串的生成(给定字符串的正则表达式)进行测试到后来的脚本化测试,同时对
多人的project进行测试并比对输出以及测试类的书写。IDEA强大的plugins以及解析包真滴牛皮,而这个过程让我深刻地意识到,每个工程不是简单的代码堆砌就结
束的,那仅仅是开始,代码的架构评测、正确性测试以及复杂度分析都是工程的有机组成部分。oo不只有bug还有疯狂测试debug。
四、课程收获
oo不仅给我带来了四个单元共计15次作业,更让我意识到了许多代码之外的面向对象而非面向过程、大需求降解成小需求、类不只有Main类等思维方式,同时
每次作业不是简单的完成代码、填补完函数就结束了,更需要有一个良好的架构做基础需兼顾正确性以及易维护性、可扩展性,oo单元作业的设计模式便是很好地
锻炼这种层层递进、考虑整体架构的能力,同时每个单元最后的博客总结又很好地把之前几次作业的问题与收获记录下来,形成可追溯的经验指导,对之后的学习提
供了很大的帮助。
五、立足于自己的体会给课程提三个具体改进建议
首先很感谢oo课程组以及助教们的辛勤付出和对更好的oo做出的十分努力,每年都是一次全新的oo体验当然离不开oo课程团队以及同学们共同的提议以及改革
推进,以下是笔者的几个小建议,希望能为oo课程更好的明天助一份力!
1、适当下调强测性能分的比例
性能分确实可以激励学有余力的同学讲自己的代码进一步优化,在保证正确性的情况下减少算法复杂度,但有些时候对性能分
的追求会导致面向过程扩散化,而不是针对一类对象去设计代码,有悖于oo的面向对象设计意图。建议可以在加强下中测、强测的数据强度,适当减少性能分的比例。
2、实验课可以重新设计一下考察内容
这学期有很多次实验课是考察的上午理论课刚讲的新内容,对内容的不太熟悉导致知识运用成了问题,下午实验课就很懵,所以建议下午实验课前加强知识预告
和理论课与实验课的协调,从而更好地达到学有所用。
3、作业源函数和需求分析可以再详细一些
第三、四单元作业涉及到较多的需求分析与源代码阅读,理论课上对作业的主体对象的介绍与作业中对象的属性覆盖范围有一定差异,比如UML图每个元素的属
性以及其在输入中相关信息的解读并不都能在理论课相关资料以及指导书中找到,更多依靠的是讨论区的抱大腿。笔者觉得可以对一些作业要求与理论课有出入或者
未提及的项进行附加解释。
祝窝窝越来越好~