(1)从多线程的协同和同步控制方面,分析和总结自己三次作业来的设计策略及其变化. 第五次作业 第五次作业是对多线程的初步探索,所以对于多线程的基本书写机制的认识比较多.本次作业难点在于了解多线程的运作机制,努力构建线程安全的操作方式,合理构造电梯之间.电梯与请求之间的协作关系.值得注意的是电梯.乘客在问题域中具有并发行为: (1)电梯之间“竞争”响应请求:也即电梯共用一个请求队列,电梯之间对请求的处理不得重复.也不得有遗漏,这对于线程安全的要求是很高的 (2)乘客之间“竞争”使用电梯:满足捎带策…

I used to be enamored of object-oriented programming. I'm now finding myself leaning toward believing that it is a plot designed to destroy joy. Eric Allman 一.基于度量来分析程序结构 总体: 第一次作业:在两个类中处理了所有多项式的求导,一个主函数控制输入并且处理字符串,格式不正确时报错:另外一个处理多项式并且求导. 第二次作业:在第一次作…

概述 和前三次作业相比,这几次作业最大的不同是难度的飞跃.遗憾的是在这难度的变化面前,我自己却没有做好充分的准备,错误的低估了作业难度导致给自己带来了很多不必要麻烦和损失.接下来我将对它们进行说明(度量图工具出了故障一直无法生成请原谅). 设计简介 第五次作业 这是oo课程第一次多线程作业,我自己也体会到了它的难度.我的设计思路是首先够早一个调度器类(以上类图的scheduler类),负责管理各种实时输入的指令,然后是有三部电梯在各自独立的运行着,每当有新的指令输入时,首先判断是否是同质指令,然…

概述 经历了三次oo作业的洗礼,让我对java语言的强大以及面向对象编程有了初步的理解(当然,我是小白).本文接下来就将对自己这三次作业的代码进行分析以及分享自己的心路历程. 基础知识点考核 针对前三次作业,我列出了这其中涉及到的主要的知识点: java基础语法 java正则表达式(注意不要爆栈) 对java封装.继承.多态.接口的理解 程序的构思能力 当然,还有最重要的还是阅读和理解指导书的能力,能够在较短的时间内准确无误的理解指导书的意图也是必需的能力之一. 程序结构分析 作业一:多项式计算…

oo第一次博客 以前从未真正的写过Java代码,接触Java也只是寒假的时候简单的看了看语法,不懂该如何面向对象,但没事,心里不惧,想着什么都是可以学的(直到真正开始写工程的时候,才发现自己还是太天真了),就这样开始了OO学习这条不归路. 一.三次作业的实现过程分析 第一次作业 第一次作业是多项式加减运算,首先我用c语言写了一遍,基本熟悉题目的具体要求,当用Java去写时,我遇到了下面一系列的问题(具有难度等级): 1. 该如何划分类,如何面向对象编程: 2.正则表达式是什么: 3.该如何用Ja…

前言 在经过了三次艰辛的oo作业后,oo课程的第一单元告一段落,这一单元,我作为一个oo小白,开始了解oo的编程思想,也有了自己的一点心得体会.把笔粗成字,不当之处,还请各位大佬多多指教. 一.分析程序结构 第一次作业: 在第一次作业中,由于刚刚开始接触oo的思想,我还不是很了解面向对象的编程方法,还是按照c语言的思路,将deriviation作为main函数,在deriviation中调用number类,完成运算. 具体的操作思路,则是使用正则表达式构造出因子与项,通过正则式匹配来得到每一个项…

1.总结本单元两次作业的架构设计 在我动手开始总结我的设计之前,我看了其他同学已经提交在班级群里的博客,不禁汗颜,我是真的偷懒.其他同学大多使用了新建一个类,用以储存每一个UMLelemet元素的具体信息(当然这个类的形式可能是结构.map等等,但核心思路大体一致).在设计这个类的时候,大多数同学都遇到了困难,耗费了大量的时间精力. 下面我来讲一下,我的第一次作业的架构设计: 最开始,我查看方法描述,考虑如何实现方法的时候,惊喜的发现,UMLelemet数据类型的对象是可以实行操作的!这样一来,…

大作业NABC分析结果 这次的大作业计划制作一款关于七巧板的游戏软件.关于编写的APP的NABC需求分析: N:需求 ,本款软件主要面向一些在校的大学生,他们在校空闲时间比较多,而且热衷于一些益智类游戏来锻炼自己思维的灵活性 A:方法 ,游戏主要包括两个板块,其一,是采用常规的闯关模式;另一方面,是采用论坛交流的方式,游戏用户,可以上传任何图片,供其他游戏者拼出图片的图形 B:给用户带来的利益或好处是界面简单容易操作,满足了大学生锻炼思维的需求,同时为他们提供了迎接挑战的机会,可以获得成功的成就…

测试与正确性论证 测试是通过构造一系列测试数据,通过对比程序的实际运行结果和预期输出结果来判断程序是否有bug的一种手段.同时,在测试的时候是默认看不到程序的具体实现的,即进行黑盒测试,例如每次OO作业的互测阶段.测试的具体方法是将输入进行划分,通过构造一个错误分支树,然后每个分支构造一个或多个测试样例来对程序进行测试.其手段简单,易于实现,通常情况下可以覆盖大多数情况.但也可以看到通过测试的话是需要大量的测试数据的,如果在输入很麻烦的情况下,需要花费大量的时间.同时,就算所有的测试输入都是正确…

OO课程目前已经进行了三次的作业,容我在本文中做一点微小的工作. 第一次作业 第一次作业由于难度不大,所以笔者程序实际上写的也比较随意一些.(点击就送指导书~) 类图 程序的大致结构如下: 代码分析 可以看出,整体的功能还是相对零散的,耦合状况也基本还可以.然而类似Main.main.Polynomial.Polynomial两个函数的复杂度仍有点高.笔者后来查阅了阿里Java开发规范手册,发现两个问题: 单个方法的长度不宜过长,入口点方法(Main.main)也是一样 不宜在构造函数中携带过多…