oo作业总结报告2

第五次作业 多线程电梯

多线程同步和控制的设计策略

  1. 明确类和对象,以及是否区分对象实例。具体类可以从类图中看出;
  2. 明确线程的类型和数量。输入作为一个线程,调度作为一个线程,三个电梯独立工作,互不影响,分别是一个线程;
  3. 明确线程之间共享的数据,控制同步,以及保证线程安全。输入线程将输入存放在请求队列中,调度类访问请求队列中的请求,所以对请求队列的操作需要做到互斥,即要加锁;电梯线程接受到请求后处于运动状态,其各个属性参数在不断变化,而调度器调度时需要访问电梯的属性状态,所以为了保证得到的是准确数据,改变和访问电梯状态的操作需要上锁,做到互斥;

类图

  

设计方案

  这次电梯可以看做是生产者消费者模型,其实发现,如果能够找到一种模型来适应工程,其实核心的设计模式就已经出来了。其中,当请求队列不空时,调度器就从请求队列中取请求进行调度,为空时,调度器就需要等待,知道请求队列中有请求是,再将调度器唤醒。而每个电梯都有自己的执行请求队列,当这个请求队列不空时,唤醒该电梯线程,为空时,等待,用到了两次生产者消费者模型。其他关于调度的算法和前两次电梯基本差不多,就是多了电梯之间的选择。

度量

OO度量

  可以看出,调度器的圈复杂度标红了,复查代码发现这个方法的代码重复率比较高,三种情况,基本是一样的代码,应该是当时懒了,设计原则的意识还很弱,导致圈复杂度较高;对于重复的代码,便可以抽象出一个方法,用起来也十分简明,复杂度也会有较大的改善。

Bug分析

       此次多线程电梯调试花了很久时间,由于时间很紧,就只实现了基本的功能,对于指导书要求的严格的时间输出,没能实现,挂了几个点。互测的时候拿到一个只能识别格式的代码,基本功能都不能实现,所以测试也较为容易,没去深究更小概率的bug。

 

第六次作业IFTTT

多线程同步控制的设计策略

  1. 明确类和对象,判别是否区分对象实例。从类图中可以看出该工程的各个类;
  2. 明确线程的类型和数量。一个文件一个线程,一个目录一个线程,三个动作三个线程。这次的线程类型是确定的,但是文件线程的数量却是动态的,不确定的,需要根据输入的监控文件对象个数来确定,但是好在程序是在已经确定了输入后才真正开始运行,这么说其实线程的数量也是确定的。
  3. 明确线程之间共享的数据,控制同步,以及保证线程安全。这次实现的是对文件的监控,以及触发动作,由此引入了快照这一概念。文件属性是作为此次工程的核心,也是共享数据,所有的操作都是围着它转的,首先是有一个文件安全类,专门提供对文件的一系列操作方法接口,必须保证是互斥的,文件监控线程需要访问文件的属性,必须保证此刻获取到的文件属性是正确的以及最新的,比较过程为和快照对比。

类图

  

设计方案

       整体的设计思路是根据输入的IFTTT构造监控线程,初始化快照,当监控到变化需要触发操作时,触发相应线程的更新快照,快照是作为监控线程对象的一个属性存在的,监控线程保持一定周期的频率扫描文件。

度量

  

  

度量分析 

  对目录监控的函数出现圈复杂度过高的现象,其中主要是用了两重循环和if条件嵌套,对于目录的监控,需要检测目录下的每一个文件,而目录下还可能有目录,所以在和快照比较的时候嵌套就复杂了些,尝试中发现要是将这个对比过程在抽象出一个函数,圈复杂度就会好很多,还是需要注意单一性原则,实现功能模块化。

 

第七次作业

多线程同步和控制的设计策略

  1. 明确类和对象,以及是否区分对象实例。类图中可见;
  2. 明确线程的类型和数量。输入一个线程, 调度器一个线程,100辆出租车100个线程,计算路径的线程。
  3. 明确线程之间共享的数据,控制同步,以及保证线程安全。输入和调度器共享用户请求队列,所以请求队列为共享数据,需要保证互斥原则,调度器获取出租车状态信息,出租车自动改变状态信息,所以出租车的状态信息为共享数据,需要保证访问互斥。

类图

  

设计方案

       这次的设计和之前的多线程电梯有相似之处,实现实时调度,面对一个请求,选择最优的车辆去执行请求,但是整体的复杂度感觉比多线程电梯高一些。输入线程将输入放入请求队列中,当请求队列不为空时,调度器遍历请求队列,为每一个请求寻找发送讯息的出租车队列,其中每一个请求控制在3秒的窗口期,当抢单窗口关闭时,就确定了该请求的最后出租车队列,然后再根据挑选出租车的原则选出最终执行请求的出租车,在这期间,计算线程一直在计算每一个请求的最短路径,并将最短路径保存在相应请求的Point容器属性中,出租车在启程是必须确保该请求的最短路径已经得出,其中对于最短路径的计算需要保证互斥,因为函数中有一个距离数组是共享的。这样执行效率是很低的,因为计算最短路径比较费时,调度也不够灵活,不能够将每一个请求分离开。想过为每一个请求建立一个线程,但又担心自己维护不好,出了奇奇怪怪的错误,就没这样实现,后面会去尝试这样做。

度量

  

  

  

度量分析

  随机化出租车运行路线函数,寻找最短路径函数,以及调度器中的寻找合适出租车函数,这三个函数复杂度确实挺高的,感觉稍微写个两层循环,以及一些判断条件语句圈复杂度就会爆掉,但是要是将一个功能函数再进行拆分,有会感觉这样太过零散,调用的深度又会增加。在代码的质量上还需要进行不断的深究。

Bug分析

       这次作业我没有交,因为没有实现功能,自己在设计和实现的连接方面还十分欠缺,总写出bug连连的代码,准确的说是写出的代码和自己心里想的完全是两个东西,也许是coding的太少,由于直接无效,所以并未进入互测阶段,也没有测同学的程序,继续努力吧。

心得体会

  三次多线程,可以说是做的一次比一次差了,是心态变了,还是真的作业难度增加了,也许都有吧。但并不是没有收获,最起码自己还是去设计了,学习了多线程的相关知识,去按照设计原则编写了自己的代码,虽然实现的效果很差。反应比较慢,逻辑能力欠缺,思维也不够缜密,在实现逻辑功能的时候容易出现bug(感觉设计的时候还是不够细致),并且完成代码后的调试过程比较慢,但是时间又是有限的,所以结果并不如人意。我觉得自己在实现这些工程的时候确实是有困难的,不想只是为了不无效而交上一份质量非常差的代码,这也是我第七次不交作业的原因,反应慢就需要比别人花费更多的时间去学习,补给站也定是有它的意义所在,但能够正常避免不去补给站,就尽量不去,无论在哪,目标只是想老老实实完成这门课的要求——2000行高质量的OO程序,希望自己可以做到。

 

posted @ 2018-05-02 14:06 N.S.A 阅读(...) 评论(...) 编辑 收藏