Размещено на http://www.allbest.ru/

РЕФЕРАТ

Объектом разработки являлась программа моделирования работы системы массового обслуживания на примере работы станции скорой помощи.

Целью разработки являлось получение различной информации о работе системы при различных настройках в графическом и текстовом виде. Основным методом решения задачи было использование существующих классов и создание новых на их основе по принципу наследования, а также реализация интерфейсов для использования создаваемых классов с уже существующими. Программа была реализована при помощи объектно-ориентированного языка Java.

Данная модель разработана с использованием средств среды разработки программ Eclipse 3.3. При реализации модели были использованы средства как текстового, так и визуального программирования.

В ходе разработки была получена работоспособная программа, реализующая поставленную задачу с возможностями изменения различных настроек.

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

ФУНКЦИЯ РЕГРЕССИИ, Java, СИСТЕМА МАССОВОГО ОБСЛУЖИВАНИЯ, ДИНАМИЧЕСКАЯ ИНДИКАЦИЯ, НАСЛЕДОВАНИЕ, ПРОЦЕСС.

РЕФЕРАТ

Об'єктом розробки була програма моделювання роботи системи масового обслуговування на роботи пожарної станції.

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

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

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

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

ФУНКЦІЯ РЕГРЕСІЇ, Java, СИСТЕМА МАСОВОГО ОБСЛУГОВУВАННЯ, ДИНАМІЧНА ІНДИКАЦІЯ, НАСЛІДУВАННЯ, ПРОЦЕС.

THE ABSTRACT

Installation of development was the program of modelling of system operation of queuing on an instance of excavation operations.

The development purpose was reception of the various information on system operation at various customisations in a graphical and text aspect. Usage of existing classes and creation new on their basis by an inheriting principle, and also implementation of interfaces for usage of created classes with already existing was the basic solution technique of a problem. The program has been realised by means of object-oriented language Java.

During development the efficient program realising a task in view with possibilities of change of various customisations has been gained.

The further development of work probably aside development of more convenient interface, and also increase of reliability of work of the program.

Excavation operations, REGRESSION FUNCTION, Java, QUEUING SYSTEM, DYNAMIC INDICATION, INHERITING, PROCESS.

Вступ

Проблема моделювання роботи систем масового обслуговування (СМО) на сьогодні має значну актуальність і займає вагоме місце в сучасному моделюванні.

Система масового обслуговування - це система, об'єкти якої виконують певні маніпуляції над вхідними елементами («обслуговують» їх), після чого передають їх на вихід. Найчастіше обслуговування відбувається послідовно, тобто оброблений елемент з виходу одного обслуговуючого елементу поступає на вхід іншого. Прикладом паралельного обслуговування може бути система, на вхід якої надходять об'єкти з різними властивостями, які вимагають різної обробки, або коли деякі складові системи проводять одні і ті ж дії над вхідними елементами.

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

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

Для СМО моделювання роботи має велике значення, оскільки, виконавши декілька серій експериментів, можна встановити оптимальні налаштування останньої.

1. Аналіз системи, що підлягає моделюванню

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

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

Можлива така ситуація, коли є виклик у даному районі, тоді машина їде на місце виклику. Можлива ситуація, коли на місце виклику приїжджає на місце виклику. До приїзду на задане місце вона затримується на деякий час. В кінці машина швидкої допомоги приїздить на станцію швидкої допомоги і стає в чергу. Аналогічна ситуація з машиною міліції.

Аналізуючи опис системи, наведений у завданні, можна виділити наступні абстракції:

1. Абстракція «машина швидкої допомоги» моделює машину, що виїзжає на виклик. У системі може працювати одразу декілька машин. На дорогу до місця виклику вона витрачає деякий час, що є випадковою величиною. Абстракція «машина швидкої допомоги» у системі може перебувати у одному з чотирьох станів - чекання на виклик, дорога до місця виклику, надання першої допомоги, повернення на станцію.

2. Абстракція «черга машин швидкої допомоги» моделює чергу машин, що чекають на виклик.

3. Абстракція «генератор викликів» через псевдовипадкові інтервали часу додає виклик в чергу викликів.

4. Абстракція «черга викликів» моделює чергу викликів, що виникли.

