第一次作业
1. 设计策略
第一次作业,一共三个线程,主线程、输入线程和电梯线程,有一个共享对象--调度器(队列)。
调度的策略大多集中到了电梯里,调度器反而只剩下一个队列。
2. 基于度量的分析
类图:
方法复杂度:
如上所说,调度的策略大多集中到了电梯里,导致电梯的run方法复杂度大大提升。
类复杂度:
solid原则:
Single Responsibility Principle (单一功能原则): 基本满足,电梯、输入处理、调度队列的功能职责都只归属于一个类。
Open Close Principle(开闭原则): 不满足,扩展性较差,电梯的调度策略都在电梯里,上下楼的方法用的是累计,然后sleep(楼层数 * time),无法动态地检查每一楼层。
Liskov Substitution Principle(里氏替换原则): 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle(接口隔离原则): 满足。本次作业没有涉及到接口。
Dependency Inversion Principle(依赖反转原则): 满足。
3. 程序的Bug分析
第一次作业逻辑比较简单,所以在强测和互测中暂时还没有发现Bug。
4. 互测策略
由于本次作业比较简单,我在互测中同学的代码中没有发现线程安全相关的问题。在互测中主要靠读别人的代码,发现一些细节上的、功能相关的问题,比如顶层和底层的限制等。
第二次作业
1. 设计策略
第二次作业的要求是在第一次作业的基础上添加了地下三层和ALS可调度策略,要求我们不再一次只载一个人,而是做得更像我们生活中的电梯,更真实效率更高的电梯。
我的架构大部分沿用了前一次作业的设计,仍旧是四个类,三个线程--主线程、输入线程和电梯线程。其中输入线程和电梯线程共享一个对象--调度器队列。
其中调度器仍然只充当一个队列的角色,只负责存取乘客的信息,大部分的调度的策略都被我写在电梯类里。
而电梯的调度算法没有使用指导书推荐的算法,而是使用了一个电梯的经典算法--Scan算法。
2. 基于度量的分析
类图:
方法复杂度:
其中 Elevator.need() 是检查 ”是否还有继续在这个方向上运行的必要“,检查后若没有必要则掉头。
这两个方法耦合度较高。
类复杂度:
电梯类承载了太多调度的策略,导致复杂度较高。
solid原则:
Single Responsibility Principle (单一功能原则): 不满足。电梯类不仅承担了电梯运行的指责,还承担了调度的指责。
Open Close Principle(开闭原则): 不满足,扩展性仍然较差。电梯的调度策略都在电梯里,无法拓展到多电梯。
Liskov Substitution Principle(里氏替换原则): 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle(接口隔离原则): 满足。本次作业没有涉及到接口。
Dependency Inversion Principle(依赖反转原则): 基本满足。
3. 程序的Bug分析
本次作业中我的程序里没有发现功能上的Bug,但存在性能上的Bug导致实际运行时间过长。
我的调度策略是,在电梯为空时接第一个人,然后以第一个人的方向开始运行。这种调度方式会导致接完第一个人后,去接的那个方向上的以后的人都会被忽略。
如图样例,当第一个请求出现,电梯会先去接第一个遇到的请求,接了之后立马会把方向转化为他想去的方向,即接到第一个八楼的人会立马往下运行,而九楼及以上的人都接不上。如上的样例需要来回送九趟……
4. 互测策略
与上一次作业差不多,主要检查一些功能上的细节,捎带的功能检查等。
在讨论区看到了一个大佬的自动测试,替换掉官方的输入输出接口可以直接在输入中加入时间,实现自动定时输入。
第三次作业
1. 设计策略
第三次作业的难度对于前两次作业总是一个飞跃,增加了两部电梯,每部电梯的可停靠楼层、运行一层的时间和最大载客量都不同。三部电梯之间的差异就决定了这一次我只能重构。
这一次作业我的程序有五个线程,主线程、输入线程和三个电梯线程。三个电梯线程和输入线程共享一个调度器对象,输入线程负责将请求放进调度器,然后调度器根据请求的起始楼层,结合三部电梯的运行状态,将请求拆分或者直接放入某部电梯的等待队列。
而在拆分请求的执行先后顺序控制上,我建立了三个个数组,分别保存了三部电梯等待人员ID和是否经过拆分,若经过拆分则不能接,然后每次送达都检查一次这个数组,更新数组。
2. 基于度量的分析
类图:
整体构造和上次一样。
方法复杂度:
方法复杂度显示出 Elevator.need() (检查是否有必要继续向现在的方向运行)和 Elevator.run() 耦合度较高,判定结构过于复杂。同时 RequestManager.addRequest(PersonRequest) 方法(尝试拆分请求并分发到电梯的等待队列)复杂度过高。
类复杂度:
由图可知,Elevator 类和 RequestManager 类之间耦合过高。
solid原则:
Single Responsibility Principle (单一功能原则): 勉强满足。电梯、调度器、输入都只承担了自己应该承担的职责,但电梯、调度器的职责还是太过复杂。
Open Close Principle(开闭原则): 满足,具有扩展性。
Liskov Substitution Principle(里氏替换原则): 满足。本次作业除 extends Thread 外没有涉及到继承关系。
Interface Segregation Principle(接口隔离原则): 满足。本次作业没有涉及到接口。
Dependency Inversion Principle(依赖反转原则): 基本满足。
3. 程序 Bug 分析
与上一次作业一样,功能上没有bug,而因为性能太差产生了 bug,特别的是这一次的bug与上次是同一个bug,错在同三行代码,名副其实的祖传 bug。
4. 互测策略
在这一次作业的互测流程中,我主要运用了大佬分享的自动测试包,对我的和互测屋里的同学的代码进行测试,结果比对,命中率不算高(可能由于评测机不太稳定?)。
心得与体会
第二单元的作业感觉除了关于处理线程安全和多线程调试的问题,总体比第一单元更好写,更不容易出错。
而要处理好线程安全,我们可以直接使用线程安全的数据结构,也可以在设计上处理好wait, notify 和锁的关系避免出现bug。
设计原则上,我们需要在设计阶段就考虑单一功能原则和开闭原则,避免写出不可拓展的代码,或者耦合度过高的代码。
OO第二次博客作业--第二单元总结的更多相关文章
-
OO第二次博客作业—17373247
OO第二次博客作业 零.写在前面 OO第二单元宣告结束,在这个单元里自己算是真正对面向对象编程产生了比较深刻的理解,也认识到了一个合理的架构为编程带来的极大的便利. (挂三次评测分数 看出得分接近等差 ...
-
OO第二次博客作业——电梯调度
OO第二次博客作业——电梯调度 前言 最近三周,OO课程进入多线程学习阶段,主要通过三次电梯调度作业来学习.从单部电梯的傻瓜式调度到有性能要求的调度到多部电梯的调度,难度逐渐提升,对同学们的要求逐渐变 ...
-
Java第二次博客作业
Java第二次博客作业 时间过的很快啊,在不知不觉中这门课程的学习也就快要过去一半了,现在就来总结一下在这个第二个月的学习当中存在的问题以及得到的心得. 1.前言 第四次题目集和第五次题目集给我的感觉 ...
-
OO第二次博客作业(第二单元总结)
在我开始写这次博客作业的时候,窗外响起了希望之花,由此联想到乘坐自己写的电梯FROM-3-TO--1下楼洗澡,然后······ 开个玩笑,这么辣鸡的电梯肯定不会投入实际使用的,何况只是一次作业.还是从 ...
-
第二周博客作业 <;西北师范大学| 周安伟>;
一,本周助教小结 逐步开始适应助教工作,对学生发布的博客进行点评,查看学生对软件工程前期的准备情况. 二,助教本人博客 https://home.cnblogs.com/u/zaw-315/ 三,学生 ...
-
C语言第二次博客作业---分支结构
一,PTA实验作业 题目1.计算分段函数 本题目要求计算下列分段函数f(x)的值: 1.实验代码 double x,result; scanf("%lf",&x); if( ...
-
C语言第二次博客作业——分支结构
一.PTA实验作业 题目1:计算分段函数 1.实验代码 #include<stdio.h> #include<math.h> int main(void) { double x ...
-
第二周博客作业<;西北师范大学|李晓婷>;
1.助教博客链接:https://home.cnblogs.com/u/lxt-/ 2.点评作业内容: https://www.cnblogs.com/dxd123/p/10494907.html#4 ...
-
[2017BUAA软工]第二次博客作业:代码复审
〇.comment链接 https://github.com/hanayashiki/Sudoku/issues/1 一.代码复审 1.概要部分 (1)代码能符合需求和规格说明么? 经测试,对于合法输 ...
随机推荐
-
activiti自定义流程之自定义表单(二):创建表单
注:环境配置:activiti自定义流程之自定义表单(一):环境配置 在上一节自定义表单环境搭建好以后,我就正式开始尝试自己创建表单,在后台的处理就比较常规,主要是针对ueditor插件的功能在前端进 ...
-
openstack配置注意事项(主要是网络相关)
vlan协议应该配置为802.1q,另一个容易混淆的为ISL,配置命令为 switchport trunk encapsulation dot1q /islswitchport mode trunk ...
-
fedora下一些问题的解决方案汇总
解决fedora下一些使用问题 一 解决fedora下无法使用Fn+功能键来调整亮度的问题 在fedora下,背光的配置参数在/sys/class/backlight文件夹下,根据不同的显卡,有不同的 ...
-
FT View SE联合Studio 5000仿真
前言:一个实际的自动化项目,都是综合性的,不仅需要PLC进行逻辑.顺序.运动等控制,还需要在上位机进行监视和操作.当没有物理PLC时,上位机软件就无法连接到实际的变量数据,开发出来的界面和功能无法验 ...
-
设计模式之 SOA面向服务的体系
SOA英文直译是,面向服务的体系结构. SOA是一种设计方法,其中包含多个服务,而服务之间通过配合最终会提供一系列功能.一个服务通常以独立的形式存在于操作系统进程中. 想要看到更多玮哥的学习笔记.考试 ...
-
shell逻辑运算总结, 包括[[]]与[]的区别,&;&;与-a的区别,||与-o的区别
1. 关于文件和目录 -f 判断某普通文件是否存在 -d 判断某目录是否存在 -b 判断某文件是否块设备 -c 判断某文件是否字符设备 -S 判断某文件是否socket(待修正) -L 判 ...
-
List<;T>;集合的Sort自定义排序用法简单解析
List<T>集合的Sort自定义排序用法简单解析: 如下:一系列无序数字,如果想要他们倒序排列,则使用如下代码: 那么如何理解这段代码呢? (x,y)表示相邻的两个对象,如果满足条件:x ...
-
数据库之MySQL ERROR 1698 (28000) 错误:Access denied for user &#39;root&#39;@&#39;localhost&#39;"; error【摘抄】
声明:全文均摘抄于MySQL ERROR 1698 (28000) 错误 //错误起源: ~$ mysql -u root -p Enter password: ERROR 1698 (28000): ...
-
Koa 框架 的错误处理
默认情况下Koa会将所有错误信息输出到 stderr,除非 NODE_ENV 是 "test".为了实现自定义错误处理逻辑(比如 centralized logging),您可以添 ...
-
STA分析(二) multi_cycle and false
multicycle path:当FF之间的组合逻辑path propagate delay大于一个时钟cycle时,这条combinational path能被称为multicycle path. ...