Group9 f12 18649_final_presentation
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
132
On Slideshare
126
From Embeds
6
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 6

http://melvin.x10.mx 6

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • First we are going to talk about our design of
  • mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
  • mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
  • mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
  • mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
  • 9 tests instantiate Dispatcher: grep Dispatcher *.cf 4 tests test arc 11.T.1: grep BOTH_DOORS *.mf
  • 9 tests instantiate Dispatcher: grep Dispatcher *.cf 4 tests test arc 11.T.1: grep BOTH_DOORS *.mf

Transcript

  • 1. 1 ECE 18-649 Final Project Report Dec 2, 2012 Group # 9 Dennis Liang Leo Lung Melvin Rayappa Samihan Yedkar Melvin Rayappa
  • 2. 2 Overview  Dispatcher Design Process  Dispatcher overview  High Level Requirements  Behavior  Time Triggered Requirements  State Chart  Implementation  Testing  Runtime Monitor  Project Statistics  Lessons Learned  Strategies  Design Choices  Advice Melvin Rayappa
  • 3. Dispatcher Object  Dispatcher - determines the order in which floors and hallways are serviced  High Level Requirement:  R-T1. All passengers shall eventually be delivered to their intended destination floor 3 Inputs Outputs mAtFloor [f,b] mDesiredFloor mDoorClosed [b,r] mDesiredDwell mHallCall [f,b,d] mCarCall [f,b] mCarWeight Melvin Rayappa
  • 4. Dispatcher Object  High Level Requirement:  R-T4. The performance shall be optimized to the extent possible  R-T5. Passenger satisfaction shall be optimized to extent possible  R-T6. The Car shall only stop at floors for which there are pending calls 4 Melvin Rayappa
  • 5. Dispatcher Object  High Level Requirement:  R-T7. The Car shall only open Doors at Hallways for which there are pending calls  Dispatcher determines which floors to stop at  R-T8.2. If one of the car lanterns is lit, the direction indicated shall not change while the doors are open  Dispatcher changes desired direction 5 Melvin Rayappa
  • 6. Dispatcher Algorithm  Service in “cycles”  Service all calls in one direction, then turn around and repeat  Peak – farthest floor in the direction of travel  Target – the desired floor  Travel – current cycle direction 6 Melvin Rayappa
  • 7. 7 Requirements Time Triggered Requirements: •11.4 mDesiredFloor.f shall always be set to Target. •11.5 If target equals peak and there are no hall calls at the target floor in the same direction, reverse Direction. •11.6 Whenever any mDoorClosed [b, r] is False, then • 11.6.1 Target shall be set equal to the closest car call or hall call (of the same direction as current) between current floor and the peak. • 11.6.2 mDesiredFloor.b shall be set to b, where f, b is whichever mAtFloor[f, b] is True • 11.6.3 mDesiredFloor.b shall be set to Direction •11.7 If all mAtFloor[f, b] are False AND any mDoorClosed [b, r] is False (which means doors are not closed between floors!) then • 11.7.1 Target shall be set to 1 • 11.7.2 mDesiredFloor.b shall be set to None . •11.8 If two mAtFloor[f, b] values are True with the same value f, then mDesiredFloor.b shall be set to Both. •11.9 mDesiredDwell shall always be set to a constant appropriate value for door open dwell. •11.10 Peak shall always be set to the farthest hall call or car call in the same direction as current. Melvin
  • 8. State Chart 8 Dennis Liang
  • 9. Statechart – Transition 1  Moving from ‘Idle’ to ‘Moving’  Condition  Travel != Direction.STOP 9 Dennis Liang
  • 10. Statechart – Transition 2  Moving from ‘Idle’ to ‘Door open’  Conditions  One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true, travel == Direction.STOP 10 Dennis Liang
  • 11. Statechart – Transition 3  Moving from ‘Moving’ to ‘Door open’  Conditions  One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true 11 Dennis Liang
  • 12. Statechart – Transition 4  Moving from ‘Door open’ to ‘Idle’  Conditions  Both mDoorClosed[f,*] == true, target == floor == peak 12 Dennis Liang
  • 13. Statechart – Transition 5  Moving from ‘Moving’ to ‘Door open’  Conditions  Both mDoorClosed[f,*] == true, floor != target or target != peak 13 Dennis Liang
  • 14. Statechart – Transition 6 & 7  Moving from ‘Idle’ and ‘Moving’ to ‘Error’  Conditions  One mDoorClosed[f,*], all mAtFloor[*,*] == false 14 Dennis Liang
  • 15. 15 Implementation Dennis Liang case MOVING: if (target == peak) direction = getCallDirection(target, direction); else { if (travel == Direction.UP) direction = Direction.UP; else direction = Direction.DOWN; } if (direction == Direction.STOP) hallway = getCallHallway(target); else hallway = getCallHallway(target, direction); mDesiredFloor.setFloor(target); mDesiredFloor.setDirection(direction); mDesiredFloor.setHallway(hallway); ... //#transition "11.T.3" if (!mDoorClosedArrayFront.getBothClosed() || !mDoorClosedArrayBack.getBothClosed() && floor != MessageDictionary.NONE) newState = State.DOOR_OPEN; State Action SC to Code Traceability Transition Implementation Implicit DesiredFloor Computation
  • 16. 16 Testing  10 acceptance tests  All test ability of Dispatcher to deliver passengers  All Dispatcher states except for error tested  Runtime Monitor  Test car only stops at floors with pending calls Leo Lung
  • 17. 17 Strategies for Correctness  Pair Programming  Ensure correct code gets committed  Catch bugs as we develop  Overnight Testing  Run acceptance tests overnight  Ensure no corner cases from specific seeds Leo Lung
  • 18. 18 Project Statistics Leo Lung Item MidSem Final # of Sequence Diagrams 19 19 # of Sequence Diagram arcs 181 181 # of Requirements 53 49 # of Statecharts 7 7 # of Statechart States 20 21 # of Statechart Arcs 27 32 # of Non-Commented Lines of Code 1912 2802 # of Unit Tests 7 7 # of Integration Tests 19 19 # of Acceptance Tests 3 10
  • 19. 19 Project Statistics Leo Lung Item MidSem Final # of Peer Reviews 69 97 # of Bugs Found through Peer Reviews 29 39 # of Bugs Fixed through Peer Reviews 29 39 # of Bugs Found through Testing 23 35 # of Bugs Fixed through Testing 23 35 # of Issue Log Entries 16 23 # of Unresolved Defects 3 4 # of Change Log Entries 13 17
  • 20. Lessons Learned  Start early; iterate often  Dispatcher has evolved to its current state, based on multiple design iterations  Work together  Especially on system critical controllers, important to have all hands on deck  Whiteboarding solutions  Brainstorming, sanity checking, optimizing  Focus on simplicity  Dispatcher as just 4 states, clear and straightforward transitions  Easy to debug 20 Samihan Yedkar
  • 21. Design Choices  Implicit target, peak, travel, direction, hallway  Computed within state itself  Saves additional states  Code compaction  Algorithm is easy to test  CommitPoint computation in FastSpeed state  Done dynamically  Based on equations of motion  1m buffer added for safety/hedge against strange behaviors: err on the side of caution Samihan Yedkar 21
  • 22. Advice  Use source control  Review lab assignment early  Email team to plan strategy  Divide responsibilities based on controller efficiency  Work together  Incredibly helpful to bounce ideas and thoughts  Whiteboard solutions  Pair program  Peer review  Go over checklist right before submission  Sanity checking Samihan Yedkar 22
  • 23. 23 Questions? Group # 9 Dennis Liang Leo Lung Melvin Rayappa Samihan Yedkar Samihan Yedkar
  • 24. Backup Slides 24 Transition Condition 11.T.1 travel != Direction.STOP 11.T.2 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK] == false) && (mAtFloor[f,FRONT] == true || mAtFloor[f,BACK] == true) && (travel == Direction.STOP) 11.T.3 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK] == false) && (mAtFloor[f,FRONT] == true || and mAtFloor[f,BACK] == true)
  • 25. Backup Slides 25 Transition Condition 11.T.4 (mDoorClosed[f,FRONT] === true && mDoorclosed[f,BACK] == true) && (floor == target && target == peak) 11.T.5 (mDoorClosed[f,FRONT] === true && mDoorclosed[f,BACK] == true) && (floor != target || target != peak) 11.T.6 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK] == false) && (mAtFloor[f,FRONT] == false && mAtFloor[f,BACK] == false) 11.T.7 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK] == false) && (mAtFloor[f,FRONT] == false && mAtFloor[f,BACK] == false)
  • 26. Backup Slides 26
  • 27. Backup Slides 27 Requirements States 11.4 11.5 11.6.1 11.6.2 11.6.3 11.7.1 11.7.2 11.8 11.9 11.10 State 1: Idle X X X X X State 2: Moving X X X State 3: Door open X X X X X X State 4: Error X X X X
  • 28. Backup Slides 28 Requirements Transitions 11.4 11.5 11.6.1 11.6.2 11.6.3 11.7.1 11.7.2 11.8 11.9 11.10 11.T.1 X 11.T.2 X X X 11.T.3 X X X 11.T.4 X 11.T.5 X 11.T.6 X X 11.T.7 X X
  • 29. 29 Dispatcher Scenario/Sequence Diagram Melvin Rayappa  Use Case U9. Cycle Doors.  Scenario/SD 9A: Elevator stops at Hallway. Dispatcher computes desired floor Dispatcher computes and broadcasts desired floor Dispatcher broadcasts desired dwell time
  • 30. Backup Slides 30
  • 31. Backup Slides 31
  • 32. 32