5. Абстракція «машина міліції» моделює машину, що виїзжає на виклик швидкої допомоги. У системі може працювати одразу декілька машин. На дорогу до місця виклику вона витрачає деякий час, що є випадковою величиною.

6. Абстракція «черга машин міліції» моделює чергу машин, що чекають на виклик.

2 ДОСЛІДЖЕННЯ ІСНУЮЧИХ МЕТОДІВ ПРОЕКТУВАННЯ СИСТЕМ МАСОВОГО ОБСЛУГОВУВАННЯ

Існує ряд класів, використовуваних у лабораторних роботах по дисципліні "Моделювання", призначених для проектування систем масового обслуговування. Ці класи істотно полегшують роботу програміста, дозволяючи йому сконцентруватися на реалізації структури СМО. Якщо який-небудь елемент моделі СМО має специфічні властивості або правила дії, то створюється новий клас, що реалізує цей компонент й успадковує стандартний базовий клас. Таким чином, можна одержати новий нестандартний компонент СМО, затрачаючи на це мінімальну кількість часу.

Дані класи знаходятся в наступних пакетах:

1) process - містить базові класи, необхідні для створення найпростішої СМО;

2) qusystem - містить класи, необхідні для створення більше складних СМО. Більшість класів цього пакета успадковують клас Actor пакета process;

3) regres - містить класи, необхідні для одержання різного роду залежностей;

4) testTheory - містить класи, необхідні для одержання перехідних процесів.

Нижче приводяться основні класи пакета process:

1) Actor - базовий клас для реалізації таких елементів СМО, як генератор й обслуговуючий прилад. Також може бути використаний при реалізації відносно простих специфічних елементів СМО шляхом спадкування цього класу. Метод rule цього класу задає правила дії елементів СМО;

2) Dіspatcher - клас диспетчера. Основна функція диспетчера - вести облік модельного часу й керувати роботою елементів СМО. Перед початком роботи елементи моделі, що успадковують клас Actor додаються в список акторів, що стартують, startLіst. Далі викликається метод start і диспетчер починає свою роботу.

Пакет qusystem містить наступні класи:

1) TransactіonsGenerator - генерує заявки на обслуговування й додає їх у вихідну чергу, що є екземпляром класу QueueForTransactіons. Генератор може працювати у двох режимах: у режимі генерації об'єктів при наявності вихідної черги й у режимі генерації подій, якщо вихідна черга не задана. Заявки створюються через випадкові проміжки часу, які залежать від настроювання внутрішнього генератора випадкових чисел;

2) QueueForTransactіons - черга заявок. Є вихідною чергою для генератора й вхідною для обслуговуючого приладу. Черга містить заявки, створені генератором заявок, які необхідно обробити обслуговуючому приладу. Є можливість встановлювати максимальний розмір черги а також виводити на діаграму графік зміни розміру черги із плином системного часу;

3) FіnіshDevіce - обслуговуючий прилад. Успадковує клас Actor. Правила дії обслуговуючого приладу описані в методі rule. Вони полягають у наступному: дочекатися, поки у вхідній черзі з'являться заявки, взяти заявку із вхідної черги, затриматися на час обслуговування заявки, взяти наступну заявку із вхідної черги.

Нижче приводяться основні класи пакета regres:

1) ExperimentControl - компонент, що дозволяє автоматизувати проведення однофакторних експериментів і регресійного аналізу. Досліджувана модель підключається до даного компонента й взаємодіє з ним за допомогою методів інтерфейсу IExperіmentable.

2) IExperіmentable - інтерфейс, що містить оголошення методів, необхідних для взаємодії компонента ExperimentControl і досліджуваної моделі. Для того, щоб компонент ExperimentControl міг працювати з моделлю, у класі моделі повинні бути реалізовані методи інтерфейсу IExperіmentable( getDіspatcher - одержати посилання на диспетчера досліджуваної моделі, setFactor - установити значення фактора, startExperіment - почати експеримент при новому значенні фактора, getResultOfExperiment - полуить результати експерименту при певнім значенні фактора).

Пакет transProcess містить наступні класи:

