一.三次作业总结 1. 说在前面 对于这次的这三次电梯作业,我采用了和几乎所有人都不同的架构:将每个人当作一个线程.这样做有一定的好处:它使得整个问题的建模更加自然,并且在后期人员调度变得复杂时,可以将调度器上纷繁的逻辑判断分布在不同的人身上,大大简化了代码逻辑.对于程序复杂度,将人作为某个容器中的PersonRequest时需要在电梯到达某一层时进行遍历,而将人作为线程池中的一个任务则是通过wait()和notify()机制实现了类似的线程遍历,对于此次最多40人的简单任务而言并不会在时间上损

目录 总 架构 controller model view 优化算法 Look 算法 多种算法取优 预测未来 多线程 第五次作业 第六次作业 第七次作业 代码静态分析 UML 类图 类复杂度 类总代码规模 属性个数 方法复杂度 方法个数 方法规模 控制分支数目 优缺点 优点 缺点 SOLID 原则 单一职责原则(SRP) 开放封闭原则(OCP) 里氏替换原则(LSP) 接口隔离原则(ISP) 依赖倒置原则(DIP) 多线程协作 UML 图 分析 线程间通信 并行任务的独立性 坑 多线程错误 Ma

目录 总 架构 Controller​ Model​ 输入处理 代码静态分析 行数 方法复杂度 UML​ 类图 优点 缺点 坑 输入 非法的空白字符 输入的简并处理 运算 浅拷贝 可变类型与不可变类型 输出 表达式因子的优化 互测策略 测试集测试 针对性测试 脚本测试 Creational Pattern 总 本博文是2019年北航面向对象(OO)课程第一单元作业(多项式求导)的总结.三次作业的要求大致如下: 第一次作业:简单幂函数的求导,如 \(1 + x^5 + 4 * x^3\) 第二次作

UML与解析架构 UML是什么 统一建模语言(英语:Unified Modeling Language,缩写 UML)是非专利的第三代建模和规约语言.UML是一种开放的方法,用于说明.可视化.构建和编写一个正在开发的.面向对象的.软件密集系统的制品的开放方法.UML展现了一系列最佳工程实践,这些最佳实践在对大规模,复杂系统进行建模方面,特别是在软件架构层次已经被验证有效.(百度百科) 作为一种统一的建模语言,UML具有完全的面向对象特性,UML使用类作为建模的主题对象,能够很好地涵盖面向对象设计

第一次作业 第一次进行面向对象的编程,不论是针对数据设计类还是对方法进行合适的归于不同类中,都不是很熟悉.所写出来的程序还是面向过程+有函数的类(虽然现在很大程度上感觉起来也是这样).索性作业难度并不算高,完成的也算马马虎虎.公测都通过了,但是互测的时候被发现了一处笔误,少写了一个0,导致6位的测试样例无法正常读入.并且由于我的检测输入的实现并不是通过正则表达式,而是通过简单粗暴的有限状态机,故而第一周并没有完整学习正则表达式.虽然有限状态机的设计并没有出错,但是没有尽早学习正则表达式也给我后面

第五次作业 这次作业是电梯系列作业的终极版,要求是使用多线程实现三部电梯的运行.这次作业的难点在于第一次运用多线程技术,对于线程中的行为并不了解,以及电梯功能的实现(如果之前作业采取的是扫描指令队列预先判断电梯行为,而电梯类仅用于实现状态跳转,那么就意味着这次作业要重新设计).多线程这部分,我在完成作业的时候了解的并不多,仅仅使用了thread.sleep()方法进行对于运行时间的模拟,以及在指令队列中疯狂添加synchronized修饰方法,而并不知道这样的深刻意义.而核心的电梯行为这部分,由

第五次作业 算法与实现 这次的电梯因为要使用系统时间进行模拟,所以又是推倒了之前的重写的.最后采用三个电梯线程,一个调度线程,一个输入线程的方式. 源码分析图示 类图 方法分析 类分析 由上图看,由于第一次写多线程,单一线程的复杂度过高,任务分配不够平均. BUG分析 这次被人测了一个ctrl+z导致的scanner的空指针错误,我对此印象深刻.之前一直没考虑到过读入时的判断问题.然后就是调度偶尔会产生不捎带的问题,与调度的算法不当有关. 第六次作业 算法与实现 这次作业主要的难点是第一次接触文

