面向对象设计入门四：UML

一.UML设计

本单元作业的要点在于

1.理解UMLelement的各种子类的属性和联系

2.用合适的容器保存图信息，实现对应的方法

第一次作业

解析UML类图，类图中元素包含以下信息：

UmlClass / UmlInterface:

• id：类/接口名称
• name：类/接口对应的独一无二id

UmlAttribute / UmlOperation

• id：属性/操作独一无二id
• name：属性/操作名称
• visibility：属性/操作可见性
• parentid：属性/操作所属的类、接口id

UmlParameter

• parentid：参数所在操作id
• direction：参数的类型

UmlAssociationEnd

• reference：对应的类、接口id

UmlAssociation

• end1：关联一段end的id
• end2：关联另一段end的id

UmlGeneralization

• source：子类、子接口id
• target：父类、父接口id

UmlInterfaceRealization

• source：实现接口的类的id
• target：被实现的接口id

查找类数 <类id， 类名 >

类操作数 、类操作可见性

<类名，Arraylist 类id> 　　<类id，Arraylist 类操作>　　<类操作， <模式名称， 模式>>

类属性数、类属性可见性【子类继承父类属性】

<类名，Arraylist 类id>　　<类id, Arraylist 类属性>　　<继承者， 被继承者>

类关联数、类关联对端【子类继承父类关联】

<类id， 类名 >　　<类id， Arraylist 类端>　　<继承者， 被继承者>　　<对端1， 对端2>

类顶级父类

<类id， 类名 >　　<继承者， 被继承者>

类实现接口【间接继承：子类获得父类接口、接口多继承 】

<类id， 类名 >　　<类id， 实现接口id>　　<继承者， 被继承者>　

类是否信息隐藏等信息

<类id， 类名 >　　<类id, Arraylist 类属性>　　

第二次作业

解析Uml状态图、Uml时序图，状态图包含的元素如下：

UmlStateMachine

UmlRegion

• parentid：对应UmlStateMachine的id

UmlPseudostate / UmlState / UmlFinalState

• id：独一无二的id

UmlTransition

• parentid：所在Region的id
• sorce：原状态id
• target：下一状态id

时序图包含的元素如下：

UmlAttribute

UmlInteraction

• name
• id

UmlMessage

• parentid：所在interaction的id
• source：发出消息的lifeline的id
• target：接受消息的lifeline的id

UmlLifeline

• parentid：所在interaction的id

状态数　　<stateMachine名称，Arraylist stateMachine的id>　　<stateMachine的id， region的id>　　<region的id， state数>

迁移数　　<stateMachine名称，Arraylist stateMachine的id>　　<stateMachine的id， region的id>　　<region的id， s转移数>

后继状态个数　　<stateMachine名称，Arraylist stateMachine的id>　　<stateMachine的id， region的id>　　<迁移source， Arraylist 迁移target>　　

顺序对象个数　　<interaction名称，Arraylist interaction的id>　　<linteraction的id，lifeline个数>

消息个数　　<interaction名称，Arraylist interaction的id>　　<linteraction的id，message个数>

接受消息个数　　<interaction名称，Arraylist interaction的id>　　<lifeline名称， <class的id，lifeline的id>>　　<message的target，<Inyeraction的id， message>>

第三次作业

在三个图的基础上，增加对类图、状态图的检测。

R001：维护一个<classid， <name， Arraylist ids>>的容器。对每个类id，name是其参数或对端end的名字，ids中保存该类该名称的id。当对应name中有超过1个id则重复

R002：对每个类，有且只有一条到达top的有向路径，如果行走过程中出现重复，则代表找到了一种类继承的循环。完成一整条路径的检查，则路径上的所有点都不需要再检查。对每个接口，通过dfs查找有向路径上是否有圈，并保存路径上的点。查找1个点所有可达的点都不需要再检查。