1) TransMonіtorVіew - візуальний компонент, призначений для завдання параметрів і проведення експериментів по виявленню закономірностей перехідного процесу. Досліджувана модель підключається до даного компонента й взаємодіє з ним за допомогою методів інтерфейсу ITransProcesable;

2) ParamFіnderVіew - візуальний компонент, призначених для пошуку параметрів перехідного процесу - тривалості й сталого значення. Пошук параметрів може виробляється як в автоматичному так й у ручному режимі;

3) TransProcessQueues - цей клас моделює черги, що мають здатність накопичувати інтеграл від свого розміру за часом. Із із допомога можна одержати середнє значення довгі черги протягом часу моделювання. Цей клас успадковує клас TransProcessQueues і містить додатково метод accum, що викликається перед зміною довгі черги й підраховує інтеграл;

4) ITransProcesable - інтерфейс, що містить оголошення методів, необхідних для взаємодії компонента TransMonіtorVіew і досліджуваної моделі. Для того, щоб компонент TransMonіtorVіew міг працювати з моделлю, у класі моделі повинні бути реалізовані методи інтерфейсу TransProcesable (clone - метод для створення необхідної кількості паралельно працюючих копій досліджуваної моделі, componentsToStart - метод додавання акторів у список акторів, що стартують, диспетчера, getResult - служить для одержання шуканого значення параметра моделі через певні проміжки системного часу, resetAccum - робить ініціалізацію накопичувача інформації, у ролі якого виступає екземпляр класу TransProcesQueues, setDіspatcher - служить для установки диспетчера для досліджуваної моделі). Перераховані вище класи істотно спрощують розробку моделей систем масового обслуговування й дозволяють скоротити час, витрачений на написання програми.

3. ПРОЕКТУВАННЯ ІНТЕРФЕЙСУ КОРИСТУВАЧА

Проектування будемо проводити, використовуючи засоби візуального проектування середовища Eclipse. Відповідний проект назвемо ambulance, пакет для класів та інтерфейсів, що будуть створені, назвемо ambulance_src, а сам клас візуальної частини назвемо Main. Для створення візуальної частини будемо використовувати не тільки стандартні компоненти Swing, але й компоненти фреймворку simulation. Тому імпортуємо цей фреймворк.

Відповідно до технічного завдання графічний інтерфейс користувача має забезпечити реалізацію таких функцій:

- налаштування параметрів моделі;

- проведення тестових запусків моделі з динамічною індикацією параметрів черг, та можливості виведення протоколу роботи моделі;

- перегляд статистичних характеристик;

- проведення багаторівневих експериментів та регресійний аналіз отриманих результатів;

- дослідження перехідного процесу.

3.1 Панель налаштувань параметрів системи, що досліджується та тестування моделі

У застосуванні передбачимо можливість налаштування таких параметрів ситеми, що досліджується:

- кількість машин міліції;

- кількість машин швидкої допомоги;

- ймовірність очікування міліції;

- ймовірність повернення;

- час моделювання;

- ймовірність повернення до лікарні;

- ймовірність повернення на станцію;

- закон розподілення для випадкової величини генератору викликів;

- закон розподілення для випадкової величини довжини шляху;

- закон розподілення для випадкової величини часу надання допомоги.

Визначимо характеристики компонентів візуальної частини, що забезпечують налаштування параметрів системи. Ці характеристики наведені у таблиці3.1.

Таблиця 3.1 - Характеристики компонентів візуальної частини, що забезпечують налаштування параметрів системи та тестування моделі

Параметр системи	Клас компоненту	Назва компоненту	Початкове значення
Тривалість моделювання	ChooseData	chooseData4	20
Кількість машин міліції	ChooseData	chooseData	5
Кількість машин швидкої допомоги	ChooseData	chooseData 1	5
Закон розподілення для випадкової величини генератору викликів	Choose Random	сhooseRandom	Експонеційний (m=1)
Закон розподілення для випадкової величини довжини шляху	Choose Random	сhooseRandom1	Експонеційний (m=1)
Закон розподілення для випадкової величини часу надання допомоги	Choose Random	сhooseRandom2	Експонеційний (m=1)
Ймовірність очікування міліції	ChooseData	chooseData2	0.5
Ймовірність повернення	ChooseData	chooseData3	0.5
Ймовірність повернення до лікарні	ChooseData	chooseDataTo Hospital	0.5
Ймовірність повернення на станцію	ChooseData	chooseData411	0.5

