See the Google Doc for the Iteration 5 brainstorm.
Iteration 5 Description (April 8th? 9th?)
The last stage of the project is to add a display console showing where each of the elevators is in real time and displaying any faults (if any). The idea is to have output suitable for the concierge sitting at the desk in the front lobby to refer to. This part of the project can be part of the floor subsystem if you so choose, or you may want to develop a separate subsystem altogether.
Finally, you will have to measure the performance of the scheduler subsystem. To do so, measure how long your system takes to run the entire input file. Your system should allow the time it takes to move between floors and the time it takes to load/unload an elevator to be specified.
Major Iteration Goals
[x] (Need) #196
[x] (Need) #203
[x] (Need) #201
[x] (Need) #204
[x] (Need) Adjust requestQueue methods for variable time
[ ] (Great to have) Fix any existing tests that are broken or break easily
[x] (Great to have) Incorporate #206
[x] (Great to have) Way of initializing system #212, #214
Major Project Goals
[ ] (Unknown) Sequence diagrams for error scenarios.
[x] (Need) More input requests #221
[x] (Need) Show faults in GUI -> somehow ?
[ ] (Need) Reflection on Design, what could be changed
[ ] (Need) Scheduler State Machine Diagram
[x] (Need) Statements for Elevator Doors opening / closing #236
[ ] Timing diagrams showing your measured values.
[ ] (Need?) Video demonstrating functionality of system
[ ] (Need) Realistic elevator travel and wait times
[ ] (Need) Make sure everything works properly
[ ] (Great to have, need to confirm). When the elevator stuck it should be shut down and stop receiving any new request.
[x] Set systemStatus to false upon ArrivalSensor fault.
[ ] (Great to have) Remove the thing saying "elevator received approachEvent," "elevator sent ElevatorMonitor"
[x] (Great to have) Only use one door fault - if it's stuck, transient fault #236
[x] Consider using a boolean instead of an interrupt
[x] (Great to have) Show the elevator's currentRequest in the GUI
(Great to have) Change design / setup of Scheduler and Elevator communication to have Scheduler being constantly updated and telling Elevator what to do
(Great to have) Delegate some of Elevator's attributes and responsibility to a new ElevatorSubsystem class
(Great to have) More test files demonstrating Simulation #239
(Good to have) ArrivalSensor's responsibility increased
(Good to have) Start screen allowing input of number of floors, elevators, number of requests, enable timing, start Simulation
(Nice to have) Many-to-one relationship between Elevator and Scheduler
(Nice to have) Floor and elevator buttons
Video:
We should take turns
Measurements
[x] There should be a confidence interval, variance, etc. like in assignment 5
[x] Have the time it takes to send one request
[x] Get the time it takes for scheduler to .... ????
Iteration Deliverables
[ ] “README.txt” file explaining the names of your files, set up instructions, etc.
[x] Breakdown of responsibilities of each team member for this and previous iterations
[ ] Any unchanged diagrams from the previous iterations UML class diagram
[ ] Timing diagrams showing your measured values.
[ ] Detailed set up and test instructions, including test files used
[ ] Code (.java files, all required Eclipse files, etc.)
Final Presentation (April 12th?)
Your team will give a 15 minute presentation to a TA of iteration #5. It must show four elevators running with 22 floors with arrivals at levels one and two (i.e., the Dunton Tower). These arrivals must also eventually depart from either level one or two. To simulate people who arrive at level 2, then go down only to go up again, assume they depart and arrive at level 1 at the same time. Your demonstration should also show stuck doors on one elevator and a stuck elevator on a second. It is not necessary to demonstrate annoyed passengers typically found in Dunton. The goal of the presentation is to show us how awesome your team and project are, and to submit your final copy of your work using CULearn.
Final Project Presentation Work Products:
You must submit all of the following:
README: A report consisting of:
[x] Team number and team members
[ ] Table of contents
[x] Breakdown of responsibilities of each team member for each iteration
[x] Detailed set up and test instructions.
[x] Results from your measurements.
[ ] Reflection on your design - what parts do you like and what parts should be redone.
All diagrams:
[ ] UML class diagrams for the three components
[ ] A State Machine diagram for the scheduler.
[ ] Sequence diagrams showing all the error scenarios.
[ ] Timing diagrams for the scheduler.
Code
[ ] Test files for all iterations.
[ ] Code (.java files, all required Eclipse files, etc.)
cuLearn Description:
Please submit a brief video demonstration showing your code in action up to and including iteration 5, along with your final report. You should show your system running on at least three separate processes that communicate with each other. You don't need to use three computers, just use the loopback address 127.0.0.1 (localhost) on a single machine.
Due Tuesday, April 12th (the last day of classes) at one minute before Midnight. Please submit PDF for all documentation and a short video as a separate file. If you choose to compress your submission, please use ZIP. Be sure to submit early, and to submit often. Late submissions will not be accepted.
All Elevator state changes must be reflected in GUI in real time
[x] #227
[ ] Test PresenterView update with ElevatorMonitor transfer from Elevator
[ ] (Need) Show the elevator's currentRequest in the GUI
[ ] IDEA: have Presenter be a thread that constantly checks for the latest added ElevatorMonitor
206
[x] Have someone test importing the exported archive file
(must delete dependencies to simulate TA conditions) for instructions on exporting from Eclipse properly, try this or this
ReadMe
[ ] "Editing" section contains a lot of info that should be included in the "Installation" section.
[ ] Determine whether the (n+1 if elevator moving DOWN)th or (n-1 if elevator moving UP)th floor is considered when assigning requests to elevators (if elevator moving up from 1 to 2, it should get any up requests being served at 2)
[ ] Show fault in GUI
[x] Scheduler should say which elevator has been assigned which request
Iteration 5
See the Google Doc for the Iteration 5 brainstorm.
Iteration 5 Description (April 8th? 9th?)
The last stage of the project is to add a display console showing where each of the elevators is in real time and displaying any faults (if any). The idea is to have output suitable for the concierge sitting at the desk in the front lobby to refer to. This part of the project can be part of the floor subsystem if you so choose, or you may want to develop a separate subsystem altogether.
Finally, you will have to measure the performance of the scheduler subsystem. To do so, measure how long your system takes to run the entire input file. Your system should allow the time it takes to move between floors and the time it takes to load/unload an elevator to be specified.
Major Iteration Goals
Major Project Goals
Video:
Measurements
Iteration Deliverables
Final Presentation (April 12th?)
Your team will give a 15 minute presentation to a TA of iteration #5. It must show four elevators running with 22 floors with arrivals at levels one and two (i.e., the Dunton Tower). These arrivals must also eventually depart from either level one or two. To simulate people who arrive at level 2, then go down only to go up again, assume they depart and arrive at level 1 at the same time. Your demonstration should also show stuck doors on one elevator and a stuck elevator on a second. It is not necessary to demonstrate annoyed passengers typically found in Dunton. The goal of the presentation is to show us how awesome your team and project are, and to submit your final copy of your work using CULearn.
Final Project Presentation Work Products:
You must submit all of the following:
cuLearn Description:
Please submit a brief video demonstration showing your code in action up to and including iteration 5, along with your final report. You should show your system running on at least three separate processes that communicate with each other. You don't need to use three computers, just use the loopback address 127.0.0.1 (localhost) on a single machine.
Due Tuesday, April 12th (the last day of classes) at one minute before Midnight. Please submit PDF for all documentation and a short video as a separate file. If you choose to compress your submission, please use ZIP. Be sure to submit early, and to submit often. Late submissions will not be accepted.
Iteration 5 Work Breakdown structure:
See Google Doc for the Iteration 5 brainstorm.
206