рах різну кількість таксі, тому й відповідно кількість обслужених клієнтів теж буде різне.
Моделювання генерації заявок здійснюється на основі різних імовірнісних законів.
Потрібно конфігурувати відділення служби таксі, ефективно обслуговувати потік заявок, в якості критеріїв оцінки приймається:
довжина черги;
зайнятість обслуговуючого персоналу;
кількість оброблених заявок.
Структура імітаційної моделі, що відповідає вимогам, повинна відображати структуру СМО: заявки (клієнти таксі) генеруються (входять в систему), стають у черги в обслуговування підсистемами, а після повного обслуговування залишають систему.
Підсистема «Черга» повинна обробляти надійшли заявки почергово за умови наявності двох видів заявок або заявки одного типу за умови відсутності заявок іншого типу на рис. 3.1.
Малюнок 3.1 Модель компонента підсистеми «Черга» на основі СП
У даному прикладі моделі позиції Р1 і Р2 служать накопичувачами заявок. Переходи t1 і t2 призначені для переміщення заявки у разі утворення черги в одній з позицій і відсутність заявок в іншій.
Підсистема «Оброблювач черги» призначена для:
почергової обробки заявок;
перевірки надходження першої заявки для надбудови підсистеми;
контролю кількості заявок перед підсистемами обслуговування.
Модель підсистеми показана на рис. 3.2.
Рисунок 3.2 Модель компонента обслуговування для відділів
Зв'язок між підсистемами забезпечують переходи t1 і t2. Перехід мітки з позиції Р2 в позицію Р1 говорить про початок обробки заявки компонентом підсистеми.
Підсистеми «Статистика обробки», «Заявок всього» і «Опрацьовано всього» реалізовані за допомогою позицій, які є накопичувачами.
Ці підсистеми служать для оцінки ефективності отриманої конфігурації.
Для забезпечення можливості підключення в процесі роботи додаткових компонентів в підсистемах обслуговування «Економічного відділу» і «Відділу платежів» розроблена модель (рис.3.4), що дозволяє залежно від інтенсивності потоку заявок перебудовувати від інтенсивності потоку заявок перебудовувати структуру конфигурируемого об'єкта.
У розробленої моделі перехід t1 служить для зв'язку компонента з підсистемою «Оброблювач черги». Позиція Р2 використовується для отримання мітки з підсистеми «Підключення компонентів підсистем», що дозволить підсистемі «Оброблювач черги» запустити заявку на виконання. Перехід t2 відправляє оброблену заявку в підсистему «Статистика обробки».
Модуль «Підключення компонентів підсистем» забезпечує можливість введення нових компонентів за умови утворення заданої кількості заявок чекаючих обробки в черзі (малюнок 3.5). Тут позиція Р1 повинна бути пов'язана з «Генераторами заявок» і служить накопичувачем всіх заявок надійшли на обробку підсистемами «Економічного відділу» і «Відділу платежів», і зв'язується з переходом t2 компонентів обслуговування, тим самим забезпечується контроль кількості заявок, що знаходяться в системі і чекаючих обробки.
Всі Х дуги, що входить до перехід t1, залежить від того, скільки заявок повинне знаходитися в черзі для підключення додаткових компонентів підсистем обробки від максимальної кількості заявок, які очікують обробки.
Малюнок 3.3 Модель елемента модуля «Підключення компонентів підсистем»
Перехід повертає мітки в позицію Р1 і генерує мітку в позицію Р2, тим самим підключаючи компонент. Позиція Р1 зв'язується з переходом t1 компонентів обслуговування підсистем, тим самим зменшуючи кількість заявок чекаючих обробки, при початку їх обслуговування підсистемами. Обробку черзі, відповідно до висунутих вимог, забезпечують підсистеми «Оброблювач черги».
Малюнок 3.4 Приклад конфігурації відділення служби таксі
Відділ «Платежів», модельований однотипними компонентами, враховує інтенсивність потоків заявок і перебудовується в процесі роботи. Приклад конфігурації відділення платежів в службі таксі представлений на рис. 3.5.
Малюнок 3.5 Приклад конфігурації відділення платежів в таксі.
Представлена ??конфігурація містить в собі 14 позицій:
Позиції Р1, Р2 - накопичувачі заявок;
Позиції Р3, Р4 - статистика обробки;
Позиція Р5 - обробник черги;
Позиція Р6 - черга заявок;