Відповідно до таблиці 3.1 у середовищі Eclipse створюємо візуальну композицію панелі налаштування параметрів системи. Зовнішній вигляд панелі наведено на рисунку 3.1.

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

- заявки на допомогу;

- черга машин швидкої допомоги;

- заявки на виклик міліції;

- черга машин міліції;

Рисунок 3.1- Панель налаштування параметрів системи та тестування моделі

3.2 Панель статистичної обробки результатів моделювання

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

Під час роботи моделі статистична інформація буде накопичуватися у відповідному об'єкті класу stat.Histo. Після завершення моделювання результати статистичної обробки можна вивести на екран у вигляді гістограм і тексту. Для цього у об'єктів класу stat.Histo є відповідні методи. Перелік компонентів панелі та їх характеристики наведено у таблиці 3.2.

Таблиця 3.2 - Характеристики компонентів панелі статистичної обробки результатів моделювання

Призначення компонента панелі	Клас компоненту	Назва компоненту	Початкове значення поля
Гістограма черги машин швидкої допомоги	paint. Diagram	diagram2	horisontalMaxText= 48 verticallMaxText=1
Відображення результатів експерименту	JTextArea	textArea1
Гістограма черги машин міліції	paint. Diagram	diagram21	horisontalMaxText= 48 verticallMaxText=1
Відображення результатів експерименту	JTextArea	textArea

На рисунку 3.2 представлено вигляд панелі для виведення статистичної обробки результатів моделювання. Компонент класу paint.Diagram призначений для відображення гістограми, а компонент типу JTextArea використовується для текстової інформації. Для зручності роботи з текстом панелі розташовані на компонентах JScrollPane.



Рисунок 3.2 - Панель статистичної обробки результатів моделювання

3.3 Панель проведення багаторівневих експериментів з моделлю

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

Зовнішній вигляд панелі представлено на рисунку 3.3.

Компонент класу paint.Diagram використовується для відображення результатів експериментів у вигляді точок. Автоматичне проведення серій експериментів забезпечуе компонент experimentControl класу experiment.controls.ExperimentControl фреймворку simulation. Він дозволяє дослідникові встановити потрібні значення фатору на рівнях і провести потрібну кількість експериментів для відповідних значень фактору.

Для проведення регресійного та дисперсійного аналізу отриманих експериментальних даних можна використовувати компонент regresAnaliser класу experiment.regres.RegresAnaliser фреймворку simulation. Він дозволяє дослідникові визначити, чи є суттєвим вплив фактору, вибрати функцію регресії для отриманих даних та перевірити її на адекватність. У разі проведення експериментів на одному рівні можна отримати параметри довірчого інтервалу. Перелік компонентів панелі та їх характеристики наведено у таблиці 3.3.

Таблиця 3.3 - Характеристики компонентів панелі статистичної обробки результатів моделювання

Призначення компонента панелі	Клас компоненту	Назва компоненту	Початкове значення поля
Автоматизація проведення експериментів	experiment. control. ExperimentControl	experiment Control	textFactors= 3 10 13 16 19 textNExpr=10 textTestTime=200
Відображення результатів експериментів	paint. Diagram	diagram3	horisontalMaxText=20 verticallMaxText= 20
Регресійний та дисперсійний аналіз	experiment. regres. RegresAnaliser	regresAnaliser
Вибір експеременту	RadioButton	jRadioButton	Selected = true
Вибір експеременту	RadioButton	jRadioButton1	Selected = false

Для нормальної роботи компоненту experimentControl його перш за все необхідно зв'язати з моделлю, яка реалізує інтерфейс IExperimentable.

Крім того компонент experimentControl слід зв'язати з компонентом класу paint.Diagram, на діаграмі якого результати експериментів будуть відображатися у вигляді точок.

Для нормального функціонування компонент regresAnaliser потребує підключення до джерела інформації яке реалізує інтерфейс IRegresable. Таким обєктом у нашому застосуванні є компонент experimentControl. Підключення можна виконати засобами візуального проектування.

