Сторінка подій (Events) інспектора об'єктів показує список подій, розпізнаваних компонентом. Кожен компонент має свій власний набір обробників подій.

Метод є функцією, яка пов'язана з компонентом, і яка оголошується як частина об'єкту. Створюючи обробники подій, можна викликати методи, використовуючи нотацію -> , наприклад:

Memo1->Clear(); (очистка багаторядкового редактора тексту)

Проектом називають сукупність фай-лів, з яких С++ Builder створює готову для виконання програ-му.

5.2.2 Створення розробки засобами Borland С++ Builder

Отже, програма визначення характеристик функціонування торгового центру буде побудована таким чином.

Як згадувалося раніше, вхідними параметрами для обрахунку будуть:

– кількість заявок в одиницю часу;

– час обслуговування однієї заявки;

– час очікування заявки на обслуговування;

– кількість каналів обслуговування.

У наступній таблиці наведені об’єкти з їх назвами на формі.

Таблиця 5.1 – Об’єкти та їх назви на формі.

Вид об’єкта | Об’єкт | Назва об’єкту на формі

Текстові поля | Label1 | Кількість заявок в одиницю часу

Label2 | Час обслуговування однієї заявки

Label3 | Час очікування заявки на обслуговування

Label4 | Кількість каналів обслуговування

Поля для вводу даних | Edit1 – Edit4 | Поля для вводу даних, що відповідатимуть об’єктам Label1 – Label4

Кнопка | Button1 | Отримати показники ситеми

Текстові поля | Label5 | Ймовірність того,що всі канали вільні

Label7 | Ймовірність зайнятості каналів обслуговування

Label8 | Довжина черги (кількість заявок, що перебувають в черзі)

Label9 | Загальна кількість заявок,що перебувають в системі

Label10 | Середня тривалість перебування заявки в черзі

Label11 | Середня тривалість перебування заявки в системі

Поле для вводу даних | Edit5 | Поле для виводу даних, що відповідатиме об’єкту Label5

Багаторядковий редактор тексту | Memo1 | Область для виводу даних, що відповідатиме об’єкту Label7

Поля для вводу даних | Edit7 – Edit12 | Поля виводу даних, що відповідатимуть об’єктам Label8 – Label13

Кнопка | Button2 | Вихід (з програми)

Кнопка | Button3 | Побудова графіку залежності довжини черги від кількості каналів обслуговування

Отже, програмне забезпечення для подальшої оптимізації роботи торгового центру буде організована наступним чином. Для зручності будуть створені дві процедури:

а) для знаходження довжини черги в залежності від кількості каналів обслуговування find_L;

б) для обчислення факторіалу fact.

Основна програма містить також покажчик *P на об’єкт (на масив, що буде змінюватися в залежності від значеня N). Текст програми знаходиться в додатку Г.

5.3 Аналіз одержаних результатів

Запустивши програму на виконання, отримаємо наступні результати:

Рисунок 5.1 – Результати розробки при кількості каналів обслуговування, що дорівнює шести.

Отже, при вхідних параметрах: 360 (заявок/годину), 2 (хвилини на обслуговування заявки), 4 (хвилини на очікування заявки в черзі) та 6 (каналах обслуговування) отримали наступні показники. Крива 1 відповідає одній хвилині обслуговування, крива 2 – двом хвилинам, крива 3 – трьом хвилинам. Бачимо, що мінімальна довжина черги 11,5 заявок (крива 1), а максимальна – більше 16-ти (крива 3). Аналіз отриманих результатів говорить про недостатню кількість каналів обслуговування.

Для кращого розуміння процесу збільшимо вхідний потік до 600 заявок в годину. Отримаємо наступні криві:

Рисунок 5.2 – Результати розробки при вхідному потоці 600 заявок.

Бачимо по графікам, що черга зросла до 19-ти і криві стали більш випуклими при вхідному потоці 600 заявок (крива 3).

В додатку Д зображені деякі інші графіки залежностей вихідних показників від вхідних параметрів.

Отже, показники системи маємо, спробуємо оптимізувати роботу системи.

Оптимізація полягає в порівнянні отриманих результатів та в прийнятті рішення шодо зменшення довжини черги та часу перебування заявки в системі. Звичайно, що можна мінімізувати довжину черги, збільшивши кількіть каналів, припустимо, вдвічі. Проте при цьому зростають витрати на закупівлю та утримання даних канлів обслуговування.

Проведемо оптимізацію, розглянувши модель з точки зору вартісних характеристик, яка прагне зрівноважити два “конфліктуючі” вартісні показники: витрати на утримання каналу (при певних характеристиках вхідного потоку вимог і часу обслуговування кожної заявки) та витрати, обумовлені затримками в наданні послуг, що призводить до створення нескінченних черг. Ці два види витрат конфліктують між собою, оскільки збільшення одне з них автоматично веде до зменшення іншого і навпаки.

В моделі з вартісними характеристиками мінімізується сума витрат, пов'язаних з наданням послуг, і втрат, обумовлених затримками в їх наданні.

На рис. 5.3 зображена типова вартісна модель магазину самобслуговування (у грошових одиницях за одиницю часу), де витрати на обслуговування зростають із зростанням його рівня. В той же час втрати, обумовлені затримками в наданні послуг, зменшуються із зростанням рівня обслуговування. Головною проблемою, зв'язаною із застосуванням вартісних моделей, є труднощі оцінки втрат в одиницю часу, обумовлених затримками в наданні послуг[2].

Рисунок 5.3 – Вартісна модель магазину самобслуговування.

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

Спробуємо визначити “прийнятну” кількість каналів обслуговування наступним чином. Для цього розглянемо два конкуруючі між собою економічні показники процесу обслуговування: середній час очікування в системі Ws та відсоток простою сервісів P.

Середній час очікування в системі можна отримати використовуючи формулу (2.14), описану в другому розілі. Відсоток простою засобів обслуговування можна обчислити таким чином:

(5.1)

Завдання