「BUAA OO Unit 1 HW1」面向测试小白的简易评测机 声明:本评测机所使用数据生成来自郭鸿宇同学,这对本评测机非常重要 目录 「BUAA OO Unit 1 HW1」面向测试小白的简易评测机 Part 0 前言 笔者的配置与环境 面向人群 定位 Part 1 准备工作 Part 2 获取java jar包 目的 过程 须知 Part 2 修改评测机参数 pipline.py gendata.py Part 3 评测机架构 Part 4 有待改进的地方 Part 5 附录:如何从0配置

「BUAA OO Unit 2 HW8」第二单元总结 目录 「BUAA OO Unit 2 HW8」第二单元总结 Part 0 前言 Part 1 第五次作业 1.1 作业要求 1.2 架构设计 1.3 协作图 1.4 调度分析 1.5 bug分析 自己bug 使用了run而不是start方法启动线程 别人bug 1.6 对象头.锁和同步 对象实例结构 锁和同步 参考资料 对象锁 方法锁形式 代码块形式 类锁 静态方法形式 代码块形式 参考资料 1.7 线程安全--封装安全输出类 每次调用加锁

OO第一次博客作业 一.三次作业的bug反省 1.自己发现别人的问题 (1)输入处理的问题,比如第一次作业,主要就是处理输入的字符串,然后有同学的正则表达式有问题,则对于一些错误输入就不能正确判断. (2)在求导求完之后的合并项的时候出问题,在第二次作业中我发现了两个同学都是在和并项的时候出了问题,导致两个指数相同的项没有成功合并,然后出现了一些奇奇怪怪的错误. (3)输入没有处理好,具体到项中各个参数读入的时候会出错,有一个同学x前输入一个空格就没法正确输出. 2.作业中自己被别人发现的bug

oo第八次作业 第五次作业分析: 1.度量图: 2.类图: 第五次作业由于是第一次接触多线程,所以导致自己的经验不足,因此最终也没有完成作业,到最后任然不能实现三部电梯的有效调度,所以导致了这次作业的无效 第六次作业: 1.度量图: 2.类图: 第六次作业,是完成对文件的监控操作.进过了上一次作业的失败,在这一周终于成功的完成了第七次的作业,但是存在很多的问题,尤其是对于目录的考虑不周到,而且自己写的测试线程由于时间太紧也没有完成.导致出现了很多的bug,错了两个公测,并且被找了6个bug,大多