Рисунок 3.3 - Панель проведення багаторівневих експериментів з моделлю

система масовий обслуговування

3.4 Панель дослідження перехідного процесу

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

Таблиця 3.4 - Характеристики компонентів панелі перехідного процесу

Призначення компонента панелі	Клас компоненту	Назва компоненту	Початкові значення
Автоматизація проведення експериментів	transProcess. TransMonotor	trans Monitor View	інтервал усереднення=20 кількість інтервалів=30 параллельно моделей=50
Відображення результатів експериментів	paint. Diagram	diagram4	horisontalMaxText=600 verticallMaxText=5

Зовнішній вигляд панелі представлено на рисунку 3.4.

Рисунок 3.4 - Панель дослідження перехідного процесу для зміни черги

Автоматизацію проведення експерименту забезпечує компонент transMonitor класу transProcess.TransMonitor фреймворку simulation. Він дозволяє дослідникові налаштувати параметри експерименту провести цей експеримент. Результати експерименту у вигляді середніх значень розміру черги у відповідні моменти часу відображаються на діаграмі.

Крім того компонент transMonitor слід зв'язати з компонентом diagram4 класу paint.Diagram, на діаграмі якого результати експериментів будуть відображатися у вигляді точок.

4. Проектування системи

4.1 Діаграмма класів

Проектування системи розпочнемо із створення діаграми класів.

Діаграма класів створена за допомогою пакету Enterprise Architect.

4.2 Проектування класів для об'єктів моделі

4.2.1 Клас Model

Центральним елементом діаграми є клас Model, що описує модель системи. Модель містить у собі посилання на всі компоненти, що моделюють об'єкти реальної системи, та допоміжні компоненти, що забезпечують динамічну індикацію стану системи та накопичення статистичної інформації. У класі визначені такі поля:

- queueOfCars - посилання на чергу машин швидкої допомоги;

- queueOfCalls - посилання на чергу дзвінків;

- queueOfPoliceCars - посилання на чергу машин міліції;

- queueOfPoliceCalls - посилання на чергу дзвінків до міліції;

- dispatcher - посилання на диспетчер;

- gui - посилання на интерфейс користувача;

- discretHisto - гистограмма для накопичення інформації;

- multiCar - посилання на об'єкт для створення декількох однакових экзеплярів класу Ambulance;

- multiPoliceCar - посилання на об'єкт для створення декількох однакових экзеплярів класу Police.

Модель містить у собі такі методи:

- getDispatcher() - отримати об'єкт типу Dispatcher;

- getGenerator() - отримати об'єкт типу Generator;

- getQueueOfCars() - отримати чергу машин швидкої допомоги;

- getQueueOfCalls() - отримати чергу дзвінків до швидкої допомоги;

- getQueueOfPoliceCars() - отримати чергу машин міліції;

- getQueueOfPoliceCalls() - отримати чергу дзвінків до міліції;

- initForTest() - ініцііалізація тесту моделі;

- initForStat() - ініціалізація тесту статистики;

- getMultiCar() - отримати об'єкт типу MultiActor;

- getMultiPoliceCar() - отримати об'єкт типу MultiActor;

- initForExperiment(double finishTime, double factor) - почати багаторівневий експеримент;

- getTransResult() - отримати результати перехідного процесу;

- initForTrans(double d) - почати есперимент перехідного процесу

Більшість методів get реалізує відкладене створення та ініціалізацію об'єктів і надає доступ до полів моделі, чим забезпечує зв'язок компонентів, що моделюють об'єкти реальної системи, з іншими об'єктами моделі та між собою.

4.2.2 Клас Ambulance

Клас Ambulabce описує поведінку машини швидкої допомоги.

У класі визначені такі поля:

- queueOfCars - посилання на чергу машин швидкої допомоги;

- queueOfCalls - посилання на чергу дзвінків;

- queueOfPoliceCalls - посилання на чергу дзвінків до міліції;

- gui - посилання на интерфейс користувача;

- model - посилання на модель.

Клас містить у собі такі методи:

- rule() - описує правила поведінки машини швидкої допомоги.

Текст метода rule() представлено нижче

