第二单元博客作业 第五次作业 UML类图: 架构思路： 本次作业只有固定的五台纵向电梯，处理的请求之间相互独立，故处理起来较为简单。线程的设计整体基于生产者消费者模式，输入通过一个线程暂存到buffer请求队列中，五台电梯各开一个线程（在主线程中就可以设置好），模拟电梯的自主运行，同时分别
Unit 2总结 一、第一次作业 本次作业采用生产者-消费者的架构，整个电梯系统主要由总调度器（Scheduled）、输入线程（InputThread）、电梯线程类（Elevator）、等待队列（PassengerQueue）构成。大致的实现过程包含以下两级： 1、InputThread——waitQueue——Schedule 这一级的功能为通过输入线程输
BUAA OO 第二单元总结 同步块与锁分析 第五次作业中,我设计了一个线程安全的类OrderQueue，在这个类中，存在请求队列与候乘表，数据相关的类，通过分别加锁保证了请求队列和候乘表的线程安全与并行性能。而因为这个封装好的类，在外部不需要考虑线程安全问题，只需要使用OrderQueue就行，保证了
目录oo第二单元总结PART 1 同步块构造与选择PART 2 调度器设计PART 3 三次作业架构分析PART 4 自我分析bug策略PART 5 感想与体会 oo第二单元总结 PART 1 同步块构造与选择 本单元我们进入了多线程的世界,最重要的一个概念的就是同步锁,本单元作业均选取了synchronized锁,最开
OO第二单元总结 一、程序设计架构 总体架构 三次作业总体架构保持一致，在初始架构的基础上进行增量的迭代开发。 第一次作业 需求：模拟多线程实时电梯系统，每座固定一部纵向电梯，处理同楼座移动请求。 代码框架： 本架构采用生产者-消费者设计模式，托盘为各楼座等待队列，为每座定义了
第一次作业 乘客的请求信息：起点层和终点层不同，起点座和终点座相同。如1-FROM-A-1-TO-A-2 思路：采用LOOK策略。若同方向上没有请求且电梯里的乘客的目的地都在反方向，则转换电梯运行方向。（捎带前往目的地与电梯运行方向相同的乘客） UML类图 自己程序的bug 输出时间戳没递增 第二次作
第二单元总结 一、同步设计 三次作业中均只使用了synchronized修饰词来进行线程的同步，并且主要针对读写冲突进行保护。在三次作业中均使用OutputQueue类对输出信息进行封装，保证其线程安全。对于使用最多的共享类RequestQueue，其读写方法getOneRequest、addRequest、removeReques
第二单元总结 第五次作业 代码架构:生产者模型 单独一个线程InputHandler用来接收输入数据. 设立共用调度器Controller用来作为缓冲区对数据进行操作. 电梯elevator作为消费者模型用来向调度器发出指令处理数据. 调度算法:半优化ALS算法 即不仅携带与主请求目的地同方向的
OO第二单元总结 同步块与锁 多线程编程目的是为了加快程序运行速度，线程之间会共享资源，由此自然而然会产生类似于计组C流水线PU中读写不一致的问题，故必须要正确地加锁。 通过阅读训练教程和相关资料，了解到了原子操作的概念以及各种加锁的方法。虽然有更高级的条件锁以及读写锁等
OO第二单元总结 摘要 第一次作业：基本目标是模拟多线程实时电梯系统，模拟多部同型号电梯的运行，熟悉线程的创建、运行等基本操作，熟悉多线程的设计方法； 第二次作业：在第一次作业的基础上，掌握线程安全知识并解决线程安全问题，同时在架构上围绕线程之间的协同设计层次架构，模拟一个多线
OO 第二单元总结 一、同步块的设置和锁的选择 第五次作业 在第五次作业中，我编写了一个RequestQueue 类。这个类作为调度器和电梯线程之间的桥梁：调度器Scheduler 可以向这个类中传入请求(用Req类表示，下面相同），而电梯线程类也可以从每个线程自身的请求队列中读取请求并进行处理。 由
OO_Unit2_单元总结 Part0 综述 本单元三次电梯作业依然是在逐次迭代的基础上进行开发的。其中第一次作业要求我们实现一个每座只有一个纵向电梯，无新增加电梯的请求并且乘客的请求仅限于同楼座不同楼层的电梯系统。第二次作业相较于第一次作业添加了横向电梯的概念，并且可以通过请求
考虑到三次作业的迭代性，我将详细的文件结构和度量分析都放在了task3的部分里，前两次就简单略过了。 task1 初识多线程时的个人思考 线程涉及 获取输入的线程：new Thread(new MyInput(sceduler)) 调度器线程：new Thread(scheduler) 每个电梯控制器的线程：new Thread(ec) 在开关门时，主
OO第二单元总结 第一次作业 题目要求 A、B、C、D、E五栋楼均有10层，每栋内有一座纵向电梯，输入为同一楼座不同楼层的请求。需要模拟电梯的运行，并输出开门、关门、乘客进出信息。 设计思路 参考了实验的思路，建立输入线程、控制器线程、电梯线程，建立请求队列类。输入线程将输入的请求
OO第二单元总结 架构设计 三次作业中我逐步形成了如下的架构设计： 运行策略 电梯运行策略为ALS策略，即确定主请求后再考虑捎带请求。 RequestQueue的子类中把请求分为已分配的请求和未分配的请求。当电梯发出分配请求时，会根据电梯当前状态（运动方向、所在楼层、所在楼座）以及等待
OO unit2 需求迭代 第一次作业 输入：只有乘客的搭乘请求，搭乘请求为纵向 一共有五台纵向电梯，分别对应五个座ABCDE 第二次作业 输入：乘客的搭乘请求，搭乘请求为纵向或者横向；电梯的增加请求 初始有五台纵向电梯 第三次作业 输入：乘客的搭乘请求，搭乘请求为纵向或者横向或者
BUAA_OO_第二单元总结 第二单元主要实现电梯的调度问题。主要为了实现单部电梯、多部电梯、横纵向电梯的调度。 第一次作业 作业要求 第一次作业要求完成纵向电梯第调度问题。五个楼座各配置一部具有一至十层移动能力的电梯。电梯具有固定的移动速度、开关门速度和承载量
1、单元/集成测试： 完成单元/集成测试且单元/集成测试阶段发现的缺陷全部关闭 2、交付文档： 业务需求及变更相关文档、非功能性需求说明书、系统设计说明书、集成测试报告等。 3、文档要求内容： （1）功能需求清晰（输入、输出、业务规划有细化描述）； （2）非功能需求清晰（业务量、响应时间、
OO第二单元总结 作业总结 第五次作业 作业简介 这次作业是编写一个简单的多线程实时电梯系统，实现模拟五部电梯接送乘客的功能。 类图与协作图 类图如下： 协作图如下： 各个类含义如下： Main：主类Person：乘客类/请求类AllTable：全局Table（后来发现其实和控制器类似）Table：请求队列Request：
第二单元总结 目录第二单元总结1. 作业分析2. 架构设计2.1 请求拆分的流水线架构2.2 电梯类与控制器类的协作2.3 面向可扩展性的设计3. 线程安全与线程协同3.1 线程安全3.2 线程协同4. 调度器4.1 纵向电梯调度方案4.2 横向电梯调度方案4.3 请求拆分策略5. bug分析5.1 锁占用过多5.
同步块的设置 本单元的基本架构由以下三个主要部分组成： Inputhander：用来接收、分类输入，是线程。 Controller：用来处理输入、处理结束、是共享对象。 Elevator、Conveyer：电梯本身，用来接送乘客，是线程。 出于输出线程安全的考虑，再外加一个Outputer的单例对象，用于处理所有的输出。 因
综述 本单元的任务为模拟多线程实时电梯系统，主要考察多线程运行和交互的实现。在这三次作业的迭代中，第一次作业只涉及多部电梯的运行和电梯与调度器的竞争；第二次作业允许同层或同座多电梯运行，由于采用自由竞争策略，涉及到多部电梯竞争同一等待队列；第三次作业增加换乘策略，增加电
一、同步块的设置 在第二单元的作业中，我只使用了同步块的设置，没有使用读写锁，因此仅就同步块这一方面来介绍我三次作业的设计。从第一次作业初上手多线程，对于synchronized懵懵懂懂、看wait/notify晕头转向，到第三次作业已经摸清了这些关键字、内置方法的机理，能够肉眼分析出轮询的bug
第二单元博客总结 第五次作业UML类图和时序图如下： 由于第五次作业整体比较简单，该次作业并无过多迭代性考虑，采用的是标准的生产者消费者模式，INPUT线程不断读入新的数据发送给调度器，调度器把符合对应楼座的请求发送给对应的电梯，剩下的交给电梯自己不断处理。
一、整体思路总结 要求分析 本单元的三次作业从简单到复杂，最终实现了一个具有横向和纵向两种电梯，具有换乘功能和动态增加电梯的电梯调度设计。 在第一次作业中，只有简单的纵向电梯，并且不支持动态增加电梯，最需要注意的是搭建好一个架构，并且注意线程安全问题。 第二次作业中