R003：由于类不存在多继承，因此R003中不需要考虑类。对每个接口，用bfs遍历继承树，寻找是否存在重复出现的接口。如果对一个点全遍历后不存在重复接口，则遍历的所有点都不需要再遍历。

R004：间接实现一个接口：父类实现的接口、实现接口继承的接口。对每个类，收集直接实现、间接实现的接口，如果出现重复则异常。

R005：在传递参数的时候对每个有名元素检查。在检查attribute时需排除时序图中的attribute。

R006：对每个参数进行检查，如果属于接口且不是public则异常。

R007：对每个finalstate进行检查，如果存在迁移的source为该finalstate则异常。

R008：对每个初始状态进行检查，如果存在迁移，且迁移对象超过1个，则异常。

二.设计演进

　　纵向来看，从多项式解析、模拟电梯、jml规格、uml设计，对OO的理解越来越抽象，在架构中越来越标准。

　　第一单元继承自寒假两次预习内容，其目的是为了强调对象概念。但不可否认的是第一单元的多次作业，我仍旧使用了大量的面向过程编程的思路，可能是因为这一单元的任务，解析-求导-输出这个过程太显眼了。而且基本上每次作业都会重构。

　　但在第二、三次作业我逐渐在类这个概念上有了比较多的体会，因为项这一概念中所包含的内容因为指导书的要求而增加了。在第二次作业中出现了三角因子，在第三次作业中出现了表达式因子，也使用了迭代。因此在设计这两次任务中，我开始从面向对象来完成方法的角度去填充解析-求导-输出这一过程，对OO的架构开始认识。

　　第二单元是拓宽新领域的内容。在这一单元中引入了多线程，这也使得不同个体承担的任务更加明显。在这种并发性高的场合中，要求对每个模块都做好完全的设计，因此在这个单元不采用架构方法是不行的。整个三次作业中，我使用了最基本的生产者、消费者的共享资源架构，这样的好处是理解起来更简单，更符合生活实际，有助于我对输入线程、控制器线程、电梯线程、生产现成之间通信的理解和规范。缺点是这次作业完成的比较保守。

　　第三单元与前两次作业完全不一样。相比较一、二单元指导书给出解释的方式，jml规格会提高理解的准确度，但是架构的难度却提升了。jml语言本身是只描述方法的语言，不会给出对整个模型的要求。因此jml规格看似给出了很多细节，实质上所有的内容都需要从整体的角度上对容器、算法上做出选择，如group中的二层循环方法，鉴于对时间的需要，使得我们不得不利用addperson、addrelation来维护一个容器，这是基于整体考虑network类和group类的结果。也就是从两个类、甚至三个类的交互中完成方法。

　　第四单元的设计任务更像是对java类、接口概念的复习。与Jml不同，这次没有给出具体的描述，首先需要的是理解Uml三种图的展示形式，从而自主的对各个元素的内容提取，在实现对应方法的时候使用。这可以说是一次综合性的架构测试。在设计上没有做比较花哨的创造，但是花费了大量代码用容器解析元素，目的是降低运行时间，实际效果一般。

三、测试演进

　　OO课程非常让我开心的一点就是我终于迈步对自己代码进行自动化测试的领域。因为这学期自己掌握的时间变多，使得我有机会去花时间尝试这部分。

　　第一单元非常适合进行黑箱测试，因为输入和输出都比较简单。第二次作业我第一次利用python的numpy和xeger工具进行测试，在windows上用一个很简单的批处理文件完成。非常简陋且会出现问题，但是查找出一些Bug，给了我些许鼓励。第三次的作业也因为没有进行随机数据的测试而使得上交公测后才发现了问题，这也给了我要在上交前对内容进行测试的决心。

　　第二单元的时候对于自动化测试已经可以做的比较规范了。给出的结果也比之前更容易确认。但是有些问题还是比较严重，一是两天的互测时间，因为测试机的时长较长，以及对输入数据的要求不甚理解，出现了浪费很多时间却没办法复刻本地错误的情况；二是我花费一下午的时间完成了黑盒测试后，很少在花费时间继续观察他人代码了，两天的时间不足以去阅读多人代码的同时对数据进行测试。综上，互测对我而言成了一个低效率而没有提升的环节。

