3.2. Управління часом

У методі Main () один з методів класу Building викликається через певні інтервали часу, щоб моделювання було динамічнішим. Цей метод називається master_tick ().

Він, у свою чергу, викликає функцію для кожного ліфта під назвою car_tickl (). Вона, крім усього іншого, промальовує ліфт на екрані і викликає ще одну функцію для прийняття рішення про те, що робити далі. Вибір дій багатий:

1) поїхати вниз;

2) поїхати вгору;

3) зупинитися;

4) посадити пасажира;

5) випустити пасажира;

6) вийти з програми;

7) викликати ще один ліфт.

Після цього кожен ліфт повинен бути зрушений на свою нову позицію. Так. Щось в цьому місці всі ускладнюється. Оскільки кожен ліфт повинен знати, де знаходяться інші, перш ніж прийняти рішення, всі ліфти повинні пройти через процес прийняття рішення, перш ніж хтось із них зрушиться з місця. Щоб упевнитися в тому, що це дійсно має місце, ми запускаємо tick'і двічі для кожної кабінки. Таким чином, car_tick1 () викликається для прийняття рішення про те, куди кожен ліфт поїде, а інша функція - car_tick2 () - для реального запуску ліфтів.

Змінюється значення змінної current_floor - кабінки починають рухатися.

Процес посадки пасажирів включає в себе послідовність певних кроків, які на екрані відображаються так:

1. кабінка з закритими дверима, щасливе обличчя відсутня;

2. кабінка з відкритими дверима, щасливе обличчя зліва ☺;

3. кабінка зі щасливим обличчям ☺ у відкритих дверях, дізнатися від пасажира кінцевий поверх;

4. Кабінка з закритими дверима, щасливе обличчя відсутня. При висадці пасажира застосовується зворотний порядок.

3.3. Діаграма станів для програми elev

Розглянемо діаграму станів для програми моделювання ліфтів. З метою спрощення задачі, будемо вважати, що в будівлі знаходиться тільки одна людина і є тільки один ліфт. Таким образом, в один момент часу може бути тільки один запит c поверху і один поверх призначення. Ліфту не потрібно стежити за іншими. Діаграма станів представлена ​​на рис. 3.

Позначення в діаграмі такі:

«Cd» - поверх призначення, тобто кнопка, натиснута всередині ліфта (грубо кажучи, це відповідає массиву destination з програми);

«Fr» - запит з поверху, кнопка, натиснута зовні ліфта (грубо кажучи, це значення змінної floor_req).

Стан ліфта визначаються за значеннями змінної current_dir (в якому напрямку їдемо? і станам loading_timer (посадка) і unloading_timer (висадка).

Оскільки всі стани переходять один в одного за допомогою слова «раптом» (тобто по сигналам таймера), на діаграмі показані тільки контрольні стану. Відображаються представлення ліфта:

1) про запити з поверхів («fr»);

2) про запити поверхів призначення («cd»).

Рис. 3. Діаграма станів об’єкту Elev

3.4. Стратегія роботи ліфтів

Вбудовування інтелекту необхідного рівня в ліфтові системи - не просте завдання. Процес прийняття рішення відпрацьовується функцією decide (), що складається з певного набору правил. Ці правила організовані в порядку їх пріоритету. Якщо застосовується одне з них, то виконується якась дія, при цьому правила більш низьких рівнів не відпрацьовуються. Наведемо спрощений варіант такої обробки:

1. Якщо ліфт ось-ось вріжеться в дно шахти або проб'є її дах, напевно, слід зупинитися.

2. Якщо даний поверх - це поверх призначення, висадити пасажирів.

3. Якщо виявлений на даному поверсі запит «вгору», їдемо вгору, завантажуємо пасажирів.

4. Якщо виявлений на даному поверсі запит «вниз», їдемо вниз, завантажуємо пасажирів.

5. Якщо немає запитів поверхів або поверхів призначення ні знизу, ні зверху, зупинитися.

6. Якщо поверхи призначення зверху, їдемо вгору.

7. Якщо поверхи призначення знизу, їдемо вниз.

8. Якщо стоїмо або рухаємося вгору, є запит з більш високого поверху, і немає при цьому ліфтів, рухаюшихся вгору, між нами і поверхом запиту або над ним, а також рухомих вниз і знаходяться ближче до нього, ніж ми, то їдемо вгору.

9. Якщо стоїмо або рухаємося вниз, є запит з більш низького поверху, і немає при цьому ліфтів, рухомих вниз, між нами і поверхом запиту або під ним, а також рухомих вгору і знаходяться ближче до нього, ніж ми, то їдемо вниз.

10. Якщо нічого нікому від нас не потрібно, зупиняємося.

Правила 8 і 9 досить складні. Вони призначені для виключення виконання одного і того ж запроса кількома ліфтами відразу. Тим не менше результати не завжди ідеальні. У деяких ситуаціях ліфти зволікають з ухваленням рішення, побоюючись зробити те, що можуть зробити за них інші.

Але в реальності в цей момент інші ліфти не рухаються до тієї ж мети, а, наприклад, відповідають на свої запити. Щоб поліпшити стратегію роботи системи, необхідно змусити розрізняти функцію decide () запити «вгору» і «вниз» під час перевірки відносного місцезнаходження ЗЕ (запиту з поверху).

Але це ще більше ускладнило б і без того занадто довгу функцію.