zoukankan      html  css  js  c++  java
  • 结队编程(电梯调度问题)

    结队编程报告

    小组成员:11061175  黄宇冰

                  11061170  罗洪运

    关于我的队友:

                  虽然已经大三了吧,但是这的确是我与他的第一次接触,当我看到结队结果的时候我的第一反应是这个人是谁。听起来一定感觉我们这组完蛋了,但我很庆幸,我的这位队友很好相处也很给力。合作期间没有争执,我感觉还是很默契的><。从代码的阅读理解、到代码优化两个人都分工明确。

    关于我们的分工:

                   代码理解:黄宇冰、罗洪运

                   代码初步编程:黄宇冰

                   算法描述:罗洪运

                   代码优化:罗洪运

                   代码测试:罗洪运

                   UML图:黄宇冰

                   整理汇总:黄宇冰、罗洪运

    关于结队编程:

                   优点

                   我觉得结对编程之所以有效无非是基于一个常识,那就是两个人的共同盲点并不多。自己在代码上缺乏一定的整体性,而在这点罗洪运对于我是一个互补。除此之外,结对编程的效率绝对是非常高的,或者说你们队友在一边熬夜写代码,你一定就不好意思去看美剧了。两个人互相监督,互相掌握着进度是一种督促。两个人的交流十分重要

                  缺点

                  相反的,结对编程也有一个缺点,就是两个人的时间不能完全统一,我们只能制定一个大致的计划,然后按照计划去尽可能完成。

     队友优缺点:

    黄宇冰:

    优点

    时间观念强,有规划,踏实努力

    不足:

    罗洪运:

    优点 做事认真,执着,能够坚持

    不足

    做事慢,时间观念不强

    Information Hiding&& interface design&& loose coupling

                 

                  信息隐藏:

                  它是指一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说,是不能访问的(隐藏的),其实也就是强调了软件开发过程中的封装性。信息隐藏实际上还有一个很大的用处,我们在 软件中隐藏了一些因素,那么在将来由于这些因素变化而需修改软件时,只需修改这些个别的模块,其它模块不受影响。总的来说信息隐蔽技术不仅提高了软件的可维护性,而且也避免了错误的蔓延,改善了软件的可靠性。

                 接口设计

                 四大原则:

                           1。简单原则

                           2。封闭原则

                           3。完整性原则

                           4。可置换原则

                 松耦合

                所谓“耦合”,指将两个元素像链子一样连接在一起。在软件领域,“耦合”一般指软件组件之间的依赖程度。松耦合系统通常是基于消息的系统,此时客户端远程服务并不知道对方是如何实现的。客户端和服务之间的通讯由消息的架构支配。只要消息符合协商的架构,则客户端或服务的实现就可以根据需要进行更改,而不必担心会破坏对方。松耦合通讯机制提供了紧耦合机制所没有的许多优点,并且它们有助于降低客户端远程服务之间的依赖性。但是,紧耦合性通常可以提供性能好处,便于在客户端和服务之间进行更为紧密的集成(这在存在安全性和事务处理要求时,可能是必需的)。

                  关于代码的理解:

                 Scheduler 功能:接受并且缓存请求,分配给每个电梯的Task。Task 功能:收到Scheduler指定的任务,指挥电梯运动。    

              Task 逻辑详解:Task 可以理解为电梯的当前任务,其有三个重要成员变量,State(任务状态),TaskDirection(任务方向),TaskFloor(任务楼层)。

             

              State有三个状态

    Idle(空闲):即电梯当前没有任何任务,停止在某一楼层状态。

    Pick(接人):即电梯在空闲时,收到一个Scheduler指定来的Direction请求,即有乘客要求上电梯时,电梯驶向乘客方向去接人的状态。

    Drop(下人):即电梯在任何时候收到一个Scheduler指定来的Destination请求后,电梯按着TaskDirection方向行驶,并且在需要停靠的楼层开门使人上下的状态。

    电梯初始状态一般是 Idle,会顺序地从 Idle -- 收到请求 --> Pick --到达呼叫楼层--> Drop --按着TaskDirection方向走到最后一站--> Idle 经历这些状态。

              Scheduler 循环逻辑过程:

    收到请求:按照请求类型(Destination or Direction)缓存。 循环过程:首要分配Destination类型请求,次要分配Direction类型请求,之后更新电梯的超重状态。

     

    分配Destination请求: 记 该请求的电梯的Task 为 tsk。 如果该tsk的TaskDirection方向与前往 destination 的方向相同,则成功分配;否则不成功 分配成功,则移除该请求;否则,保留在请求列表。

     

    分配Direction请求: 遍历所有电梯,优先寻找一台“顺路”电梯,“顺路”满足下面条件中任一 1、状态为Idle && 未超重 && 正好停在该楼层 2、状态为Pick && 未超重 && 任务方向和请求方向一样 && 路过该楼层或者正在行驶的方向和任务方向相反 3、状态为Drop && 未超重 && 任务方向和请求方向一样 && 路过该楼层 如果找到则马上返回分配成功,否则次要搜索一台停在任意楼层的空闲电梯。 分配成功,则移除该请求;否则,保留在请求列表。

                  我们的算法

      因为考虑到0、1层请求较多,而且从0、1层能够最大的将请求覆盖,所以每次尽量让电梯接往下的请求。

    1、如果电梯正在运行,对外部请求进行考虑,如果外部请求所在楼层在外部电梯和当前目标楼层之间且方向相同,同时为避免乘客上了电梯由于超重又下电梯的情况,对超重进行预测,如果电梯剩余负载小于乘客平均体重,则接收此请求,更新目的楼层;否则不接收外部请求。

    2、如果电梯当前状态为静止,则只用考虑外部请求,根据电梯的当前位置,将请求分为4中,下下、下上、上上、上下(前一个“上”、“下”表示请求楼层相对于电梯位置,后一个“下”、“上”表示请求要去的方向),并统计四个方向人数。按下下 、 下上、上上、上下优先级从高到低相应请求,但同时各个楼层、方向请求的数量也影响最终的调度:

    如果下下人数大于下下人数,才将电梯目的楼层定位下下请求中离电梯最近的请求;

    如果下上人数大于上下人数,才将电梯目的楼层定位到下上楼层

    否则按照下下、下上、上上、上下的顺序响应。

    (测试中下上和上下请求数的比较后不一定比不进行比较快,但是我认为在数据足够多的情况下,平均时间是有降低的,而且除了上述四个情况,如果考虑所有往下的请求和所以往上的请求,在之前算法的基础上再并进行相应的控制,是可以找到一个相对很优的调度算法)

     

     

                  关于类图:

                               

        

       队友博客地址:http://www.cnblogs.com/icehorn924/p/icehorn.html

     

  • 相关阅读:
    开始学习编写用于 Windows SideShow 设备的小工具【转】
    Windows Mobile 6.5 Developer Tool Kit 下载
    Microsoft Security Essentials 微软免费杀毒软件下载
    SQL Server 2008 空间数据存储摘抄(SRID 点 MultiPoint LineString MultiLineString 多边形 MultiPolygon GeometryCollection)
    Vista Sidebar Gadget (侧边栏小工具)开发教程 (2)
    Vista Sidebar Gadget (侧边栏小工具)开发教程 (4)
    负载测试、压力测试和性能测试的异同
    Windows Server 2008 Vista Sidebar Gadget (侧边栏小工具) 入门开发实例
    Silverlight Tools 安装失败 解决办法
    SQL Server 2008 空间数据库 空间索引概念及创建(取自帮助)
  • 原文地址:https://www.cnblogs.com/lhyun/p/3366752.html
Copyright © 2011-2022 走看看