　　第三单元的时候面临了一个比较重大的问题，就是测试的方式变思路了。原先随机数据的方式不再适用于这次的测试，因为没有准确的数据包。而下载OpenJML未果以及按照规格自动测试工具的问题也让我头疼之余放弃了。从而转用分析 + Junit单元测试的方法。第一次作业完全靠分析，出现了因忽视修改的jml发生的错误，第二次使用了junit测试，除了jml更迭不及时以外，还完全忽视了多个方法的时间问题。这都是完全由于不熟练Junit测试、没花时间寻找相关内容的原因。

　　最后一单元不涉及互测，但是因为完成效果与理解、实现都有着紧密关系，必须对实现的结果进行测试。使用starUML设计了一系列数据对完成效果进行测试，排除了理解以外的问题。

　　我对测试一直采取非常严肃地态度，往往要彻底想清楚整个来龙去脉，确定不会出现问题，才会准备测试，这让我后期很多时候更相信自己的思考内容，而不是诉诸测试本身，走了一段弯路。

四、课程收获

　　OO课程给我的感觉比OS课程要好些，可能是因为idea工具的优势，还有本身作业在时间上的宽限和规律性。我每周的OO安排都是稳定的、不会出纰漏的，尽管出现很多次熬夜、精神紧张、烦躁的时候，但是不会真的如同OS那样让我拖2~3天才找出问题并解决。

　　在面向对象的学习中，首先是从阅读指导书的能力开始，然后逐渐学习从课程内容对作业进行分析、解析，使用面向对象的思想去设计程序模型，套用工厂模式、消费者、生产者模式来解决问题。从jml语言来标准化构建的过程，并对类的关系有了一个准确的梳理。虽然OO本身带给我不小的压力，但是完成后确实有成就感。而且在对作业不得不的要求中对能力也加强了锻炼。

五、改进建议

　　第一，是对我而言互测时间不是很够，当然也有这次普遍OS课程开始时间在周一的原因。测试本身的时间先不说，看5~7个人的代码两天是没什么可能的，认真看1~2个人的代码勉强可以，但一周时间里总会忍不住休息一下，如果测试上不加权重，可能因为低回报率放弃互测和阅读别人的代码。

　　第二，第三单元出现了两次乌龙都是和jml语言修改有关，第一次是jml规格修改后我囫囵吞枣没有注意到关键内容导致的，这个属于我的问题，第二次是我完全没有更新规格的问题，当然这个也得说有我的一部分责任，因为应该时时注意论坛动向，保证作业的改动，但是错误的时候还是特别懊恼，因为我特意延后了看代码的时间。如果没有修改作业内容的事情发生就好了，或者能缩减在周二晚上就更好了，或者给出一个更明确的提醒机制，比如@所有人、发短信之类的。

　　第三，我的电脑端无法加载OO测试的stdin、stdout、测试txt文件，只有手机可以，不知道是什么原因。

　　第四，实验测试的答案希望公布，结果希望给到人。虽然我这学期的测试成绩很差，但还是说为了学习效率可以看见正确的答案。

六、线上学习体会

　　因为没有线下学习过OO，所以也没有什么对比的。我认为相比较OS，OO的线上体验更好，首先OO实验正常进行了，唯一的问题是线下有没有同学相互沟通的问题，这个可能有，但是至少实验本身的内容是有的。其余的OO课程内容，无论是网课还是作业在家个人学习都不会降低效率，甚至可能因为环境而提高效率。老师在群里面的效果很好，保证了我们都正常完成了课程，而且线上交流更没有门槛。对每次作业的提示、解释、交流论坛也很有效率。就我个人的习惯来讲，我其实更喜欢线上的学习。