Your SlideShare is downloading. ×
0
1
ECE 18-649
Final
Project Report
Dec 2, 2012
Group # 9
Dennis Liang
Leo Lung
Melvin Rayappa
Samihan Yedkar
Melvin Rayappa
2
Overview
 Dispatcher Design Process
 Dispatcher overview
 High Level Requirements
 Behavior
 Time Triggered Require...
Dispatcher Object
 Dispatcher - determines the order in which
floors and hallways are serviced
 High Level Requirement:
...
Dispatcher Object
 High Level Requirement:
 R-T4. The performance shall be optimized to
the extent possible
 R-T5. Pass...
Dispatcher Object
 High Level Requirement:
 R-T7. The Car shall only open Doors at
Hallways for which there are pending ...
Dispatcher Algorithm
 Service in “cycles”
 Service all calls in one direction, then turn
around and repeat
 Peak – fart...
7
Requirements
Time Triggered Requirements:
•11.4 mDesiredFloor.f shall always be set to Target.
•11.5 If target equals pe...
State Chart
8
Dennis Liang
Statechart – Transition 1
 Moving from ‘Idle’ to
‘Moving’
 Condition
 Travel != Direction.STOP
9
Dennis Liang
Statechart – Transition 2
 Moving from ‘Idle’ to ‘Door open’
 Conditions
 One mDoorClosed[f,*] == false, one mAtFloor[f...
Statechart – Transition 3
 Moving from ‘Moving’ to ‘Door open’
 Conditions
 One mDoorClosed[f,*] == false, one mAtFloor...
Statechart – Transition 4
 Moving from ‘Door open’ to ‘Idle’
 Conditions
 Both mDoorClosed[f,*] == true, target == floo...
Statechart – Transition 5
 Moving from ‘Moving’ to ‘Door open’
 Conditions
 Both mDoorClosed[f,*] == true, floor != tar...
Statechart – Transition 6 & 7
 Moving from ‘Idle’ and ‘Moving’ to ‘Error’
 Conditions
 One mDoorClosed[f,*], all mAtFlo...
15
Implementation
Dennis Liang
case MOVING:
if (target == peak)
direction = getCallDirection(target, direction);
else {
if...
16
Testing
 10 acceptance tests
 All test ability of Dispatcher to deliver passengers
 All Dispatcher states except for...
17
Strategies for Correctness
 Pair Programming
 Ensure correct code gets committed
 Catch bugs as we develop
 Overnig...
18
Project Statistics
Leo Lung
Item MidSem Final
# of Sequence Diagrams 19 19
# of Sequence Diagram arcs 181 181
# of Requ...
19
Project Statistics
Leo Lung
Item MidSem Final
# of Peer Reviews 69 97
# of Bugs Found through Peer
Reviews
29 39
# of B...
Lessons Learned
 Start early; iterate often
 Dispatcher has evolved to its current state,
based on multiple design itera...
Design Choices
 Implicit target, peak, travel, direction,
hallway
 Computed within state itself
 Saves additional state...
Advice
 Use source control
 Review lab assignment early
 Email team to plan strategy
 Divide responsibilities based on...
23
Questions?
Group # 9
Dennis Liang
Leo Lung
Melvin Rayappa
Samihan Yedkar
Samihan Yedkar
Backup Slides
24
Transition Condition
11.T.1 travel != Direction.STOP
11.T.2 (mDoorClosed[f,FRONT] === false || mDoorclose...
Backup Slides
25
Transition Condition
11.T.4 (mDoorClosed[f,FRONT] === true && mDoorclosed[f,BACK]
== true) &&
(floor == t...
Backup Slides
26
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
...
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...
29
Dispatcher Scenario/Sequence Diagram
Melvin Rayappa
 Use Case U9. Cycle Doors.
 Scenario/SD 9A: Elevator stops at Hal...
Backup Slides
30
Backup Slides
31
32
Upcoming SlideShare
Loading in...5
×

Group9 f12 18649_final_presentation

73

Published on

no

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
73
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

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 of "Group9 f12 18649_final_presentation"

    1. 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. 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. 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. 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. 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. 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. 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. 8. State Chart 8 Dennis Liang
    9. 9. Statechart – Transition 1  Moving from ‘Idle’ to ‘Moving’  Condition  Travel != Direction.STOP 9 Dennis Liang
    10. 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. 11. Statechart – Transition 3  Moving from ‘Moving’ to ‘Door open’  Conditions  One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true 11 Dennis Liang
    12. 12. Statechart – Transition 4  Moving from ‘Door open’ to ‘Idle’  Conditions  Both mDoorClosed[f,*] == true, target == floor == peak 12 Dennis Liang
    13. 13. Statechart – Transition 5  Moving from ‘Moving’ to ‘Door open’  Conditions  Both mDoorClosed[f,*] == true, floor != target or target != peak 13 Dennis Liang
    14. 14. Statechart – Transition 6 & 7  Moving from ‘Idle’ and ‘Moving’ to ‘Error’  Conditions  One mDoorClosed[f,*], all mAtFloor[*,*] == false 14 Dennis Liang
    15. 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. 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. 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. 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. 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. 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. 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. 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. 23 Questions? Group # 9 Dennis Liang Leo Lung Melvin Rayappa Samihan Yedkar Samihan Yedkar
    24. 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. 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. 26. Backup Slides 26
    27. 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. 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. 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. 30. Backup Slides 30
    31. 31. Backup Slides 31
    32. 32. 32
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×