protected void rule() {

IWaitCondition isCall = new IWaitCondition() {

public boolean testCondition() {

return queueOfCalls.size()>0;

}

public String toString() {

return ("ожидание вызова");

}

};

IWaitCondition policewait = new IWaitCondition() {

public boolean testCondition() {

return Ambulance.this.police;

}

public String toString() {

return ("ждет милицию");

}

};

while (true) {

queueOfCars.addLast(this);

gui.getHisto1().add(queueOfCars.size());

try {

waitForCondition(isCall);

} catch (DispatcherFinishException e) {

return;

}

queueOfCars.remove(this);

gui.getHisto1().add(queueOfCars.size());

queueOfCalls.removeFirst();

holdForTime(rndway.next());

if (getDispatcher().getCurrentTime() >= gui.getChooseDataTimeModel().getDouble()) {

return;

}

// приехали к больному

holdForTime(rndwait.next());

if(Math.random() < gui.getChooseDataTimeWaitPolice().getDouble()){

// вызвать милицию

queueOfPoliceCalls.addLast(this);

try {

waitForCondition(policewait);

} catch (DispatcherFinishException e) {

// TODO Auto-generated catch block

return;

}

}

if (Math.random()< gui.getChooseDataBackToHospital().getDouble()){

holdForTime(rndway.next());

}

if (Math.random()<gui.getChooseDataBackToStation().getDouble()){

holdForTime(rndway.next());

}

if (getDispatcher().getCurrentTime() >= gui.getChooseDataTimeModel().getDouble()) {

return;

}

}

}

4.2.3 Клас Police

Клас Police описує поведінку машини міліції.

У класі визначені такі поля:

- queueOfPoliceCars - посилання на чергу машин швидкої допомоги;

- queueOfPoliceCalls - посилання на чергу дзвінків до міліції;

- gui - посилання на интерфейс користувача;

- model - посилання на модель.

Клас містить у собі такі методи:

- rule() - описує правила поведінки машини міліції.

Текст метода rule() представлено нижче.

protected void rule() {

IWaitCondition isCallPolice = new IWaitCondition() {

public boolean testCondition() {

return queueOfPoliceCalls.size()>0;

}

public String toString() {

return ("ожидание вызова");

}

};

while (true) {

queueOfPoliceCars.addLast(this);

gui.getHisto11().add(queueOfPoliceCars.size());

try {

waitForCondition(isCallPolice);

} catch (DispatcherFinishException e) {

return;

}

queueOfPoliceCars.remove(this);

gui.getHisto11().add(queueOfPoliceCars.size());

Ambulance amb = (Ambulance) queueOfPoliceCalls.removeFirst();

// приехали к больному

holdForTime(rndway.next());

// оформили факт события

holdForTime(rndwait.next());

amb.setPolice();

//holdForTime(rndway.next());

if (getDispatcher().getCurrentTime() >= gui.getChooseDataTimeModel().getDouble()) {

return;

}

}

}

4.2.4 Клас Generator

Клас Generator використовується для формування заявоу до станції швидкої допомоги.

Клас містить у собі такі методи:

- rule() - описує правила виникнення заявки.

Текст метода rule() представлено нижче.