前三次作业可以说是入门编程,随着课程的深入,这三次多线程作业使我们开始慢慢接触工程性的编程任务. 对比起1-3次作业,5-7次作业明显没有那么顺利了,之前在互测环节每次最多就一个BUG或者没有BUG,并且出现BUG时一般可以比较容易的发现BUG的类型以及造成BUG的原因,但是在这三次作业中,由于多线程的部分不确定性,很多问题难以在测试中准确发现,尤其是自己进行测试时,所以这三次作业互测环节被发现的BUG较前三次有所上升,然而乐观地说,互测中被发现的BUG越多在互测环节的收获也越大(当然这是抛开分

面向对象OO第5-7次作业总结 学习OO七周了,深切的感受到了这门课程的不友好.前三次作业能够算是勉强地通过了,但是从第五次作业开始就完全GG了.这三次作业,从多线程电梯开始,然后文件监控,然后到出租车,都没有写出来有效的作业.所以就不按照给定的基于度量来分析自己的程序结构了. 第五次作业 多线程电梯 这次作业是根据第三次作业改写而来的,自认为前两个电梯写的还不错,只是电梯捎带功能上少了几个判断的条件,以为这次能够加入多线程完美运行.但是实际写起来却并不如意,各个线程本身写出来了,但是在各个线程

oo第四单元作业总结暨课程总结 一.本单元作业架构设计 本单元需要构建一个UML解析器,通过对输入的UML类图/顺序图/状态图的相关信息进行解析以供查询,其中课程组已提供输入整体架构及输入解析部分,仅需补充查询指令相关实现.本单元的三次作业是彻底的增量开发,没有对先前的作业做任何改动,因此仅分析第三次作业的架构设计. 由于本单元作业数据量较小,性能要求较低,因此并没有采取按照元素的属性和归属进行建树或建图的方法,而仅暴力存储了每一元素的相关信息并在查询时不断遍历,架构较为简单,类图如下(仅选取自

OO前三次作业总结 基于度量分析程序结构 由于三次作业较多,决定分析内容.功能最为复杂的第三次作业. 上图为第三次作业的类图.我使用了一个抽象类Factor,写了五个因子继承Factor,然后又单独开了一个Term类,还有表达式类,其中Expression因子包含一个表达式类,其他就是常见的Main类,InputHandle类,求导和输出都在Main类中完成.个人认为本次的架构还可以,较为清晰,具有延展性,若是加入其他因子只需要继续继承Factor类,而在其他类中改动无需太多就可继续使用,而在递

「BUAA OO Pre」 Pre 2总结回顾概览 目录 「BUAA OO Pre」 Pre 2总结回顾概览 Part 0 前言 写作背景 定位 您可以在这里期望获得 您在这里无法期望获得 对读者前置知识的期望 Part 1 Pre 2 task 1 题目 描述 输入/输出格式 数据范围与操作限制 变量约束 操作约束 测评方法 输入样例 输出样例 提示 值得注意的点 Part 2 Pre 2 task 2 题目 基本要求 描述 输入/输出格式 数据范围与操作限制 变量约束 操作约束 测评方法 输

「BUAA OO Unit 4 HW16」第四单元总结与课程回顾 目录 「BUAA OO Unit 4 HW16」第四单元总结与课程回顾 Part 0 第四单元作业架构设计 架构设计概要 AppRunner官方包代码简析与架构设计初步 一.AppRunner工作逻辑和流程 1. 属性 1.1 interaction 1.2 status 2. 行为 2.1 run Step 1 输入与解析模型 Step 2 输入与指令获取 Step 3 输出 二.我们的工作 1. 解析和存储元素 1.1 输入顺

Deadline: 2016-10-26 23:59 作业内容 实验4-1 求1到20的阶乘的和,其中求阶乘用函数完成. 实验4-2 写一个判素数的函数,在主函数输入一个整数,输出其是否是素数的信息. 实验4-3 打印出1-100之间的全部素数(判素数由函数实现). 实验4-4 写两个函数,分别求两个数的最大公约数和最小公倍数,用主函数调用这两个函数,并输出结果,两个整数由键盘输入. 实验4-5 数组 score 存放 10 个学生成绩,编写一个函数求平均成绩.最高分.最低分. 第五次作业总结

第五次作业,主要学习和复习的是几种循环结构的使用. 在前一次的课堂上,同学们已经学习了分支语句的使用.分支语句和循环语句配合使用,就可以写出更多的,逻辑功能丰富的代码了. 逻辑功能的丰富,也意味着学习难度的加大,不过,要是同学们前面几次课都有认真学习,那么难度并不会很大. 这次作业,简单的总结如下: 什么时候用 hile 循环,什么时候用 do-while循环 在多数情况下,while循环和do-while循环都是可以互换的.唯一的差别就是do-while循环在进行判断之前会额外的执行一次循环.

C语言程序设计第五次作业--循环结构(1) (一)改错题 输出华氏摄氏温度转换表:输入两个整数lower和upper,输出一张华氏摄氏温度转换表,华氏温度的取值范围是{lower,upper},每次增加2℉.计算公式如下:++c = 5×(f-32)/9++. 其中,c表示摄氏温度,f表示华氏温度. 输入输出样例1: Enter lower:32 Enter upper:35 fahr celsius 32 0.0 34 1.1 输入输出样例2: Enter lower:40 Enter upp

oo 第一次博客作业 早在大一就听说了oo的各种传奇故事,大二下学期终于也开始了我的oo之旅. 基于度量来分析自己的程序结构 第一次作业 类图分析 耦合度分析 可以看出在第一次作业中,我的耦合度非常高,还停留在面向过程式的设计. 第二次作业 类图分析 耦合度分析 可以发现在第二回作业中虽然我有意识的拆分类,但组织结构仍然不好,耦合度仍然很高. 第三次作业 类图分析 耦合度分析 可以分析发现,这次的作业有了一些oo的样子,对input, output, terms有了各自的package,并且耦合