北航 2012 秋季 现代软件工程 两人结对 作业要求
Pair Project: Elevator Scheduler [电梯调度算法的实现和测试]
Design and implement an Elevator Scheduler to aim for both correctness and performance, in managed code.
Skills to learn and practice:
a) Peer to peer collaboration
b) Requirement Analysis
c) Design by contract, Interface design and comprehension
d) Test Driven Development, Unit Test
e) Algorithm design
f) Implementation
1. Background
Imagine we’re building a tall office building, it has the following configuration about elevators:
Building has 21 floors, 4 elevators, many passengers use these elevators everyday (passenger weight: average 70kg. max 120kg, min 45kg).
Other constant data: Elevator speed, door open/close time, passenger time for going in/out of the elevator. We can make reasonable assumptions about these.
The building has 21 floors, from floor 0, 1, ... to 20. Floor 0 is the underground parking level, floor 1 is the lobby level. Most people come in/out the building via these 2 floors.
|
Elevator name |
Service floor list |
Passenger limit |
Weight limit |
|
1 |
All floors |
10 |
800 kg |
|
2 |
All floors |
10 |
800 kg |
|
3 |
All floors |
20 |
1600 kg |
|
4 |
All floors |
20 |
2000 kg |
2. Requirement to Student pairs
A framework with a naive algorithm is prepared and shared to students. The core task for students is to design and implement the scheduling algorithm. Students need to write their own scheduler class (implements the IScheduler interface)，Update the SchedulerFactory.CreateScheduler method so the test framework can instantiate your class.
TA will come up with a consistent testing model to test your program according to the “rush hour” scenario (see below), and record the total travel time of each passengers.
Total Travel Time = the time delta between the passenger appears in front of the elevator, and the time she gets off the elevator at this designated floor.
You (student pair) have:
1) A set of API
2) A naive solution (BUS program)
3) A set of test cases to run
2.3 Explanation of BUS program:
We can have a naive algorithm called “BUS”. BUS algorithm treats an elevator as a bus, it goes from bottom to top, stops at every floor, opens its door, to let people in and out (if any), then closes the door and moves on. After it reaches the top floor, it will go down and stop at each floor again. This algorithm can serve all requests, but it’s apparently not the fastest algorithm.
Your code is required to be managed code (C#, managed C++, etc).
It has to generate 0 (zero) VS Code Analysis warnings and errors.
It has to be correct
It has to be fast
Score guideline: TA will evaluate the “average total travel time” for all passengers in the same test case, the lower, the better. If your performance is slower than “bus” solution, you get 0 points; if your program can’t deliver any passenger to the correct destination, you get 0 points.
One hint about elevator scheduling: When total weight is within 45 kg of the max limit, or the number of passengers is already at maximum, the elevator doesn’t need to stop for more external requests.
The elevator scheduler program doesn’t know how many passengers are waiting on each floor, it doesn’t know how many passengers will show up either. This is the same with the real world situation.
3. Testing
TA will simulate a “rush hour” (上下班高峰时刻) test. The “rush hour” test is to simulate the come-to-work and leave-work scenario in a business building, which has the following 2 parts (they can be run next to each other).
1) Simple test. 20 passengers
20 people going thru random floors within 5 minutes.
2) Come-to-work. 1000 total passengers
a) 80% of them goes from floor 0 and 1 to all other floors, the destination is distributed evenly. The time each passenger arrives at the elevator can be emulated as a normal distribution.
b) 20% of them are going between any 2 floors of [2, 20], Very few people travel between 2 adjacent floors (e.g. from floor 5 to 4). Other than this, the distribution is also even.
3) Leave-work. 1000 total passengers
a) 90% of them go from other floors to floor1 or floor0.
b) 10% of them travel between floors [2, 20], again, Very few people travel between 2 adjacent floors.
4. 作业步骤
|
作业 |
博客要求 (写1个博客, 附加题的解法写另一个博客) 博客注明结对编程人员的名字/或学号后3位. |
|
看教科书和其它参考书, 网站中关于结对编程的章节。例如: |
照至少一张照片, 展现两人在一起合作编程的情况。 说明结对编程的优点和缺点。 结对的每一个人的优点和缺点在哪里 (要列出至少三个优点和一个缺点)。 |
|
看教科书和其它资料中关于 Information Hiding, interface design, loose coupling 的章节
|
说明怎样利用这些好的设计方法。 |
|
看 Design by Contract, Code Contract 的内容: |
描述这些做法的优缺点, 说明你是如何把它们融入你的作业中的。 |
|
看教科书中，网上有关 unit test 的内容 http://www.cnblogs.com/xinz/archive/2011/11/20/2255830.html
|
通过截屏显示你是如何用VS 的 unit test 来保证你写的类的质量的。显示unit test 对你的写的类 (class) 的覆盖率 |
|
阅读有关 UML 的内容 |
画出UML 图显示各个实体之间的关系 (画一个图即可) |
|
实现你的算法 |
说明你的算法的关键 （不必列出源代码）, 以及独到之处。
把你的代码签入TFS (问老师要权限及小组的路径)
|
|
[附加题]改进电梯调度的interface 设计, 让它更好地反映现实, 更能让学生练习算法, 更好地实现信息隐藏和信息共享。 |
目前的设计有什么缺点, 你会如何改进它? Analyze the API design, and propose a better API so that Scheduler can have more freedom and students can do more realistic scheduling. |
|
[附加题] 目前的这个测试程序只有命令行界面, 请给它设计UI 界面, 显示乘客/电梯的运动, 并实现之。 |
Implement a UI to show how people/elevator moves (write a blog to show your code and UI)
|
|
[附加题] 阅读有关 MVC 和 MVVM 设计模式的文章。 |
说明你写的电梯调度的UI /Algorithm/interface 如何实现了MVC 或MVVM 的算法。 |
|
[附加题] 我们现在的题目是假设所有电梯到达所有的楼层。 在现实生活中, 多部电梯到达的楼层都不一样。如果是这样 (例如3号电梯能到达10 – 20 层, 4 号电梯能到达5-15 层)，整个程序框架和你的电梯调度模块要做什么改变? |
请说明你的改进意见 |
作业期限: 由老师决定。
第二次结对编程作业 (同学们重新组合成为新的两人对)
1) 以实际项目为例, 完成这一个软件测试，用户调查，项目分析和规划的作业:
http://www.cnblogs.com/xinz/archive/2012/03/26/2417699.html
截止日期: 12/28/2012 晚11:00pm. (如果你到这时候还没做, 那熬夜做和第二天做是一样的，都是0 分。 不交作业倒扣分。)
2) 有了电梯的调度算法和电梯的测试模拟框架, 我们可以从数据层面模拟并测试算法的正确性和效率。 那么现在我们要加上展现的部分 – 用GUI 展现电梯系统从运送所有乘客的过程。 想象一幢大楼全都是透明的, 有许多乘客通过电梯上上下下, 电梯外墙的指示灯 (通常有上/下) 两个标识随着乘客的需求或亮或灭。
实现: 根据第一次结对项目的电梯测试系统, 和你自己的调度模块 (两个同学各带一个调度模块)，任选一种编程语言实现 GUI.
能跑起来就是成功! 详细评分标准:
1) 能完整而准确地反映调度算法运行的过程，并动态显示系统的基本数据 (当前活跃的乘客数量, 乘客的平均旅行时间, 等)
2) 能转换电梯调度模块，通过简单的命令参数就可以调用不同模块进行演示。
3) 在程序启动时，能自动调节UI 以适应不同的楼层和电梯数目的限制。
4) UI 方面, 楼层, 电梯, 乘客, 指示灯的设计要让观众看得清楚, 比例协调, 同时有一定的美感。如能支持乘客进出电梯，电梯运行的动画，则可加分。
5) 支持启动, 暂停，继续，结束等控制。
6) 按照 GUI 实现语言的种类分别给程序排序, 鼓励用比较新的语言/框架来实现。
7) 奖励分数: 如果能支持局部放大, 鼠标点击电梯/乘客能显示具体数据; 如果能设计API 让不同的展示模块能使用同一个API, 不用重新编译, 就可以加载不同展示模块 (特别是用不同的语言实现的展示模块)
演示要求:
1) 启动电梯测试框架程序和测试数据 (建议数据规模: 6 层楼, 2 部电梯, 10 乘客 ) , 载入调度算法1,
2) 同样启动电梯测试框架程序和同样的测试数据, 载入调度算法 2 (此算法必须和前一个不同),
3) 同时开始运行两个模拟情景, 查看 GUI 模块的显示是否满足各项评分标准。
4) 再载入不同的测试数据重复 ( 建议数据规模: 10 层楼, 4 部电梯， 500 人)
提交程序/文档:
1) 程序要签入TFS 截至日期: 1/9/2013
2) 把设计/源程序架构/代码行数/运行时的截屏/设计心得/等等 写成博客。 1/9/2013