protected void rule() {

// TODO Auto-generated method stub

while(true){

holdForTime(rnd.next());

if (getDispatcher().getCurrentTime() >= finishtime) {

return;

}

queue.addLast(getDispatcher().getCurrentTime());

}

4.3 Режим тестування моделі

Тестування моделі на відповідність реальній системи проводилось за допомогою закладки застосування «Тест Моделі». Були проведені тестові запуски при різних налаштуваннях моделі. Аналіз отриманих діаграм підтвердив, що модель адекватно реагує на зміни налаштувань і її поведінка адекватно відображає процеси, які б могли відбуватися у реальній системі.

На рисунках 4.2 та 4.3 показані результати моделювання при різній кількості машин швидкої допомоги.

Налаштування моделі були такими, як показано у таблиці.

Таблиця 4.1 - Характеристики компонентів візуальної частини при виведенні протоколу роботи моделі

Параметр системи	Значення
Генератор вызовов	Експоненціальне(m=1.0)
Генератор длительности пути	Експоненціальне(m=1.0)
Генератор оказания помощи	Експоненціальне(m=1.0)
Кол-во машин милиции	5
Тривалість моделювання	20
Кількість машин скорой помощи	5
Вероятность ожидания милиции	0.5
Вероятность возвращения	0.5
Вероятность возврата в больницу	0.5
Вероятность возврата на станцию	0.5

Нижче на рисунку 4.2 наведено зображення вікна програми із зображенням результатів моделювання, що відповідають даним таблиці.



Рисунок 4.2 - Результати моделювання системи з 5 машинами швидкої допомоги



Рисунок 4.3 - Результати моделювання системи з 25 машинами швидкої допомоги та часом моделювання 200

4.4 Режим статистичних досліджень

Для тестування цього режиму було взято досить великий відрізок модельного часу, 10000 одиниць. Це дозволило великі об'єми вибірок і, відповіно достатньо виразні форми емпіричних розподілів. Повторні запуски моделі при таких налаштуваннях давали майже однакові результати.

Зовнішній вигляд панелі «Статистика» після проведення цього експерименту наведено на рисунку 4.4.

Рисунок 4.4 - Результати дослідження статистичних характеристик системи

4.5 Режим проведення багаторівневих експериментів з моделлю

У цьому режимі досліджувалася залежність черги машин швидкої допомоги та середній час чекання машини швидкої допомоги пацієнтом від кількості машин швидкої допомоги. Загальний вид отриманої залежності представлено на рисунку 4.5.

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

Рисунок 4.5 - Результати дослідження середньго значення черги від кількості машин швидкої допомоги

4.6 Режим дослідження перехідних процесів

На рисунку 4.6 представлені результати дослідження перехідного процесу для черги машин швидкої допомоги.

Рисунок 4.6 - Результати дослідження перехідного процесу

Висновки

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

Під час роботи над проектом були отримані практичні навички по проектуванню моделей систем масового обслуговування й збору статистичних даних про результати їхньої роботи. Таким чином, при багаторазовому запуску моделі з різними параметрами й аналізі статистичних даних можна настроїти модель на максимальну продуктивність.

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

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

Позитивним фактором при розробці проекту є досвід, отриманий при проектуванні систем масового обслуговування, і навички при объектно-оріентовному програмуванні.

Список використаних джерел

1. Буч Г. Объектно-ориентированное проектирование с примерами применения. К.: Вища школа, 1979.

2. Дослідження генераторів випадкових чисел. Методичні вказівки до лабораторного практикуму та самостійної роботи з дисципліни «Моделювання» для студентів напрямку підготовки 6.050201 - „Комп'ютерна інженерія”. /Укл.: Бивойно П.Г., Павловський В.І. - Чернігів: ЧДТУ, 2007. - 66 с. укр. мовою.

3. Кофман А., Крюон Р. Массовое обслуживание. Теория и приложения. М. Мир. 1965. - 354с.

4. Клейнрок Л. Теория массового обслуживания. М. Машиностроение 1979. - 423 с.

5. Методи дослідження імітаційних моделей. Методичні вказівки до лабораторного практикуму та самостійної роботи з дисципліни «Моделювання» для студентів напряму підготовки 6.050201 - «Комп'ютерна інженерія». Частина третя. /Укл.: Бивойно П.Г. , Зінченко А.Л., Павловський В.І. - Чернігів: ЧДТУ, 2008. - 78 с.

6. Моделювання паралельних процесів. Методичні вказівки до лабораторного практикуму та самостійної роботи з дисципліни «Моделювання» для студентів напряму підготовки 6.050201 - „Комп'ютерна інженерія”. Частина друга. /Укл.: Бивойно П.Г. , Зінченко О.Л., Павловський В.І. - Чернігів: ЧДТУ, 2008. - 66 с.

7. Прицкер А. Введение в имитационное моделирование и язык СЛАМ II: Пер. с англ. - М.:Мир, 1987. - 646с. ил.

8. Советов Б.Я., Яковлев С.А. Моделирование систем: Учебник для вузов. М.: Высш.шк., 1998. -320с.

9. Томашевський В.И. Моделювання систем. - К.: Видавнича група BHV, 2005. -352с.:іл.

Размещено на Allbest.ru

...