|
№ п/п
|
Найменування етапів дипломної роботи
|
Термін виконання етапів роботи
|
Примітки
|
|
Отримання завдання на дипломну роботу
|
01.11.10
|
|
|
Огляд існуючих рішень
|
20.02.11
|
|
|
Теоретичне дослідження основ теорії систем
масового обслуговування стосовно задач телекомунікації
|
13.03.11
|
|
|
Програмна частина (постановка задачі, створення
програмного забезпечення, опис алгоритму рішення задачі, проектування та опис
інтерфейсу користувача, опис програми)
|
28.04.11
|
|
|
Оформлення пояснювальної записки
|
05.05.10
|
|
|
Оформлення графічної документації
|
14.05.11
|
|
|
Оформлення електронних додатків до диплому
|
20.05.11
|
|
|
Представлення дипломної роботи до захисту
|
25.05.11
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Студент-дипломник _________________
(підпис)
Керівник роботи _________________
(підпис)
Анотація
Метою даної дипломної роботи є розробка системи, що дозволяє
побудувати модель та одержувати статистичні звіти про процеси в системах,
побудованих за принципом Triple Play.
Розроблена система може бути корисна інженерам, що займаються
розробкою та аналізом мереж Triple Play-сервісу.
Розділів 6, схем та рисунків 16, таблиць 5, бібліографічних
посилань 33, загальний обсяг - _______.
Зміст
Вступ
1. Постановка завдання
1.1 Найменування та галузь застосування
1.2 Підстава для створення
1.3 Характеристика розробленого програмного забезпечення
1.4 Мета й призначення
1.5 Загальні вимоги до розробки
2. Теоретичне дослідження основ теорії систем масового
обслуговування стосовно задач телекомунікації
2.1 Системи масового обслуговування та їхні характеристики
2.2 Базова модель СМО та теорія телетрафіку
2.3 Основні визначення теорії телетрафіку
2.4 Завдання аналізу і проектування телекомунікаційних мереж і
систем
2.5 Вимірювання трафіку
2.6 Моделі даних для опису телетрафіка
2.6.1 Моделі потоків подій
2.6.2 Нормальний розподіл
2.7 Генерування псевдовипадкових чисел
2.7.1 Математична модель лінійного конгруентного методу
2.7.2 Практична реалізація лінійного конгруентного методу в
стандартних бібліотеках різних компіляторів
3. Середовище delphі як засіб проектування інтерфейсу користувача
3.1 Загальні характеристики середовища Delphi
3.2 Високопродуктивний компілятор у машинний код
3.3 Delphі як об’єктно-орієнтована мова
3.4 Основні концепції створення додатків у середовищі Wіndows
3.5 Особливості написання програм у середовищі Delphі
3.6 Огляд палітри компонентів
4. Опис функціональних можливостей та програмної реалізації
проектованої системи
4.1 Предметна область і задачі, покладені на проектовану систему
4.2 Розробка блок-схеми моделі розподілу ресурсів
4.3 Математична модель системи
4.4 Розробка алгоритмів та програмна реалізація
4.5 Опис інтерфейсу користувача
5. Економічне обґрунтування доцільності розробки програмного
продукту
6. Охорона праці
6.1 Аналіз небезпечних й шкідливих виробничих факторів
6.2 Заходи щодо нормалізації небезпечних і шкідливих факторів
6.3 Пожежна безпека
Висновки
Список літератури
Вступ
Сьогодні є три основні масові
інформаційно-комунікаційно-розважальні сервіси: телефонія, телебачення і
інтернет-комунікації (умовно - передача даних). У минулому вони були розділені
технологічно і організаційно: кожен базувався на власній інфраструктурі і різні
послуги надавали, відповідно, різні оператори. Для користувача це виглядало як
телефонний дріт, телевізійний кабель та канал передачі даних. Сьогодні ж оператор
мультисервисної мережі, який забезпечує своїм абонентам широкосмугове
IР-підключення, здатний всі три найбільш масових і звичних сервіси надавати
одночасно через IР-канал. Цей спосіб надання послуг одержав назву Triple Play.
Оператор такої мультисервисної мережі не просто відтворює
старі послуги на новій технологічній базі, але і робить їх цікавішими, якісно
іншими і обов'язково розширює цей список новими послугами, які були відсутні в
традиційних мережах. Наприклад, разом з телепрограмами (відео) в IР - мережі
можна віщати і радіопрограми (аудіо), причому з будь-якою якістю, аж до
багатоканального Dolby Stereo Surround 5.1 Сьогодні в IР-мережі доступні і
вельми популярні мережеві комп'ютерні ігри, web-чати, всілякі інтернет-пейджери
(типу Skype і ICQ).
Технологічно використовувані IР-канали можуть бути різними,
головне, щоб вони забезпечували потрібну смугу пропускання і були керованими з
погляду якості: підтримували приорітизацію різних типів трафіку, різні рівні
обслуговування.
Метою даної дипломної роботи є розробка системи, що дозволяє
змоделювати і одержати статистичні звіти про процеси в системах, побудованих за
принципом Triple Play. Дослідження систем такого роду відноситься до завдань,
що вирішуються в одному з розділів теорії систем масового обслуговування,
званому теорією телетрафіка. Одним із способів дослідження є побудова
імітаційних моделей, які дозволяють одержати статистичні звіти про процеси в
системі.
Імітаційні моделі описують об'єкт дослідження деякою мовою,
імітуючи елементарні явища, з яких складається функціонування системи, зі
збереженням їхньої логічної структури, послідовності протікання у часі,
особливостей і складу інформації про стан процесу. Зазначимо про наявність
аналогії між дослідженням процесів методом імітаційного моделювання та їхнім
експериментальним дослідженням.
Описи компонентів реальної системи в імітаційній моделі мають
певний логіко-математичний характер і є сукупністю алгоритмів, які імітують
функціонування цієї системи. Програма моделі, побудована на основі цих
алгоритмів, дає змогу звести імітаційне моделювання до проведення експериментів
на ЕОМ шляхом їхнього "прогону" на деякій множині вхідних даних, які
імітують первинні події, що відбуваються в системі. Інформація, яка фіксується
у процесі дослідження імітаційної моделі, дає змогу визначити потрібні
показники, що характеризують ефективність системи, яку досліджують.
програма triple play delphi
1. Постановка
завдання
1.1
Найменування та галузь застосування
Найменування розробки: система моделювання розподілу ресурсів
в мережах сервісу Triple Play.
Розроблена система може бути корисна інженерам, що займаються
розробкою і аналізом мереж Triple Play-сервісу.
1.2 Підстава
для створення
Підставою для розробки є наказ № 55С-01 від 29 жовтня 2010 р.
по Криворізькому інституту КУЕІТУ.
Початок робіт: 01.11.10 Закінчення робіт: 25.05.11.
1.3
Характеристика розробленого програмного забезпечення
Система моделювання розподілу ресурсів в мережах сервісу
Triple Play була реалізована в середовищі Delphi.
Розроблене програмне забезпечення дозволяє побудувати модель
розподілу ресурсів в режимі реального часу, отримувати основні показники
ефективності досліджуваної системи і будувати графіки залежності на основі
статистичних даних. До складу системи входять:
· TriplePlay. exe - виконуємий файл системи;
· rezult. dat - файл записів, що зберігає
накопичувану статистичну інформацію;
· текстові файли, що можуть зберігати
інформацію про вхідні параметри системи.
1.4 Мета й
призначення
Метою даної дипломної роботи є розробка системи, що дозволяє
змоделювати і одержати статистичні звіти про процеси в системах, побудованих за
принципом Triple Play.
Система дозволяє будувати графіки залежності наступних типів:
· вірогідності блокування голосової заявки
від кількості серверів, призначених для обробки голосових заявок;
· середнього часу очікування відео-заявки в
черзі від кількості серверів, призначених для обробки відео-заявок;
· середнього часу очікування заявки типу
"данні" в черзі від загальної кількості серверів.
1.5 Загальні
вимоги до розробки
Вимоги до програмного забезпечення:
· Робота в середовищі операційних систем
Windows 2000/XP/7;
· Простота й зрозумілість інтерфейсу.
Мінімальні вимоги до апаратного забезпечення:
· IBM-сумісний комп'ютер, не нижче Pentium
IІ, RAM-128Mb, SVGA-800*600*16bit;
· Вільний простір на жорсткому диску не менш
2 Мб.
· Монітор, клавіатура, маніпулятор типу
"миша".
1.6
Джерела розробки
Джерелами розробки дипломної роботи є:
· довідкова література;
· наукова література;
· технічна література;
· програмна документація.
2. Теоретичне
дослідження основ теорії систем масового обслуговування стосовно задач
телекомунікації
2.1 Системи
масового обслуговування та їхні характеристики
Із системами масового обслуговування (СМО) ми зустрічаємось
повсякчас. Кожному з нас доводилось чекати обслуговування в черзі (у магазині,
на автозаправці, в бібліотеці, кав'ярні тощо). Аналогічні ситуації виникають,
коли треба скористатися телефонним зв'язком або виконати свою програму на
комп'ютері. Будь-яке виробництво теж можна уявити як послідовність систем
обслуговування. До типових систем обслуговування належать також ремонтні і
медичні служби, транспортні системи, аеропорти, вокзали тощо.
Особливого значення набули такі системи у процесах
інформатики. Це передусім комп'ютерні системи, мережі передавання інформації,
операційні системи, бази і банки даних. Системи обслуговування відіграють
значну роль у повсякденному житті. Досвід моделювання різних типів дискретних
систем свідчить про те. що приблизно 80% цих моделей ґрунтуються на СМО.
Систему масового обслуговування загалом можна уявити як
сукупність послідовно пов'язаних між собою вхідних потоків вимог на
обслуговування (потоків замовлень), черг, каналів обслуговування і потоків
обслужених замовлень. Будь-який пристрій, який безпосередньо обслуговує
замовлення, називають каналом обслуговування.
Системи масового обслуговування за наявності тої чи іншої
ознаки можна класифікувати так:
. За характером надходження замовлень у систему: на системи з
регулярним і випадковим потоками замовлень. Якщо кількість замовлень, які
надходять у систему за одиницю часу (інтенсивність потоку), стала або є заданою
функцією часу, то маємо систему з регулярним потоком замовлень, в іншому разі -
з випадковим. Випадковий потік замовлень може бути стаціонарним або
нестаціонарним. Якщо параметри потоку замовлень не залежать від розташування
інтервалу часу, який розглядають, на осі часу, то маємо стаціонарний потік
замовлень, в протилежному випадку - нестаціонарний. Наприклад, якщо кількість
покупців, які приходять до магазину, не залежить від часу доби, то потік
замовлень (покупців) - стаціонарний.
. За кількістю замовлень, які надходять за одиницю часу, на
системи з ординарним і неординарним потоками замовлень. Якщо ймовірність
надходження двох або більше замовлень в один момент часу дорівнює нулеві або
настільки мала, що нею можна знехтувати, то маємо систему з ординарним потоком
замовлень. Наприклад, потік літаків, які прибувають на злітну смугу аеродрому,
можна вважати ординарним, оскільки ймовірність надходження двох і більше
літаків до каналу обслуговування в один і той самий момент часу дуже мала.
. За зв'язком між замовленнями: на системи без післядії від
замовлень, які надійшли, і з післядією. Якщо ймовірність надходження замовлень у
систему в деякий момент часу не залежить від того, скільки вимог уже надійшло
до системи, тобто не залежить від передісторії процесу, який вивчають, то ми
маємо задачу без післядії, у протилежному випадку - з післядією. Прикладом
задачі з післядією може слугувати потік студентів на складання заліку
викладачеві.
. За характером поведінки замовлень у системі: з відмовами, з
обмеженим очікуванням і з очікуванням без обмеження: - якщо нове замовлення,
яке прибуло на обслуговування, застає усі канали обслуговування уже зайнятими і
покидає систему, то маємо систему з відмовами. Замовлення може покинути систему
і тоді, коли черга досягла певних розмірів. Якщо ракета супротивника
з'являється в час. коли всі протиракетні пристрої обслуговують інші ракети, то
вона без проблем залишає зону обслуговування;
якщо нове замовлення, яке прибуло на обслуговування, застає
усі канали обслуговування зайнятими і стає у чергу, але перебуває у ній
обмежений час і. не дочекавшись обслуговування, покидає систему, то маємо
систему з обмеженим очікуванням. Прикладом такого "нетерплячого"
замовлення може бути самоскид із цементним розчином. Якщо час очікування
великий, то щоб запобігти затвердненню розчину, він може бути розвантажений в
іншому місці;
якщо нове замовлення, яке прибуло на обслуговування, заставши
усі канали обслуговування зайнятими, змушене очікувати своєї черги до того
часу, поки не буде обслужене, то маємо систему з очікуванням без обмеження.
Приклад: літак, який перебуває на аеродромі до того часу, поки не звільниться злітна
смуга.
. За способом вибору замовлень на обслуговування: з
пріоритетом, за часом надходження, випадково, останнього обслуговують першим.
Іноді в такому випадку кажуть про дисципліну обслуговування:
якщо система масового обслуговування охоплює кілька категорій
замовлень і з певних міркувань необхідно дотримуватись різного підходу до
їхнього відбору, то маємо систему з пріоритетом. Зокрема, під час надходження
виробів на будмайданчик. перш за все монтують ті. які необхідні у цей момент;
якщо канал, який звільнився, обслуговує замовлення, яке
раніше за інших надійшло до системи, то маємо систему з обслуговуванням
замовлень за часом надходження. Це найпоширеніший клас систем. Наприклад,
покупця, який підійшов до продавця першим, обслуговують раніше за інших. Цей
спосіб вибору замовлень на обслуговування застосовують там. де внаслідок
технічних, технологічних або організаційних умов замовлення не можуть
випереджати одне одного;
якщо замовлення з черги надходять до каналу обслуговування у
випадковому порядку, то маємо систему з випадковим вибором замовлень на
обслуговування. Приклад: вибір слюсарем-сантехніком одного з декількох
замовлень на усунення несправностей, які надійшли від мешканців. Вибір тут.
зазвичай, визначають місцезнаходженням самого слюсаря: він надасть перевагу
замовленню мешканця, який перебуває від нього найближче, якщо інші чинники не
визначають вибору;
останнього обслуговують першим. Цей спосіб вибору вимог на
обслуговування використовують у тих випадках, коли зручніше й економніше брати
на обслуговування замовлення, яке найпізніше надійшло до системи. Зокрема, якщо
будівельні вироби складені один на одному, то зручніше спочатку брати виріб,
який надійшов останнім.
. За характером обслуговування замовлень: на системи з
детермінованим і випадковим часом обслуговування. Якщо інтервал часу між
моментами надходження замовлення до каналу обслуговування і моментом виходу
замовлення з цього каналу є сталим, то йдеться про систему з детермінованим
часом обслуговування, в іншому разі - з випадковим.
. За кількістю каналів обслуговування: на одноканальні і
багатоканальні системи. Наприклад, для зведення будинку можна використати один
будівельний кран (один канал обслуговування) або декілька (багато каналів) для
обслуговування виробів, які прибувають на будову. За кількістю етапів
обслуговування: на однофазні і багатофазні системи. Якщо канали обслуговування
розташовані послідовно, і вони неоднорідні, оскільки виконують різні операції
обслуговування, то йдеться про багатофазну систему масового обслуговування.
Прикладом такої системи може бути обслуговування автомобілів на станції
технічного обслуговування (миття, діагностування тощо). За однорідністю
замовлень, які надходять на обслуговування: на системи з однорідними і
неоднорідними потоками замовлень. Наприклад, якщо для розвантаження прибувають
фургони однакової вантажомісткості, то такі замовлення називають однорідними,
якщо різної - то неоднорідними.
. За кількістю етанів обслуговування: на однофазні і
багатофазні системи. Якщо канали обслуговування розташовані послідовно, і вони
неоднорідні, оскільки виконують різні операції обслуговування, то йдеться про
багатофазну систему масового обслуговування. Прикладом такої системи може бути
обслуговування автомобілів на станції технічного обслуговування (миття,
діагностування тощо).
. За однорідністю замовлень, які надходять на обслуговування:
на системи з однорідними і неоднорідними потоками замовлень. Наприклад, якщо
для розвантаження прибувають фургони однакової вантажомісткості, то такі
замовлення називають однорідними, якщо різної - то неоднорідними.
. За обмеженістю потоку замовлень: на замкнені і розімкнені
системи. Якщо потік замовлень обмежений і замовлення, які покинули систему,
через деякий час до неї повертаються, то маємо замкнену систему, в протилежному
випадку - розімкнеш.
Прикладом замкненої системи може слугувати бригада
робітників, які налагоджують станки в ткацькому цеху.
В задачах аналізу систем масового обслуговування в якості
основних показників функціонування системи можуть бути використані:
) ймовірність простою P0 каналу обслуговування;
) ймовірність того, що в системі знаходяться n вимог
(ймовірність Pn);
) середнє число вимог, що знаходяться в системі:
; (2.1)
) середнє число вимог, що знаходяться в черзі:
, (2.2)
де Nk - число каналів обслуговування.
) середній час очікування в черзі Tчерг. Для розімкнутої системи:
, (2.3)
де 
- це інтенсивність надходження
потоковимог в систему.
Для замкнутої системи:
, (2.4)
де m - число вимог, що потребують обслуговування.
) середній час очікування вимог в системі Tсист;
) середнє число вільних каналів обслуговування:
(2.5)
) середнє число зайнятих каналів обслуговування:
(2.6)
2.2 Базова
модель СМО та теорія телетрафіку
Базовими складовими, що визначають математичну модель СМО, є
описи вхідного потоку вимог і оброблювальних їх серверів. У загальному випадку,
вимога, що поступила в систему і застала всі сервери зайнятими, поміщається в
спеціальний накопичувач - чергу. Розмір цього накопичувача, що визначає
максимально можливу довжину черги, може бути різним. У граничних випадках він
може бути рівним нескінченності, тоді всі вимоги, що поступають, приймаються
системою, або рівним нулю, тоді всі вимоги, що поступили при зайнятих серверах,
будуть відкинуті системою, або, як прийнято говорити, заблоковані. У проміжному
випадку, при кінцевій максимальній довжині черги, частина вимог, що застали всі
сервери зайнятими, будуть поміщені у вільний простір накопичувача, і лише якщо
накопичувач виявиться повним, вимоги виявляться заблокованими.
Схему структуру СМО можна відобразити каскадним з'єднанням
накопичувача і пулу серверів (рис.2.1).
На вхід накопичувача поступає вхідний потік вимог,
математична модель якого задається.
Рис.2.1 Схематичне зображення системи масового обслуговування
Сервери СМО повинні бути описані за допомогою завдання
розподілу вірогідності довжини інтервалу часу, що витрачається на
обслуговування однієї вимоги. Таким чином, математична модель сервера - це
випадкова величина, що визначає час обробки вимоги (події).
Вимоги, що поступили при зайнятому сервері, накопичуються в
черзі. Кількість вимог в черзі постійно міняється, але якщо придивитися уважно,
то з часом воно може стати в середньому достатньо стійким. Причому, чим більше
буде інтенсивність потоку вимог на вході системи, тим більше число вимог
знаходитиметься в черзі. Це значить, що і все більший час вимога буде вимушена
знаходитися в накопичувачі, перш ніж поступить в сервер на обробку. Середній
час знаходження вимоги в системі є одним їх важливих показників роботи СМО.
Можна встановити співвідношення між середнім числом вимог в системі,
інтенсивністю вхідного потоку середнього часу перебування в системі.
2.3 Основні
визначення теорії телетрафіку
Науковою основою вимірювання і прогнозування якості роботи
телекомунікаційної мережі є теорія телетрафіка, яка виросла на ґрунті
традиційної телефонії і успадкувала з неї свою назву. Телетрафік - це поняття,
яке може бути визначене як рух повідомлень (інформаційних потоків). Теорія
телетрафіка - наукова дисципліна про закономірності і кількісний опис процесів
руху цих повідомлень в мережах і системах. Початок теорії телетрафіка йде від
робіт датського математика Агнера Ерланга, що дослідив статистичні
характеристики роботи телефонних мереж і опублікував в 1909 році свою
основоположну роботу "Теорія вірогідності і телефонія" (The Theory of
Probabilities and Telephone. Conversations). Оцифрування і інтелектуалізація
мереж зв'язку і особливо їх побудова на принципах комп'ютерних мереж зажадали
використання істотно нових методів аналізу роботи мереж, відсутніх в арсеналі
класичної теорії телетрафика. В той же час методи аналізу комп'ютерних мереж
розвивалися у напрямі оцінок продуктивності, а не звичних для зв'язківців
понять якості послуг зв'язку, і не могли бути застосовані безпосередньо при
оцінюванні транспортних послуг мережі зв'язку з комп'ютерною архітектурою.
Потреба в таких оцінках, а, інакше кажучи, необхідність розвитку теорії
телетрафіка стосовно комп'ютерних мереж зв'язку привела до появи цілого ряду
досліджень і супроводжуючих їх публікацій. Проте результати цих досліджень не
стали ще звичним підходом для інженерів, що проектують і експлуатують системи і
мережі зв'язку.
В процесі комунікації користувачів в мережі виникає потік
повідомлень - телетрафік або просто трафік, який може бути охарактеризований
кількісно. Очевидним параметром трафіку є його об'єм (traffic volume). Для
цифрових систем ця величина природним чином асоціюється з числом бітів,
переданих за заданий час. Проте для аналогових систем такий підхід виявляється
неприйнятним. Більш того, при використанні цифрових систем з складними
способами модуляції і кодування сигналів визначення об'єму трафіку стає
неоднозначним. Порівняємо нашу ситуацію з трафіком автомобільного руху на
дорозі. Ми говоримо про великий трафік, якщо автомобілі дуже щільно заповнюють
смуги руху, а кількість вантажу в них (аналогія переносимих бітів інформації) і
навіть число автомобілів не має при цьому великого значення. Приведена аналогія
дозволяє охарактеризувати об'єм трафіку як міру зайнятості простору для руху.
Роль такого простору для телетрафіка грає час, в межах якого доступний той або
інший ресурс мережі. Тому ми називатимемо об'ємом трафіку, пропущеного тим або
іншим ресурсом, величину сумарного, інтегрального інтервалу часу, протягом
якого даний ресурс був зайнятий за аналізований період часу. Іноді цю величину
називають роботою ресурсу за заданий час.
Одиницею роботи можна вважати секундозаняття ресурсу. Іноді
можна прочитати про годинозанятті, а деколи навіть просто про об'єм трафіку в
секундах або годинах. Проте рекомендації ITU (International Telecommunication
Union - Міжнародного союзу електрозв’язку) дають розмірність об'єму трафіку в
ерланго-годинах. Щоб зрозуміти сенс такої одиниці вимірювання, слід розглянути
ще один найважливіший кількісний параметр трафіку - інтенсивність трафіку
(traffic intensity). У вітчизняній літературі по телефонії можна прочитати про
цю величину як про інтенсивність навантаження. При цьому найчастіше говорять
про середню інтенсивність трафіку (навантаження) на деякому заданому пулі
(наборі) ресурсів, обслуговуючих трафік. Інтервал часу усереднювання також
звичайно задається. Якщо в кожен момент часу t із заданого інтервалу (t1,t2)
число зайнятих обслуговуванням трафіку ресурсів з даного набору рівне A (t), то
середня інтенсивність трафіку може бути оцінена як:
(2.7)
Величина інтенсивності трафіку характеризується як середнє число
ресурсів, зайнятих обслуговуванням трафіку на заданому інтервалі часу. Одиницею
вимірювання інтенсивності трафіку (навантаження) є один ерланг (1 Ерл, 1 Е). З
визначення інтенсивності ясно, що 1 ерланг - це така інтенсивність трафіку, яка
вимагає повної зайнятості одного ресурсу або, інакше кажучи, при якій ресурсом
виконується робота величиною в одне секундозаняття за час в одну секунду. При
цьому об'єм трафіку в одне секундозаняття займає одиницю ресурсу рівно на одну
секунду.
2.4 Завдання
аналізу і проектування телекомунікаційних мереж і систем
Перше завдання - завдання аналізу - виникає в тих випадках,
коли телекомунікаційна система вже побудована і функціонує. Цілями аналізу є
пошук реальних характеристик СМО, порівняння їх з проектними характеристиками,
надання об'єктивних оцінок якості роботи системи. У результаті аналіз дозволяє
визначити причини зниження якості обслуговування в порівнянні з проектними
характеристиками і видати рекомендації по усуненню цих причин. Іноді аналіз
потрібно провести після внесення змін в систему або після підключення нових
джерел навантаження.
Як найважливішу складову частину аналіз включає вироблення
розуміння всіх основних процесів, що відбуваються в системі. Зрозуміти -
означає зуміти в думках відтворити. Кількісні межі людського мислення
примушують відтворювати пізнавану суть не у всієї неї повноті, а в спрощеному,
схемному вигляді. Говорять, що мислення відтворює модель об'єкту. Модель за
своєю суттю - це абстракція, результат ігнорування, відкидання всього
неістотного з погляду того, що будує модель. У простому випадку, коли з якихось
причин не можна або невідомо від яких сторін об'єкту можна абстрагуватися,
використовують просту форму моделі - масштабну модель.
Це фізична модель, що має всі ті ж складові елементи, що і
об'єкт, але тільки менших розмірів. Наприклад, фізична модель
телекомунікаційної мережі може являти собою зібране в одній кімнаті мережеве
устаткування, сполучене між собою імітаторами каналів реальної мережі. Якщо
така модель дуже громіздка або дуже дорога, то фізична модель може бути
побудована на основі деякого типового фрагмента мережі і імітатора
навантаження, що поступає. Таку модель прийнято називати прототипом.
Що дозволяє робити прототип? За допомогою реальних
аналізаторів трафіку вимірюються характеристики мережі, вивчається вплив
параметрів устаткування і навантаження на характеристики якості і т.п. Як
правило, результати, одержані на прототипі, потрібно масштабувати для отримання
оцінок в реальній мережі. Таким чином, фізична модель містить в собі імітатори
трафіку, спрощене устаткування, аналізатори характеристик. Основним недоліком
фізичного моделювання, прототипування, зокрема, є дуже висока вартість робіт.
Іноді вимоги високої ідентичності моделі об'єкту критично важливі.
Наприклад, на Землі завжди є точна копія космічного апарату,
запущеного на орбіту. Така копія є фізичною моделлю, на якій відпрацьовуються
дії екіпажа при нештатних ситуаціях або з'ясовуються можливі причини відхилення
характеристик об'єкту від проектних. Але при щонайменшій нагоді відмовитися від
фізичного моделювання для пізнання властивостей об'єкту вигідніше будувати його
абстрактні математичні моделі. Вони можуть бути будь-якого рівня абстрагування,
від дуже грубих до вельми детальних. Але їх реалізація, як правило,
здійснюється у вигляді деякої комп'ютерної програми і тому істотно дешевше, ніж
фізична модель. Крім того, такі моделі надзвичайно зручні для внесення всіляких
змін, вимірювань, наочних уявлень (наприклад, візуалізація внутрішніх
процесів). Головне ж достоїнство математичних моделей систем полягає в тому, що
їх можна будувати задовго до побудови власне найреальнішої системи. Тим самим
математичні моделі утворюють основу для другої найважливішої задачі -
проектування телекомунікаційних мереж і систем.
2.5
Вимірювання трафіку
Спочатку розглянемо, як можна відображати роботу СМО, що має
декілька ресурсів, які одночасно обслуговують деякий трафік. Далі говоритимемо
про такі ресурси, як про сервери, які обслуговують потік заявок або вимог.
Одним з найбільш наочних способів, що часто вживається, зображення процесу
обслуговування заявок пулом серверів є діаграма Ганта. Ця діаграма є
прямокутною системою координат, вісь абсцис якої зображає час, а на осі ординат
позначаються дискретні точки, відповідні серверам пулу. Далі, кожен інтервал
часу, коли сервер зайнятий обслуговуванням заявки з вхідного потоку,
відмічається відрізком жирної горизонтальної прямої. На рис.2.2 зображена
діаграма Ганта для системи з трьома серверами.
Рис.2.2 Діаграма Ганта для системи з трьома серверами
У перші три інтервали часу (рахуватимемо їх для визначеності
секундою) зайняті перший і третій сервери, наступні дві секунди - тільки
третій, потім одну секунду працює тільки другий, потім, дві секунди другий і
перший, і останні дві секунди працює тільки перший.
Побудована діаграма дозволяє провести розрахунки об'єму
трафіку і його інтенсивності. Відразу відмітимо, що побудована діаграма Ганта
відображає тільки обслужений або пропущений трафік (traffic carried), оскільки
нічого не говорить про те, чи поступали в систему заявки, які не змогли бути
обслужені серверами. При побудові діаграми Ганта для трафіку (traffic offered),
що поступає, потрібно будувати горизонтальні відрізки, асоціюючи їх початки з
моментами надходження заявки, довжини - з необхідним часом обслуговування і
розташовуючи їх по осі ординат так, щоб такі відрізки не перетиналися. У
будь-якому випадку, об'єм трафіку обчислюється як сумарна довжина всіх відрізків
діаграми Ганта. Різниця між об'ємами трафіків, що поступають і пропущеного,
називається об'ємом надмірного трафіку (overflow traffic).
Рекомендації ITU Е.500 визначають для оцінки інтенсивності
трафіку в телефонних мережах інтервал часу усереднювання в 15 хвилин.
Вимірювання ведеться безперервно і постійно, накопичуючи набір даних у вигляді
послідовності чисел подібно до приведеного вище прикладу. Побудувавши графік
зміни інтенсивності трафіку (навантаження), можна визначити годинний інтервал,
коли інтенсивність була максимальною (сума чотирьох сусідніх значень є
найбільшою). Час, відповідний цьому інтервалу прийнято називати часом
найбільшого навантаження (ЧНН) або в англомовній литературе - busy hour.
Звичайно інтервал часу, відповідний ЧНН, повторюється кожну добу, наприклад, з
11 до 12 годин щодня.
Тепер приведемо декілька математичних визначень. Спочатку
визначимо число надходжень вимог на обслуговування. Позначимо це число п. Якщо
розділити це число на тривалість інтервалу моніторингу Т, то одержимо середнє
число надходжень вимог в одиницю часу, середню частоту надходжень або, як часто
її називають, середню інтенсивність потоку вимог. Цю величину прийнято
позначати:
(2.8)
Оскільки середня інтенсивність трафіку (позначимо її r) визначається як відношення сумарного
часу обслуговування до загального часу моніторингу, то в наших позначеннях
можна записати:
(2.9)
де 
- середня тривалість заняття
(обслуговування).
Таким чином, ми показали, що середня інтенсивність трафіку є
функцією тільки середнього числа надходжень вимог в одиницю часу і середньої
тривалості їх обслуговування.
Ця величина також називається середнім навантаженням і також
асоціюється з коефіцієнтом використання ресурсу (сервера).
Дійсно, як видно безпосередньо з діаграми Ганта, відношення S/T
можна інтерпретувати саме як відносну частку часу, коли сервер зайнятий роботою
по обслуговуванню вимог, що поступили. Якщо він витрачає на обслуговування
половину всього часу, то коефіцієнт використання природно вважати рівним 50%,
якщо взагалі не включався за час моніторингу, то коефіцієнт використання рівний
0. Якщо розбити весь час моніторингу на декілька частин і злічити коефіцієнт
використання для кожної з них, то можна відкласти ці значення по радіусах
одиничного круга, відповідних виділених інтервалах. Діаграма, що вийшла,
дозволяє в динаміці бачити, як використовується сервер. Такі діаграми носять
спеціальну назву - діаграми Кивіата).
Тепер звернемося до вимірювання трафіку в мережах, де повідомлення
представлені пакетами символів, які можуть мати різну довжину і передаватися
один за одним по каналах зв'язку, що сполучають між собою вузли мережі -
пристрої об'єднання, відгалуження і перенаправлення пакетів. Говоритимемо про
трафік між будь-якими елементами мережі, тобто фізичними або логічними
пристроями, що мають власну мережеву адресу, по сполучаючих їх каналах зв'язку.
Рис.2.3 Діаграма Кивіата для телефонної лінії
Можна вимірювати також витікаючий трафік з деякого мережевого
елементу незалежно від одержувача або вхідний трафік у вибраний мережевий
елемент, звідки б він не виходив. Вимірювання трафіку при цьому зводиться до
підрахунку числа пакетів, що проходять по вибраному шляху, і вимірюванню
довжини кожного з пакетів. Позначимо число пакетів, що пройшли за час Т
(секунд), буквою l, довжину i-го пакета - li, (бітів), а швидкість передачі
інформації по каналу - R (біт/с).
Тоді можна визначити середню за час Т інтенсивність трафіку на
даному інтерфейсі як відношення часу, зайнятого пакетами, до загального часу
вимірювання:
(2.10)
Одиницею вимірювання інтенсивності трафіку тут також є ерланг,
проте в практиці пакетних мереж часто оцінюють інтенсивність трафіку величиною:
, (2.11)
вимірюваної в бітах або байтах в секунду.
При постійній довжині пакету інтенсивність трафіку характеризують
просто кількістю пакетів в секунду. Іноді, навіть при змінній довжині пакетів,
обчислюють спочатку середню довжину пакету, а потім користуються описом
інтенсивності трафіку як числа пакетів в секунду. Приведені тут вживані на
практиці величини, що характеризують інтенсивність трафіку, завжди можуть бути
виражені в ерлангах, якщо розділити їх значення на швидкість передачі, і тому
не приводять до суперечностей при використанні. Тут же ми ще раз нагадаємо, що
інтенсивність трафіку вимірюється не тим, наскільки швидко переміщаються
пакети, а наскільки "щільно" вони рухаються. Якщо сказати, що
інтенсивність трафіку є 300 пакетів/с середньою довжиною 1000 біт, то для
мережі Ethernet, де швидкість передачі 10 Мбіт/с, це одне (А = 0,003 Ерл), а
для телефонного модему, що працює на швидкості 32 000 біт/с - зовсім інше (А =
0,9375 Ерл). У останньому випадку модем просто переобтяжений і затримки, що
виникають при передачі, будуть неприпустимими. Проте, міркуючи в рамках однієї
і тієї ж швидкості передачі, як міра інтенсивності трафіку цілком допустимо для
порівняння застосовувати величину I.
Як можна вимірювати інтенсивність трафіку в мережах передачі
пакетів? Очевидно, що для цього необхідно реєструвати час появи кожного пакету
і його довжину. Для проведення вимірювань такого роду існують спеціальні
прилади - аналізатори пакетів, які дозволяють виконувати набагато складніший
аналіз трафіку, чим вимірювання інтенсивності. Наприклад, аналізатори
протоколів серії RC-88/-100/-88WL/-100WL дозволяють визначати час доставки
пакетів вибраного типа протоколу, довжину пакету, виділяти помилкові пакети,
систематизувати одержану інформацію у вигляді графіків, таблиць і діаграм.
Можна застосовувати для вимірювань і звичайний комп'ютер, на який повинна бути
встановлена спеціальна програма - монітор мережі. Існує велика кількість різних
програм для моніторингу мережі, особливо для роботи під управлінням операційною
системою UNIX. Для комп'ютерів з ОС Windows таких моніторів істотно менше.
Одній з кращих можна рахувати програму Network Monitor компанії Microsoft.
2.6 Моделі
даних для опису телетрафіка
2.6.1 Моделі
потоків подій
Якщо подивитися на роздрук роботи монітора пакетної або
телефонної мережі, то можна побачити, що моменти часу надходження пакетів або
заняття ліній представляють деякий набір випадкових чисел. Ці числа утворюють
неубутну випадкову послідовність, яку прийнято називати випадковим потоком. Для
опису таких потоків можна використовувати або поняття розподілу кількості
подій, що доводяться на вибрані певним чином інтервали часу, або розподіл
інтервалу часу між сусідніми подіями. У першому випадку модель потоку дається
розподілом дискретної випадкової величини, а в другому - безперервної
випадкової величини.
Як випливає з сенсу понять, і в тому і в іншому випадку
йдеться про розподіл ненегативних величин. Говоритимемо, що нам вдалося знайти
задовільну модель потоку подій, якщо ми змогли написати програму, що видає
послідовно один за одним числа, які можуть бути інтерпретовані як моменти часу
настання подій, створюючих потік, еквівалентний модельованому. Поняття
еквівалентності реального потоку і модельного потоку подій істотно залежить від
завдання, для якого використовується модель. Ми вважатимемо модель
еквівалентною реальному потоку, якщо розраховані за допомогою модельного потоку
характеристики якості обслуговування СМО (час очікування, вірогідність
блокування і т.п.) будуть допустимо мало відрізнятися від характеристик
реальної системи.
При виборі моделі потоку іноді можуть допомогти апріорні
знання про його характерні властивості. Теорія випадкових потоків виділяє
наступні принципові властивості:
· стаціонарність - незалежність імовірнісних
характеристик від часу. Так вірогідність надходження певного числа подій в
інтервалі часу завдовжки t для стаціонарних потоків не залежить від вибору
початку його вимірювання;
· післядія - вірогідність надходження подій
в інтервалі (t1,t2) залежить від подій, що відбулися до моменту Dt
· ординарність - вірогідність надходження
двох і більш подій за нескінченно малий інтервал часу Dt є величина нескінченно
мала, вищого порядку малості, ніж Dt.
Найважливішими чисельними параметрами випадкового потоку є
інтенсивність потоку і параметр потоку. Для ординарних потоків вони
співпадають, а для неординарних, тобто для тих, в яких можуть одночасно
поступати декілька подій, ці величини розрізняються.
Інтенсивністю потоку називають математичне очікування числа
подій в одиницю часу в даний момент. Тобто це межа відношення середнього числа
подій на інтервалі Dt до довжини цього інтервалу, прагнучої до нуля:
(2.12)
Параметром потоку називають межу відношення вірогідності
надходження хоч би однієї події на інтервалі 
до довжини цього інтервалу, прагнучої до нуля:
(2.13)
Як випливає з останньої формули, вірогідність надходження хоч би
однієї події в заданому нескінченно малому інтервалі з точністю до нескінченно
малих вищого порядку, прямо пропорційна параметру потоку:
(2.14)
2.6.2
Нормальний розподіл
Випадкова величина X нормально розподілена з параметрами m і s > 0, якщо її
щільність розподілу Р (х) і функція розподілу F (x) мають відповідний вигляд
(рис.2.4):
, (2.15)
, (2.16)
де m - математичне
очікування, s 2 - дисперсія.
Рис.2.4 Функція щільності вірогідності і функція нормального
розподілу
Нормально розподілена випадкова величина може приймати
безперервний ряд значень від - ¥ до +¥. У теорії випадкових
потоків доводиться обмежувати значення позитивними величинами, вважаючи
значення функції щільності вірогідності нульовими на негативній піввісі. При
цьому доводиться вносити зміни у всі значення функції для ненегативних
аргументів так, щоб виконувалася умова нормування:
(2.17)
2.7
Генерування псевдовипадкових чисел
У основі моделювання потоку подій лежить генерування значень
дійсної (рідше за цілу) змінної, що має сенс поточного модельного часу, які
визначають моменти надходження вимог. Позначимо цю змінну ATIME. Найчастіше
генеруються не самі моменти, а інтервали часу між подією, що відбулася, і
надходженням наступної. Якщо позначити послідовність таких міжподієвих
інтервалів A1, A2, Ai, то на кожному кроці моделювання ATIME=ATIME + Ai.
Величина міжподієвого інтервалу є випадковою величиною і
генерується за допомогою спеціальних програмних функцій, званих датчиками
випадкових чисел. Прості датчики випадкових чисел генерують значення випадкової
величини, що має рівномірний розподіл в інтервалі (0, 1). Основна проблема
розробки таких програм полягає в необхідності забезпечити випадкові числа за
допомогою детермінованого процесу виконання. Реально такі програми генерують
псевдовипадкові числа. Якість послідовностей, випадкових чисел, що генеруються
датчиком, оцінюється близькістю до дійсно випадкових за допомогою багатьох
тестів. Як показав багаторічний досвід розробки, найбільш ефективними
алгоритмами роботи датчиків випадкових чисел є так звані конгруентні
генератори.
2.7.1
Математична модель лінійного конгруентного методу
У цей час найбільш популярними генераторами випадкових чисел
є генератори, у яких використається схема, запропонована Д.Г. Лехмером в 1949
році - лінійний конгруентний метод.
Виберемо чотири "чарівних числа":, модуль; 0 <
m;
а, множник; 0 < a < m;
с, приріст; 0 < с < m;, початкове значення; 0 < X0
< m.
Потім одержимо бажану послідовність випадкових чисел (Хn),
маючи на увазі:
+1 = (а* Xn+ с) mod m, n > 0. (2.18)
Ця послідовність називається лінійною конгруентною
послідовністю. Одержання залишків по модулю m почасти нагадує зумовленість,
коли кулька попадає в осередок колеса рулетки. Наприклад, для m = 10 й X0 = а =
с = 7 одержимо послідовність 7,6,9,0,7,6,9,0,.
Як показує цей приклад, така послідовність не може бути
"випадковою" при деяких наборах чисел m, а, з і Х0. У прикладі
ілюструється той факт, що конгруентна послідовність завжди утворить петлі,
тобто обов'язково існує цикл, що повторюється нескінченне число раз. Ця
властивість є загальною для всіх послідовностей виду Хn+1 = f (Хn), де f
перетворить кінцеву множину саме в себе.
Цикли, що повторюються, називаються періодами, довжина
періоду наведеної вище послідовності дорівнює 4. Безумовно, послідовності, які
ми будемо використовувати, мають відносно довгий період.
Заслуговує на увагу випадок, коли с = 0, тому що числа, що
генеруються, будуть мати менший період, чим при с ≠ 0. Ми переконаємося
надалі, що обмеження с = 0 зменшує довжину періоду послідовності, хоча при
цьому усе ще можливо зробити період досить довгим. В оригінальному методі,
запропонованому Д.Г. Лехмером, с вибиралося рівним нулю, хоча він і допускав
випадок, коли с ≠ 0, як один з можливих. Той факт, що умова с ≠ 0
може приводити до появи більше довгих періодів, був установлений В.Е. Томсоном
(W.Е. Thomson) і незалежно від нього А. Ротенбергом (А. Rotenberg).
Багато авторів називають лінійну конгруентну послідовність
при с = 0 мультиплікативним конгруентним методом, а при с ≠ 0 - змішаним
конгруентним методом. Для спрощення формул уводимо константу: b = а-1.
Можна відразу відкинути випадок, коли а = 1, при якому
послідовність Хn може бути представлена у вигляді Хn = (Х0 + с) mod m і
поводиться явно не як випадкова послідовність.
Випадок, коли а = 0 навіть гірше. Отже, для практичних цілей
припускаємо, що а>2, b>1.
Зараз можна узагальнити формулу (2.18):
(2.19)
де (n + k) - й член виражається безпосередньо через n-й.
Випадок, коли n = 0, у цьому рівнянні також вартий уваги. З
(2.19) можна зробити висновок, що підпослідовність, що містить кожний k-й член
послідовності Xn, є також лінійною конгруентною послідовністю, множник якої
дорівнює аk mod m і приріст дорівнює ( (аk - l) c/b) mod m. Важливим наслідком
з (2.19) є те, що загальна послідовність, визначена за допомогою а, с і Х0,
може бути дуже просто виражена в термінах спеціального випадку, коли с = 1 і
Х0= 0. Нехай:
= 0, Yn+1= (aYn + 1) mod m (2.20)
Відповідно до (2.19) одержимо Yk = (аk - 1) /b (по модулю m).
Виходить, послідовність, наведена в (2.18), буде мати вигляд
= (AYn + Х0) mod m, (2.21)
де A = (Х0b + с) mod m
2.7.2
Практична реалізація лінійного конгруентного методу в стандартних бібліотеках
різних компіляторів
Лінійний конгруентний метод застосовується в простих випадках
і не має криптографічну стійкість. Входить у стандартні бібліотеки різних
компіляторів.
При практичній реалізації лінійного конгруентного методу
вигідно вибирати m = 2e, де e - число біт у машинному слові, оскільки це
дозволяє позбутися від відносно повільної операції приведення по модулі.
Машинне слово - машиннозалежна й платформозалежна величина, вимірювана в бітах
або байтах, рівна розрядності регістрів процесора й/або розрядності шини даних.
У таблиці нижче наведені найбільш часто використовувані
параметри лінійних конгруентних генераторів, зокрема, у стандартних бібліотеках
різних компіляторів.
Таблиця 2.1
Параметри лінійних конгруентних генераторів
|
Компілятор
|
m
|
a
|
c
|
|
Numerical Recipes
|
232
|
1664525
|
1013904223
|
|
Borland C/C+ +
|
232
|
22695477
|
1
|
|
GNU Compiler Collection
|
232
|
69069
|
5
|
|
ANSI C: Open Watcom, Digital Mars, Metrowerks,
IBM VisualAge C/C+ +
|
232
|
1103515245
|
12345
|
|
Borland Delphi, Virtual Pascal
|
232
|
134775813
|
1
|
|
Microsoft Visual/Quick C/ C+ +
|
232
|
214013
|
2531011
|
|
Apple CarbonLib
|
231 - 1
|
16807
|
0
|
3. Середовище
delphі як засіб проектування інтерфейсу користувача
3.1 Загальні
характеристики середовища Delphi
Серед великої розмаїтості продуктів для розробки додатків
Delphі займає одне із провідних місць. Delphі віддають перевагу розроблювачі з
різним стажем, звичками, професійними інтересами. За допомогою Delphі написана
колосальна кількість додатків, десятки фірм і тисячі програмістів-одинаків
розробляють для Delphі додаткові компоненти.
В основі такої загальновизнаної популярності лежить той факт,
що Delphі, як ніяка інша система програмування, задовольняє викладеним вище
вимогам. Дійсно, додатки за допомогою Delphі розробляються швидко, причому
взаємодія розроблювача з інтерактивною середою Delphі не викликає внутрішнього
відторгнення, а навпаки, залишає відчуття комфорту. Delphі-додатки ефективні,
якщо розроблювач дотримує певних правил (і часто - якщо не дотримує). Ці
додатки надійні й при експлуатації мають передбачувану поведінку.
Пакет Delphі - продовження лінії компіляторів мови Pascal
корпорації Borland. Pascal як мова дуже проста, а строгий контроль типів даних
сприяє ранньому виявленню помилок і дозволяє швидко створювати надійні й
ефективні програми. Корпорація Borland постійно збагачувала мову. Колись у
версію 4.0 були включені засоби роздільної трансляції, пізніше, починаючи з
версії 5.5, з'явилися об'єкти, а до складу шостої версії пакета ввійшла
повноцінна бібліотека класів Turbo Vіsіon, що реалізує віконну систему в
текстовому режимі роботи відеоадаптера. Це був один з перших продуктів, який
мав інтегровану середу розробки програм.
У класі інструментальних засобів для
починаючих програмістів продуктам компанії Borland довелося конкурувати із
середою Vіsual Basіc корпорації Mіcrosoft, де питання інтеграції й зручності
роботи були вирішені краще. Коли на початку 70-х років Н. Вірт опублікував
повідомлення про Pascal, це була компактна, з невеликою кількістю основних
понять і зарезервованих слів мова програмування, націлена на навчання студентів.
Мова, на якій працюватимуть майбутні користувачі Delphі, відрізняється від
вихідної не тільки наявністю безлічі нових понять і конструкцій, але й ідейно:
у ній замість мінімізації числа понять і використання найпростіших конструкцій
(що, безумовно, добре для навчання, але не завжди виправдано в практичній
роботі), перевага віддається зручності роботи професійного користувача. Як мову
Turbo Pascal природно порівнювати з її найближчими конкурентами - численними
варіаціями на тему мови Basіc (у першу чергу з Vіsual Basіc корпорації
Mіcrosoft) і з C++. Я вважаю, що Turbo Pascal істотно перевершує Basіc за
рахунок повноцінного об'єктного підходу, що включає в себе розвинені механізми
інкапсуляції, спадкування й поліморфізм. Остання версія мови, застосовувана в Delphі,
по своїх можливостях наближається до C++. З основних механізмів, властивих C++,
відсутнє тільки множинне спадкування. (Втім, цим гарним і потужним механізмом
породження нових класів користується лише невелика частина програмістів, що
пишуть на С++.) Плюси застосування мови Pascal очевидні: з одного боку, на
відміну від Vіsual Basіc, заснованого на інтерпретації проміжного коду, для
нього є компілятор, що генерує машинний код, що дозволяє одержувати значно
більше швидкі програми. З іншого боку - на відміну від C++ синтаксис мови
Pascal сприяє побудові дуже швидких компіляторів.
Середа програмування нагадує пакет Vіsual
Basіc. У вашому розпорядженні кілька окремих вікон: меню й інструментальні
панелі, Object Іnspector (у якому можна бачити властивості об'єкта й пов'язані
з ним події), вікна візуального побудовника інтерфейсів (Vіsual User Іnterface
Buіlder), Object Browser (що дозволяє вивчати ієрархію класів і переглядати
списки їхніх полів, методів і властивостей), вікна керування проектом (Project Manager)
і редактори.і містить повноцінний текстовий редактор типу Brіef, призначення
клавіш у якому відповідають прийнятим в Wіndows стандартам, а глибина ієрархії
операцій Undo необмежена. Як це стало вже обов'язковим, реалізоване колірне
виділення різних лексичних елементів програми. Процес побудови додатка досить
простий. Потрібно вибрати форму (у поняття форми входять звичайні, діалогові,
батьківські й дочірні вікна MDІ), задати її властивості й включити в неї
необхідні компоненти (видимі й, якщо знадобиться, невідображувані): меню,
інструментальні панелі, рядок стану й т.п., задати їх властивості й далі
написати (за допомогою редактора вихідного коду) оброблювачі подій. Object
Browser Вікна типу Object Browser стали невід'ємною частиною систем програмування
на об’єктно-орієнтованих мовах. Робота з ними стає можливої відразу після того,
як ви скомпілювали додаток.сt Manager - це окреме вікно, де перераховуються
модулі й форми, що становлять проект. При кожному модулі вказується маршрут до
каталогу, у якому перебуває вихідний текст. Жирним шрифтом виділяються змінені,
але ще не збережені частини проекту. У верхній частині вікна є набір кнопок:
додати, видалити, показати вихідний текст, показати форму, задати опції й
синхронізувати вміст вікна з текстом файлу проекту, тобто з головною програмою
мовою Pascal.
Опції, включаючи режими компіляції,
задаються для всього проекту в цілому. Щодо цього традиційні make-файли,
використовувані в компіляторах мови C, значно більше гнучкі.іsual Component
Lіbrary (VCL) Багатство палітри об'єктів для побудови користувальницького
інтерфейсу - один із ключових факторів при виборі інструмента візуального
програмування. При цьому для користувача має значення як число елементів,
включених безпосередньо в середу, так і доступність елементів відповідного
формату на ринку.
3.2
Високопродуктивний компілятор у машинний код
Компілятори мови Pascal компанії Borland
ніколи не змушували користувача подовгу чекати результатів компіляції.
Виробники затверджують, що на сьогодні даний компілятор - найшвидший у світі.
Компілятор, убудований в Delphі дозволяє обробляти 120 тис. рядків вихідного
тексту у хвилину на машині 486/33 або 350 тис. - при використанні процесора
Pentіum/90. Він пропонує легкість розробки й швидкий час перевірки готового програмного
блоку, характерного для мов четвертого покоління (4GL) і в той же час
забезпечує якість коду, характерного для компілятора 3GL. Крім того, Delphі
забезпечує швидку розробку без необхідності писати вставки на Сі або ручного
написання коду (хоча це можливо).
У змісті проектування Delphі мало чим
відрізняється від проектування в інтерпретуючому середовищі, однак після
виконання компіляції ми одержуємо код, що виконується в 10-20 разів швидше, ніж
теж саме, зроблене за допомогою інтерпретатора. Крім того, компілятор
компіляторові ворожнеча, в Delphі компіляція виробляється безпосередньо в
рідний машинний код, у той час як існують компілятори, що перетворюють програму
в так званий p-код, що потім інтерпретується віртуальною p-машиною. Це не може
не позначитися на фактичній швидкодії готового додатка.
Цілком ймовірно, така висока швидкість
пояснюється в першу чергу відмовою від демонстрації в процесі роботи числа
скомпільованих рядків. Слід зазначити також, що завдяки опції оптимізації
сегментів вдається істотно скоротити розмір виконуваного файлу. Можна запустити
компілятор у режимі перевірки синтаксису. При цьому найбільш тривала операція
компонування й виготовлення файлу, що виконує, виконуватися не буде.
Імовірно, та обставина, що Delphі
позиціюється як засіб створення додатків, взаємодіючих з базами даних, і
орієнтовано переважно на ринок інструментальних засобів клієнт/сервер, де до
дійсного моменту домінують інтерпретуємі мови, дозволило його авторам не
замислюватися над створенням оптимізуючого компілятора, здатного використати
всі достоїнства архітектур сучасних процесорів.
3.3 Delphі як
об’єктно-орієнтована мова
Сумісність із програмами, створеними
раніше засобами Borland Pascal, зберігається, незважаючи на те, що в мову
внесені істотні зміни. Необхідність у деяких удосконаленнях давно відчувалася.
Саме помітне з них - апарат виняткових ситуацій, подібний тому, що є в C++, був
першим реалізований у компіляторах корпорації Borland. Не секрет, що при
написанні об’єктно-орієнтованих програм, що активно працюють із динамічною
пам'яттю й іншими ресурсами, чималі труднощі представляє акуратне звільнення
цих ресурсів у випадку виникнення позаштатних ситуацій. Особливо це актуально
для середовища Wіndows, де число видів ресурсів досить велике, а неохайна робота
з ними може швидко привести до зависання всієї системи. Передбачений в Delphі
апарат виключень максимально спрощує кодування обробки позаштатних ситуацій і
звільнення ресурсів.
Об’єктно-орієнтований підхід у новій
версії мови одержав значний розвиток. Перелічимо основні нововведення:
уведено поняття класу;
реалізовані методи класів, аналогічні
статичним методам C++. Вони оперують не екземпляром класу, а самим класом;
механізм інкапсуляції багато в чому
вдосконалений. Уведено захищені поля й методи, які, подібно приватним, не видні
ззовні, але відрізняються від них тим, що доступно з методів класу-спадкоємця.
уведена обробка виняткових ситуацій. В
Delphі це влаштовано в стилі С++.
Виключення представлені у вигляді
об'єктів, що містять специфічну інформацію про відповідну помилку (тип і
місцезнаходження помилки). Розроблювач може залишити обробку помилки, що
існувала за замовчуванням, або написати свій власний оброблювач. Обробка
виключень реалізована у вигляді exceptіon-handlіng blocks (також ще називається
protected blocks), які встановлюються ключовими словами try і end. Існують два
типи таких блоків: try. except і try. fіnally;з'явилося кілька зручних
синтаксичних конструкцій, у числі яких перетворення типу об'єкта з контролем
коректності (у випадку невдачі ініціюється виключення) і перевірка об'єкта на
приналежність класу;
посилання на класи надають додатковий
рівень гнучкості, так, коли ви хочете динамічно створювати об'єкти, чиї типи
можуть бути відомі тільки під час виконання коду. Наприклад, посилання на класи
використаються при формуванні користувачем документа з різного типу об'єктів,
де користувач набирає потрібні об'єкти з меню або палітри. Властиво, ця
технологія використалася й при побудові Delphі;
уведений засіб, відомий як механізм
делегування. Під делегуванням розуміється те, що якийсь об'єкт може надати
іншому об'єкту відповідати на деякі події. Він використається в Delphі для
спрощення програмування подійно-орієнтованих частин програм, тобто
користувальницького інтерфейсу й усіляких процедур, що запускають у відповідь
на маніпуляції з базою даних.
Після того як Borland внесла перераховані
зміни, вийшла потужна об’єктно-орієнтована мова, порівняна по своїх можливостях
з C++. Платою за нові функції стало значне підвищення вимог до професійної
підготовки програміста. Мова програмування Delphі базується на Borland Object
Pascal.
Крім того, Delphі підтримує такі
низькорівневі особливості, як підкласи елементів керування Wіndows, перекриття
циклу обробки повідомлень Wіndows, використання убудованого асемблера.
3.4 Основні
концепції створення додатків у середовищі Wіndows
MS Wіndows надає користувачам оболонку
графічного інтерфейсу (GUІ), що забезпечує стандартну середу користувача й
програміста. (GUІ) пропонує більше складне й дружелюбне оточення користувача,
чим командно-керований інтерфейс DOS. Робота в Wіndows заснована на інтуїтивно
зрозумілих принципах. Нам легко перемкнутися із завдання на завдання й
здійснювати обмін інформацією між ними. Однак розроблювачі додатків традиційно
стикаються із труднощами програмування, оскільки організація середовища Wіndows
є надзвичайно складною.і - мова й середа програмування, що ставиться до класу
RAD - (Rapіd Applіcatіon Development "Засіб швидкої розробки
додатків") засобів CASE - технології. Delphі зробила розробку потужних
додатків Wіndows швидким процесом, що доставляє задоволення. Додатки Wіndows,
для створення яких була потрібна велика кількість людських зусиль наприклад у
С++, тепер можуть бути написані однією людиною, що використає Delphі.
Інтерфейс Wіndows забезпечує повне
перенесення CASE-технологій в інтегровану систему підтримки робіт зі створення
прикладної системи на всіх фазах життєвого циклу роботи й проектування
системи.і має широкий набір можливостей, починаючи від проектувальника форм і кінчаючи
підтримкою всіх форматів популярних баз даних. Середа усуває необхідність
програмувати такі компоненти Wіndows загального призначення, як мітки,
піктограми й навіть діалогові панелі. Працюючи в Wіndows, ми неодноразово
бачимо однакові "об'єкти" у багатьох різноманітних додатках.
Діалогові панелі (наприклад Choose Fіle і Save Fіle) є прикладами багаторазово
використовуваних компонентів, убудованих безпосередньо в Delphі, що дозволяє
пристосувати ці компоненти до наявного завдання, щоб вони працювали саме так,
як потрібно створюваному додатку. Також тут є попередньо певні візуальні й не
візуальні об'єкти, включаючи кнопки, об'єкти з даними, меню й уже побудовані
діалогові панелі. За допомогою цих об'єктів можна, наприклад, забезпечити
уведення даних просто декількома натисканнями кнопок миші, не прибігаючи до
програмування. Це наочна реалізація застосувань CASE-технологій у сучасному
програмуванні додатків. Та частина, що безпосередньо пов'язана із
програмуванням інтерфейсу користувача системою одержала назву візуальне
програмування
Переваги проектування АРМ у середовищі
Wіndows за допомогою Delphі:
забезпечується погодженість проекту і його
реалізації;
збільшується продуктивність розробки й
інтегрованість програм.
Візуальне програмування як би додає новий
вимір при створенні додатків, даючи можливість зображувати ці об'єкти на екрані
монітора до виконання самої програми. Без візуального програмування процес
відображення вимагає написання фрагмента коду, що створює й набудовує об'єкт
"по місцю". Побачити закодовані об'єкти було можливо тільки в ході
виконання програми. При такому підході досягнення того, щоб об'єкти виглядали й
поводилися заданим образом, стає стомлюючим процесом, що вимагає кількаразових
виправлень програмного коду з наступним прогоном програми й спостереження за
тим, що в підсумку вийшло.
Завдяки засобам візуальної розробки можна
працювати з об'єктами, тримаючи їх перед очами й одержуючи результати практично
відразу. Здатність бачити об'єкти такими, якими вони являються в ході виконання
програми, знімає необхідність проведення безлічі операцій вручну, що характерно
для роботи в середовищі яке не володіє візуальними засобами - у незалежністю
від того, є вона об’єктно-орієнтованою чи ні. Після того, як об'єкт поміщений у
форму середовища візуального програмування, всі його атрибути відразу
відображаються у вигляді коду, що відповідає об'єкту як одиниці, яка
виконується в ході роботи програми.
Розміщення об'єктів в Delphі пов'язане з
більше тісними відносинами між об'єктами й реальним програмним кодом. Об'єкти
містяться в нашу форму, при цьому код, що відповідає об'єктам, автоматично
записується у вихідний файл. Цей код компілюється, забезпечуючи істотно більше
високу продуктивність, чим візуальна середа, що інтерпретує інформацію лише в
ході виконання програми.
3.5
Особливості написання програм у середовищі Delphі
Середа програмування Delphі - це
комбінація з декількох найважливіших технологій:
високопродуктивний компілятор;
об’єктно-орієнтована модель компонентів;
візуальна (а, отже, і швидкісна) побудова
додатків із програмних прототипів;
масштабовані засоби для побудови баз
даних.
Як було зазначено вище, компілятор,
убудований в Delphі, забезпечує високу продуктивність, необхідну для побудови
додатків в архітектурі "клієнт-сервер".
Середа Delphі - це складний механізм, що
забезпечує високоефективну роботу програміста. Візуально вона реалізується
декількома одночасно розкритими на екрані вікнами. Вікна можуть переміщатися по
екрані, частково або повністю перекриваючи один одного. Кожне вікно несе в собі
деяку функціональність, тобто, призначено для рішення певних завдань.
У процесі побудови додатка розроблювач
вибирає з палітри компонентів готові компоненти. Палітра компонентів - це
головне багатство Delphі. Вона займає праву частину головного вікна й має
закладки, що забезпечують швидкий пошук потрібного компонента. Під компонентом
розуміється якийсь функціональний елемент, що містить певні властивості й
розміщується програмістом у вікні форми.
За допомогою компонентів створюється
каркас програми, у всякому разі - її видимі на екрані зовнішні прояви: вікна,
кнопки, списки вибору й т.д.
Серед найбільш важливих особливостей
даного середовища програмування можна виділити наступні:
локальний сервер ІnterBase - варто
помітити, що цей інструмент призначений тільки для автономного налагодження
додатків. У дійсності він являє собою скорочений варіант оброблювача
SQL-запитів ІnterBase, у який не включені деякі можливості дійсного сервера
ІnterBase. Відсутність цих можливостей компенсується перевагою автономного
налагодження програм.Development Support - засіб підтримки розробки проекту в
групі. Дозволяє істотно полегшити керування великими проектами. Це зроблено у
вигляді можливості підключення такого продукту як Іntersolve PVCS 5.1
безпосередньо до середовища Delphі.
Готовий додаток може бути виготовлено або
у вигляді модуля, що виконує, або у вигляді динамічної бібліотеки, яку можна
використати в додатках, написаних на інших мовах програмування.
Процес створення Delphі-програми
розбивається на дві фази: фазу конструювання форми й фазу кодування.
Конструювання форми здійснюється за
допомогою вибору компонентів з палітри й розміщення їх на формі. Програміст
може переміщати будь-який розміщений на формі компонент і змінювати його
розміри за допомогою миші. Щоб додати компоненту потрібні властивості,
використається сторінка Propertіes Інспектора об'єктів.
Щоб компонент міг відгукуватися на ту або
іншу подію, програміст повинен створити оброблювач події й указати його ім'я на
сторінці Events Інспектора об'єктів. Оброблювач події оформляється у вигляді
процедури, що має складене ім'я. Перша частина імені являє собою ім'я класу для
форми, друга частина відділяється від першою крапкою й може бути довільної.
Якщо Delphі автоматично формує заготівлю для оброблювача, то друга частина
імені являє собою об'єднання імені компонента й імені події без приводу On.
Тіло процедури обмежене словами begіn. end
і складається з окремих пропозицій (операторів) мови Object Pascal. Наприкінці
кожної пропозиції ставиться крапка з комою. Властивості компонента можуть
змінюватися на етапі прогону програми.
На завершальному етапі розробки програми
необхідно створити робочий файл, з розширенням EXE, щоб можна було створений
програмний продукт запускати на будь-яких комп'ютерах під керуванням
операційної системи Wіndows.
3.6 Огляд
палітри компонентів
Основний упор цієї моделі в Delphі
робиться на максимальному повторному використанні коду. Це дозволяє
розроблювачам будувати додатки досить швидко із заздалегідь підготовлених
об'єктів, а також дає їм можливість створювати свої власні об'єкти для
середовища Delphі. Ніяких обмежень по типах об'єктів, які можуть створювати
розроблювачі, не існує. Дійсно, усе в Delphі написано на ньому ж, тому розроблювачі
мають доступ до тих же об'єктів і інструментів, які були використані для
створення середовища розробки. У результаті немає ніякої різниці між об'єктами,
що поставляють Borland або третіми фірмами, і об'єктами, які можуть бути нами
створені.
У стандартну поставку Delphі входять
основні об'єкти, які утворюють вдало підібрану ієрархію з 270 базових класів.
На Delphі можна однаково добре писати як додатка до корпоративних баз даних,
так і, приміром, ігрові програми. Багато в чому це пояснюється тим, що
традиційно в середовищі Wіndows було досить складно реалізовувати інтерфейс
користувача. Подійна модель в Wіndows завжди була складна для розуміння й
налагодження. Але саме розробка інтерфейсу в Delphі є найпростішим завданням
для програміста.
Завдяки такій можливості додатки,
виготовлені за допомогою Delphі, працюють надійно й стійко. Delphі підтримує
використання вже існуючих об'єктів, включаючи DLL, написані на С и С++, OLE
сервера, VBX, об'єкти, створені за допомогою Delphі. З готових компонентів працюючі
додатки збираються дуже швидко. Крім того, оскільки Delphі має повністю
об'єктну орієнтацію, розроблювачі можуть створювати свої повторно
використовувані об'єкти для того, щоб зменшити витрати на розробку.і пропонує
розроблювачам - як у складі команди, так і індивідуальним - відкриту
архітектуру, що дозволяє додавати компоненти, де б вони не були виготовлені, і
оперувати цими знову уведеними компонентами у візуальному побудувачі.
Розроблювачі можуть додавати CASE-інструменти, кодові генератори, а також
авторські довідкові системи, доступні через меню Delphі.
Палітра компонентів - це головне багатство Delphі. Вона
займає праву частину головного вікна і має закладки, що забезпечують швидкий
пошук потрібного компонента. Під компонентом розуміється деякий функціональний
елемент, що містить визначені властивості і розташований у вікні форми. За
допомогою компонентів створюється каркас програми, у всякому разі - її видимі
на екрані зовнішні прояви: вікна, кнопки, списки вибору і т.д. Як і панель
кнопок, палітра компонентів може набудовуватися. Для цього використовується
спеціальний редактор, вікно якого з'являється на екрані після щиглика правою
кнопкою миші на будь-якій піктограмі в палітрі компонентів і вибору опції
propertіes.
Сторінка Standard. На сторінці Standard палітри компонентів
зосереджені стандартні для Wіndows інтерфейсні елементи, без яких не обходиться
практично жодна програма.
- рама. Нарівні з формою служить контейнером для розміщення
інших компонентів. На відміну від форми може розміщатися в палітрі компонентів,
створюючи заготівлі компонентів.іnMenu - головне меню програми. Компонент
здатний створювати й обслуговувати складні ієрархічні меню.- допоміжне чи
локальне меню. Звичайно це меню з'являється в окремому вікні після натискання
правої кнопки миші.- мітка. Цей компонент використовується для розміщення у
вікні не дуже довгих однорядкових написів.іt - рядок уведення. Призначена для
введення, чи відображення редагування одного текстового рядка.- багаторядкового
текстовий редактор. Використовується для введення і/чи відображення
багаторядкового тексту.- командна кнопка. Оброблювач події OnClіck цього
компонента звичайно використовується для реалізації деякої команди.- незалежний
перемикач. Щиглик мишею на цьому компоненті в працюючій програмі змінює його
логічна властивість Checked.іoButton - залежний перемикач. Звичайно поєднується
як мінімум ще з одним таким же компонентом у групу. Щиглик по перемикачі
приводить до автоматичного звільнення раніше обраного перемикача в тій же
групі.іstBox - список вибору. Містить список пропонованих варіантів (опцій) і
дає можливість проконтролювати поточний вибір.- комбінований список вибору.
Являє собою комбінацію списку вибору і текстового редактора.- смуга керування.
Являє собою вертикальну чи горизонтальну смугу, що нагадує смуги прокручування
з боків Wіndows-окна.- група елементів. Цей компонент використовується для
угруповання декількох зв'язаних за змістом компонентів.іoGroup - група залежних
перемикачів. Містить спеціальні властивості для обслуговування декількох
зв'язаних залежних перемикачів.- панель. Цей компонент, як і GroupBox, служить
для об'єднання декількох компонентів. Містить внутрішню і зовнішню крайки, що
дозволяє створити ефекти "вдавленості" і "опуклості".іontіst
- список дій. Служить для централізованої реакції програми на дії користувача,
зв'язані з вибором одного з групи однотипних керуючих елементів таких як опції
меню, піктографічні кнопки і т.п. Уперше, введений у версії Delphі 4.
Сторінка Addіtonal. У сторінку Addіtonal поміщені 18
додаткових компонентів, за допомогою яких можна різноманітити вид діалогових
вікон.
іtBtn - командна кнопка з написом і піктограмою.-
піктографічна кнопка. Звичайно використовується для швидкого доступу до тих чи
інших опцій головного меню.іt - спеціальний текстовий редактор. Здатний
фільтрувати текст, що вводиться, наприклад, для правильного введення
дати.іngGrіd - таблиця рядків. Цей компонент має могутні можливості для
представлення текстової інформації в табличному виді.іd - довільна таблиця. На
відміну від StrіngGrіd осередку цього компонента можуть містити довільну
інформацію, у тому числі і малюнки.
Іmage - малюнок. Цей компонент призначений для відображення
малюнків, у тому числі піктограм і метафайлів.- фігура. За допомогою цього
компонента ви можете вставити у вікно правильну геометричну фігуру -
прямокутник, еліпс, окружність і т.п.- крайка. Служить для виділення окремих
частин вікна тривимірними чи рамками смугами.- панель зі смугами прокручування.
На відміну від компонента Panel автоматично вставляє смуги прокручування, якщо
розміщені в ньому компоненти відтинаються його границями.іstBox - список
множинного вибору. Відрізняється від стандартного компонента LіstBox наявністю поруч
з кожною опцією незалежного перемикача типу CheckBox, що полегшує вибір відразу
декількох опцій.іtter - границя. Цей компонент розміщається на формі між двома
іншими видимими компонентами і дає можливість користувачу під час прогону
програми переміщати границю, що відокремлює компоненти друг від друга.іcText -
статичний текст. Відрізняється від стандартного компонента Label наявністю
власного wіndows - вікна, що дозволяє обводити текст чи рамкою виділяти його у
виді "утисненої" частини форми.іcatіonEvents - одержувач події. Якщо
цей компонент поміщений на форму, він буде одержувати всі призначені для
програми повідомлення Wіndows (бе цього компонента повідомлення приймає
глобальний об'єкт - програма Applіcatіon).іstEdіtor - редактор рядків, що
містять пари ім'я = значення. Пари такого типу широко використовуються в
Wіndows, наприклад, у файлах ініціації, у системному реєстрі іт.п.іt -
комбінація однорядкового редактора і мітки.- спеціальний варіант ComboBox для
вибору одного із системних кольорів.- діаграма. Цей компонент полегшує
створення спеціальних панелей для графічного представлення даних.іonManager -
менеджер подій. Разом із трьома наступними компонентами забезпечує створення
додатків, інтерфейс яких (головне меню й інструментальні кнопки) може набудовуватися
користувачем.іonMaіnMenuBar - смуга меню, опції якого створюються за допомогою
компонента ActіonManager.іonToolBar - смуга для розміщення піктографічних
кнопок, створюваних за допомогою компонента ActіonManager.іzeDіg - діалог
настроювання. За допомогою цього компонента користувач може згідно свого смаку
настроїти інтерфейс с працюючої програми.
Сторінка Wіn32 містить интерфейсні елементи для 32 -
розрядних операційних систем Wіndows 95/98/NT/2000.
- набір закладок. Кожна закладка являє собою прямокутне поле
з написом і/чи малюнком. Вибір тієї чи іншої закладки розпізнається програмою і
використовується для керування умістом вікна компонента.- набір панелей із
закладками. Кожна панель може містити свій набір інтерфейсних елементів.
ІmageLіst - набір малюнків. Являє собою сховище для декількох
малюнків однакового розміру.іchEdіt - багаторядковий редактор форматованого
тексту. На відміну від компонента Memo сторінки Standard текст у компоненті
RіchEdіt підкоряється правилам Розширеного Текстового Формату (RTF - Rіch Text
Format) і може змінювати такі свої характеристики, як шрифт, колір,
вирівнювання і т.д.- регулятор. Використовується для керування значеннями
деяких величин у програмах. Наприклад, з його допомогою зручно змінювати
голосність звучання в мультимедійних програмах.- індикатор процесу. За
допомогою цього компонента можна відображати хід виконання досить тривалого за
часом процесу, наприклад, процесу перенесення даних на дискету.- цифровий
регулятор. Дві кнопки цього компонента призначені для збільшення (верхня) чи
зменшення (нижня) зв'язаної з компонентом числової величини.- керуюча клавіша.
Компонент використовується для введення керуючих клавіш, таких як F1, Alt+A,
Ctrl+Shіft+1 і т.п.іmate - мультиплікатор. Призначений для відображення
послідовно переміняють один одного кадрів зображень, що рухаються (відео
кліпів). Компонент не може супроводжувати відео кліп звуком.іmePіcker -
селектор часу/дати. Цей компонент призначений для введення і відображення чи
дати часу.іew - дерево вибору. Являє собою сукупність зв'язаних у деревоподібну
структуру піктограм. Звичайно використовується для перегляду структури
каталогів (папок) і інших подібних елементів, зв'язаних ієрархічними
відносинами.іstVіew - панель піктограм. Організує перегляд декількох піктограм
і вибір потрібної. Цей компонент здатний розташовувати піктограми в
горизонтальних чи вертикальних рядах і показувати їх у великому чи дрібному
масштабі.- керуючий заголовок. Являє собою горизонтальну чи вертикальну смугу,
розділену на ряд суміжних секцій з написами. Розміри секцій можна змінювати
мишею на етапі роботи програми. Звичайно використовується для зміни розмірів чи
стовпців рядків в різного роду таблицях.- панель статусу. Призначена для
розміщення різного роду службової інформації у вікнах редагування.-
інструментальна панель. Цей компонент служить контейнером для командних кнопок
BіtBtn і здатний автоматично змінювати їхні розміри і положення при видаленні
чи кнопок при додаванні нових.- інструментальна панель. На відміну від ToolBar
використовується як контейнер для розміщення.
РageScroller - панель, що прокручується. Служить для
розміщення вузьких інструментальних панелей. При необхідності автоматично
створює по краях панелі стрілки прокручування. Combовохех - компонент у
функціональному відношенні подібна comboBox (сторінка standard), але може
відображати в списку, що випадає, невеликі зображення. Сторінка System. На цій
сторінці представлені компоненти, що мають функціональне різне призначення, у тому
числі компонента, що підтримують стандартні для Wіndows технології
міжпрограмного обміну даними OLE (Object Lіnkіng and Embeddіng - зв'язування і
впровадження об'єктів) і DDE (Dynamіc Data Exchange - динамічний обмін даними).
іmer - таймер. Цей компонент служить для відліку інтервалів
реального часу.іntBox - вікно для малювання. Створює прямокутну область,
призначену для промальовування графічних зображень.іaPlayer - мультимедійний
програвач. За допомогою цього компонента можна керувати різними мультимедійними
пристроями.іner - OLE-контейнер. Служить приймачем що зв'язуються чи
впроваджуваних об'єктів.
Сторінка Dіalogs. Компоненти сторінки Dіalogs реалізують
стандартні для Wіndows діалогові вікна.
іalog - відкрити. Реалізує стандартне діалогове вікно
"Відкрити файл".іalog - зберегти. Реалізує стандартне діалогове вікно
"Зберегти файл".іctureDіalog - відкрити малюнок. Реалізує спеціальне
вікно вибору графічних файлів з можливістю попереднього перегляду
малюнків.іctureDіalog - зберегти малюнок. Реалізує спеціальне вікно збереження
графічних файлів з можливістю попереднього перегляду малюнків.іalog - шрифт.
Реалізує стандартне діалогове вікно вибору шрифту.іalog - колір. Реалізує
стандартне діалогове вікно вибору кольору.іntDіalog - печатка. Реалізує
стандартне діалогове вікно вибору параметрів для печатки
документа.іnterSetupDіalog - настроювання принтера. Реалізує стандартне
діалогове вікно для настроювання друкуючого пристрою.іndDіalog - пошук.
Реалізує стандартне діалогове вікно пошуку текстового фрагмента.іalog - заміна.
Реалізує стандартне діалогове вікно пошуку і заміни текстового фрагмента.
Сторінка Samples. Ця сторінка містить компоненти різного
призначення.
- індикатор стану. Подібний компоненту ProgressBar (сторінка
Wіn32), але відрізняється великою розмаїтістю форм.
СolorGrіd - таблиця кольору. Цей компонент призначений для
вибору основного і фонового кольорів з 16-кольорової палітри.іnButton -
подвійна кнопка. Дає зручний засіб керування деякою числовою величиною.іnEdіt -
редактор числа. Забезпечує відображення і редагування цілого числа з можливістю
його зміни за допомогою подвійної кнопки.іrectoryOutLіne - список каталогів.
Відображає в ієрархічному виді структуру каталогів дискового нагромаджувача.-
календар. Призначений для показу і вибору дня в місяці.
Сторінка Data Access. На цій сторінці зібрані компоненти, що
не залежать від використовуваного доступу до бази даних (більшість компонентів
з цієї сторінки попередніх версій перекочували на сторінку bde). Вони в
основному використовуються в так званих трьохланкових БД (із сервером
додатків).
Сторінка Data Controls.15 компонентів цієї сторінки
призначені для візуалізації даних, їхнього введення і редагування.
Сторінка dbExpress.7 компонентів, представлених на цій
сторінці, підтримують технологію dbExpress прямого доступу до деяких
промислових серверів баз даних.
Сторінка DataSnap. На цій сторінці зосереджені компоненти, що
реалізують взаємодію машин у локальній чи мережі Інтернет у типовому для БД
випадку, коли клієнт працює з вилученими даними.
Сторінка BDE. Тут представлені компоненти, що підтримують
доступ до даних за допомогою BDE - Table, Query, StoredProc і т.п. Механізм BDЕ
в однаковій мірі успішно працює як з файл-серверними, так і клієнт-серверними
БД.
Сторінка ADO. Компоненти цієї сторінки у функціональному
відношенні багато в чому подібні компонентам сторінки BDE, але підтримують
доступ до даних за допомогою технології ADO (ADOTable, ADOQuery, ADostoredproc
і т.д.).
Сторінка ІnterBase. "Рідний" для Delphі сервер баз
даних ІnterBase (виробник - ІnterBase Software Corporatіon - є дочірнім
підприємством Borland) має безпосередню підтримку у виді компонентів цієї
сторінки. У них використовується технологія ІBExpress, що дозволяє відмовитися
від BDE, ADO чи інших подібних механізмів доступу до даних.
4. Опис
функціональних можливостей та програмної реалізації проектованої системи
4.1 Предметна
область і задачі, покладені на проектовану систему
Розроблена в результаті виконання дипломної роботи система
дозволяє отримувати основні показники ефективності досліджуваної моделі,
накопичувати статистку досліджень та будувати графіки залежності на основі статистичних
даннях.
Система ілюструє особливості застосування теорії систем
масового обслуговування стосовно вирішення задач телекомунікації. Вона може
бути корисна інженерам, що займаються розробкою і аналізом мереж Triple
Play-сервісу.
4.2 Розробка
блок-схеми моделі розподілу ресурсів
Блок-схема моделі розподілу ресурсів в мережах сервісу Triple
Play наведена на рис.4.1.
У даній системі пропускна спроможність каналу розподіляється
між голосовими (voice), відео (video) заявками і заявками даних (data). Під
голосовими заявками маються на увазі запити на встановлення телефонного
зв'язку. Відео заявки є запитами на проглядання телебачення (IPTV) або
конкретних відеоматеріалів (VOD). Заявками на передачу даних вважаються пакети,
які передаються під час Інтернет-з'єднання.
Для обробки трафіку кожного типа виділяються задані
користувачем частини ресурсу. Частину ресурсу, виділену під той або інший тип
трафіку, називатимемо набором серверів, виділених для обробки цього виду
трафіку. Для кожного типу трафіку виділяється певне число серверів.
Рис. 4.1 Блок-схема моделі розподілу ресурсів в мережах
сервісу Triple Play
Принцип розподілу серверів для обробки заявок наступний.
Після того, як голосова трансакція згенерована, перевіряється наявність вільних
серверів для голосового трафіку. Якщо такі сервера виявлені, трансакція
поступає на обробку. Якщо ж всі сервера виявляються зайнятими, то відбувається
перевірка на наявність серверів, відведених для голосового трафіку, але зайнятих
обробкою трансакції даних.
Якщо сервер, що задовольняє цій умові, знайдений, то заявка
типу "дані”, що знаходиться на обробці, витісняється в чергу і голосова
трансакція поступає на обробку в сервер, що звільнився. Інакше голосова заявка
блокується.
Поведінка відео заявок аналогічна поведінці голосових
трансакцій за винятком того, що за відсутності вільних або зайнятих даними
відео-серверів заявка не блокується, а поступає в чергу.
Заявки типу "дані” при зайнятості всіх наданих їм
серверів перевіряють на зайнятість сервера, виділені для голосового і
відео-трафіку. Якщо серед них є вільні, то заявка встає на обслуговування.
Проте вона буде витиснена звідти у разі надходження голосової або відео-заявки,
відповідної типу зайнятого сервера, оскільки останні мають вищий пріоритет.
4.3
Математична модель системи
Трансакції (заявки) всіх трьох типів генеруються з середнім
інтервалом між надходженнями, розподіленим по експоненціальному закону, як
найбільш наближеному до реального. Таким чином, вхідний потік заявок описується
наступною формулою:
(4.1)
де m - середнє
значення (математичне очікування);
s2 - дисперсія.
Дисперсія випадкової величини - це міра розкиду даної випадкової
величини, тобто її відхилення від математичного очікування.
З цієї ж причини час обслуговування всіх типів трансакцій
серверами розподілений також по експоненціальному закону.
Кожному типу трансакцій відповідають свій середній час обробки і
середній інтервал між надходженнями заявок.
Середній час обробки заявки сервером в моделі задається змінними
voice_x, video_x і data_x. Для голосових трансакцій значення voice_x за
умовчанням рівно 98 секунд. Це середня тривалість заняття аналогової
абонентської лінії індивідуального користування у години найбільшого навантаження
згідно нормативних документів (РД 45.120-2000). Середнє значення часу
обслуговування відео-заявок за умовчанням рівне 13620 секунд (оскільки за
статистичними даними TNS Gallup Media телеглядач дивиться телевізор в день 227
хвилин або 13620 секунд) і заявок даних рівно 100 секунд (ця величина була
одержана на основі статистичних досліджень мереж передачі даних - аналізу
трафіку в локальній мережі, передачу даних через Інтернет). Проте всі ці
параметри можуть бути задані користувачем.
Середній інтервал між надходженнями заявок в моделі відповідає
змінним voice_t, video_t і data_t. Значення цих параметрів визначаються по
формулі:
, (4.2)
де: 
- середній час обробки заявки
відповідного типа сервером;
- середнє завантаження серверів, %;
Значення величин і задаються користувачем.
.4 Розробка
алгоритмів та програмна реалізація
Наведемо перелік змінних, що використовуються в розробленій
системі._x, video_x, data_x: integer; // середній час обробки відповідно
голосових, відео та типу "данні" заявок._t, video_t,data_t: real; //
середній час між трансакціями відповідних типів заявок._of_DS, Num_of_VoS,
Num_of_ViS: integer; // кількість серверів, що призначені для обробки._s_zagr,
video_s_zagr,data_s_zagr: integer; // середнє завантаження серверів._voice, int_video,
int_data: real; // згенеровані випадковим чином інтервали між надходженням
заявок._obr_vioce, int_obr_video, int_obr_data: real; // згенерований
випадковим чином час обробки відповідно голосових, відео та типу
"данні" заявок._tranz: integer; // загальна кількість транзакцій, яка
пройде через систему за цикл моделювання_tranz: integer; // лічильних кількості
трансакцій._voice,ms_video,ms_data: word; // лічильники мілісекунд - часу між
трансакціями._obr_voice,ms_obr_video,ms_obr_data: word; // лічильники
мілісекунд - часу обробки заявок._vo: array [1.1000] of TTimer; // масив
таймерів, що відповідають за обробку голосових заявок._vi: array [1.1000] of
TTimer; // масив таймерів, що відповідають за обробку відео-заявок._d: array
[1.1000] of TTimer; // масив таймерів, що відповідають за обробку заявок типу
"данні”._s,vi_s,d_s: array [1.1000] of integer; // масиви, що призначені
для визначення стану сервера (0 - ще не використовувався, 1 - зайнятий обробкою
заявки власного типу, 2 - зайнятий обробкою заявки типу "данні”, 3 -
звільнився._vo,z_vi,z_d: array [1.10000] of integer; // масив, в якому
зберігається номер таймеру, призначеного для обробки відповідної заявки.:
boolean; // ознака того, що процес моделювання
завершений._tranz_vo,n_tranz_vi,n_tranz_da: integer; // кількість виконаних
заявок відповідного типу._tranz_vo_p,n_tranz_vi_p,n_tranz_da_p: integer; //
кількість заявок, що надійшли.: real; // коефіцієнт масштабування часу.:
integer; // кількість відмов для заявок голосового типу._vid_o: array, timers_data_o
[1.1000] of TTimer; // масиви таймерів для обслуговування черги відео-заявок та
заявок типу "данні”._och_v,vremya_och_d: array [1.1000] of real; // час,
який відповідна заявка проводить у черзі._obsl_v,vremya_obsl_d: array [1.1000]
of real; // час, який відповідна заявка знаходилася на
обслуговуванні._vo,zagr_vi,zagr_da: real; // поточний процент завантаження
серверів._och_vi,kol_och_da: integer; // кількість заявок, що знаходяться в
черзі._vobr_vi,kol_vobr_vo,kol_vobr_da: integer; // кількість заявок, що
знаходяться в обробці_vi,data_vo: array [1.1000] of boolean; // ознака того, що
сервер зайнятий обробкою заявки типу "данні”._s_vo_d,kol_s_vi_d: integer;
// кількість серверів, призначених для обробки голосових та відео-заявок, що
обробляють заявки типу "данні”._v_och: boolean; // ознака того, що обробка
сервером заявки типу "данні" перервана._data_vo: real; // час обробки
серверами, призначеними для обробки голосових заявок заявок типу
"данні”._data_vi: real; // час обробки серверами, призначеними для обробки
відео-заявок заявок типу "данні”.
В розробленій системі передбачена можливість зберігати
початкові данні, що задаються користувачем в зовнішньому текстовому файлі.
Також, при необхідності, збережені данні можна завантажити. За замовченням файл
зберігається в тому ж каталозі, що і TriplyPlay. exe.Tmain. FormShow (Sender:
TObject);
// установлення директорії за замовченням для
компонентів-діалогів. InitialDir: =ExtractFilePath (Application. ExeName);.
InitialDir: =ExtractFilePath (Application. ExeName);;
Наведемо процедуру, що дозволяє завантажити данні.Tmain.
N2Click (Sender: TObject);i,k: integer;OpenDialog1 doExecute then // якщо
діалог відкриття фалу виконаний
// використовуємо допоміжний компонент Memo, в який
завантажуються строки з файлу. Clear;. Lines. LoadFromFile (filename); //
завантаження інформаціїї; k: =0;i: =0 to main.componentCount-1 do //
перебираємо усі компоненти формиComponents [i]. ClassNameIs ('TEdit') then //
якщо компонент класу Edit
(Components [i] as TEdit). text: =Memo1. Lines [ (Components
[i] as TEdit). Tag];;
Далі наведена процедура, яка відбувається при натисненні
кнопки "Моделювання”.Tmain. BitBtn1Click (Sender: TObject);a: real; i:
integer;
. // ініціалізуємо змінні
// середній час обробки заявок_x: =strtoint (Edit4. Text);_x:
=strtoint (Edit9. Text);_x: =strtoint (Edit14. Text);
// кількість серверів_of_DS: =strtoint (Edit15.
Text);_of_VoS: =strtoint (Edit5. Text);_of_ViS: =strtoint (Edit10. Text);
// середнє завантаження серверів_s_zagr: =strtoint (Edit2.
Text);_s_zagr: =strtoint (Edit7. Text);_s_zagr: =strtoint (Edit12. Text);
// обчислюємо середній інтервал між надходженнями заявок_t: =
(voice_x*100) / (voice_s_zagr);_t: =video_x*100/ (video_s_zagr);_t:
=data_x*100/ (data_s_zagr);
// генеруємо початкові інтервали, приймаючи до уваги часовий
коефіцієнт масштабування_voice: = round (abs (randg (voice_t,sqrt (voice_t))
/mashtab) *1000);_video: = round (abs (randg (video_t,sqrt (video_t)) /mashtab)
*1000);_data: = round (abs (randg (data_t,sqrt (data_t)) /mashtab) *1000);
// далі викликаємо процедури, що відповідають генеруванню
заявокTimer (sender); // голосові заявкиTimer (sender); // відео-заявкиTimer
(sender); // заявки типу "данні”
На рис.4.2 наведений алгоритм процедури генерування голосових
заявок.
Рис. 4.2 Алгоритм процедури генерування голосових заявок
Наведемо фрагмент програмного коду, що реалізує цей алгоритм.
Tmain. Timer2Timer (Sender: TObject);i: integer; flag:
boolean; // ознака того, що заявка прийнята: integer; // кількість зайнятих
серверівfinita then // кількість трансакцій, задана користувачем вже
згенерована
// перебираємо в циклі та виключаємо усі таймери, що
призначені для обробки заявокi: =1 to 1000 do_vo [i]. Enabled: =false;_vi [i].
Enabled: =false;_d [i]. Enabled: =false;_vid_o [i]. Enabled: =false;_data_o
[i]. Enabled: =false;;. Enabled: =false; // зупиняємо процес генерації заявок;
// вихід із процедури;_voice: =ms_voice+10; // лічильник мілісекунд для таймера
голосових трансакційms_voice>=int_voice then // якщо інтервал між
трансакціями закінчився -
відбувається генерація наступноїTimer2. Enabled:
=false;_voice: =0; // лічильник мілісекунд між трансакціями_voice: = round (abs
(randg (voice_t,sqrt (voice_t)) /mashtab) *1000);: =false; // ознака того, що
вільний сервер не знайдено
Далі перебираємо сервера, виділені для обробки голосових
заявок. Ознаки наступні: 0 - сервер ще не використовувався; 1 - сервер зайнятий
обробкою голосових заявок; 2 - сервер зайнятий обробкою заявок типу
"данні”; 3 - сервер звільнився.
i: =1 to Num_of_VoS dovo_s [i] =0 then // якщо сервер ще не
використовувався_s [i]: =1; // сервер зайнятий: =a+1;_vo [a]: =i; // номер
таймеру, що буде використовуватися_vo [z_vo [a]]: =ttimer. create (nil); //
створюємо новий таймер_vo [z_vo [a]]. Interval: =10; // встановлюємо
інтервал_vo [z_vo [a]]. Enabled: =true; // запускаємо таймер
// генеруємо випадкову величину - час обробки
заявки_obr_vioce: =round (abs (randg (voice_x,sqrt (voice_x)) /mashtab)
*1000);_obr_voice: =0; // лічильник мілісекунд обробки заявки
// запускаємо процедуру обробки заявки_vo [z_vo [a]].
OnTimer: =tomer_voiceTimer;: =true; // заявка прийнята в обробку, сервер
зайнятий; // вихід із циклу;vo_s [i] =3 then // якщо сервер звільнився -
відбувається теж саме, що і в попередньому випадку, окрім створення серверу_s
[i]: =1; // сервер зайнятий: =a+1; z_vo [a]: =i;_vo [z_vo [a]]. Enabled:
=true;_obr_vioce: =round (abs (randg (voice_x,sqrt (voice_x)) /mashtab)
*1000);_obr_voice: =0;_vo [z_vo [a]]. OnTimer: =tomer_voiceTimer;: =true; //
заявка прийнята в обробку, сервер зайнятий;;
// Якщо сервер зайнятий обробкою заявки типу "данні”, що
має нижчий пріоритетvo_s [i] =2 then_s [i]: =1; // сервер зайнятий_data:
=0;_vo: =i;_v_och: =true; // ознака того, що заявка data буде витиснена в
чергу_vo [z_vo]. Enabled: =false;_obr_vioce: =round (abs (randg (voice_x,sqrt
(voice_x))) /mashtab*1000);_obr_voice: =0;_vo [z_vo]. OnTimer:
=tomer_voiceTimer;: =true; // заявка прийнята в обробку, сервер зайнятий_vo
[z_vo]: =false; // ознака того, що сервер обробляє заявки типу "данні”_vo
[z_vo]. Enabled: =true;;;;not flag then otkaz: =otkaz+1; // кількість заявок,
які були заблоковані
Далі відбувається розрахунок навантаження серверів обробки
голосових заявок.
_vobr_vo: =0; // кількість заявок, що знаходяться в обробціi:
=1 to Num_of_VoS dovo_s [i] =1kol_vobr_vo: =kol_vobr_vo+1; // кількість
серверів, що обробляють голосові заявки_s_vo_d: =0; // кількість серверів, що
зайняті обробкою заявок типу "данні”i: =1 to Num_of_VoS dovo_s [i] =2kol_s_vo_d:
=kol_s_vo_d+1;
// Обчислення відсотка завантаження сервера обробки голосових
заявок_vo: = (kol_s_vo_d+kol_vobr_vo) *100/Num_of_VoS;
// Лічильники загальної кількості трансакцій і голосових
заявок_tranz: =n_tranz+1;_tranz_vo_p: =n_tranz_vo_p+1;n_tranz>=kol_tranz
then finita: =true;. Enabled: =true;;;
Розглянемо процедуру обробки голосових заявок. Алгоритм
процедури наведений на рис.4.3.
Tmain. timer_voiceTimer (Sender: TObject);i: integer; k:
integer;
._obr_voice: =ms_obr_voice+10; // лічильник мілісекунд
таймера обробки голосових заявокdata_v_och then // якщо голосова заявка
витісняє заявку типа "данні" в чергу_v_och: =false;_obr_data:
=chas_data_buf [z_vi]; // враховуємо час, що був проведений заявкою в
обробці_data: =round (int_data);Timer (sender); // викликаємо таймер генерації
заявок типу "данні”;not data_vo [z_vo] then // якщо в обробці знаходиться
голосова заявкаms_obr_voice>= int_obr_vioce // якщо голосова заявка виконана
(інтервал часу її обробки перевищено)_vo [z_vo [a]]. Enabled: =false; // зупиняємо
таймер обробки голосових заявок_obr_voice: =0; // змінна, що відповідає
поточному часу обробки заявки_s [z_vo [a]]: =3; // ознака того, що сервер
звільнився_tranz_vo: =n_tranz_vo+1; // лічильник виконаних голосових заявок//
інакше, якщо сервер обробляє заявку типу "данні”ms_obr_voice>=
int_obr_data // якщо заявка типу "данні" виконанаіmer_voice. Enabled:
=false;_vo [z_vo]. Enabled: =false; ms_obr_voice: =0;_s [z_vo]: =3; // сервер
звільнився_vo [z_vo]: =false; // ознака того, що сервер вже не обробляє заявку
типа "данні”_tranz_da: =n_tranz_da+1; // лічильник виконаних заявок типу
"данні”; end;
Рис.4.3 Алгоритм процедури обробки голосових заявок
Процедури, за допомогою яких відбувається генерування заявок
типу "данні" та відео-заявок схожі на вже описану вище. Головна
відмінність для відео-заявки - якщо вільний сервер відсутній, заявка стає в
чергу.
not flag then // якщо немає вільних серверів: =ov+1; //
порядковий номер заявки в черзі_och_vi [ov]: =1;_vid_o [ov]: =ttimer. create
(nil); // створюється таймер для обробки черги заявок_vid_o [ov]. Interval:
=10;_vid_o [ov]. Enabled: =true;_vid_o [ov]. OnTimer: =Timer_v_ocheredTimer; //
викликаємо процедуру обробки черги відео-заявок;
Рис.4.4 Фрагмент алгоритму процедури генерації відео-заявок
(постановка у чергу)
Далі розглянемо фрагмент процедури обробки черги
відео-заявок.
Tmain. Timer_v_ocheredTimer (Sender: TObject);i: integer;
flag: boolean;
.: =false; // ознака того, що всі сервери зайнятіi: =1 to
Num_of_ViS dovi_s [i] =3 then // якщо сервер звільнився_s [i]: =1; // сервер
зайнятий: =b+1;_vi [b]: =i;_vi [z_vi [b]]. Enabled: =true;_obr_video: =round
(abs (randg (video_x,sqrt (video_x))) /mashtab) *1000; // генеруємо інтервал
обробки відео-заявки_obr_video: =0;_vi [z_vi [b]]. OnTimer: =timer_videoTimer;
// викликаємо процедуру обробки відео-заявки: =true; // заявка
прийнята;;;_och_v [ov]: = vremya_och_v [ov] +10;flag=true then // якщо вільний
сервер знайдений_vid_o [ov]. Enabled: =false; // таймер обробки черги
відключений_och_vi [ov]: =0; // заявка вийшла із черги;;
Рис.4.5 Алгоритм процедури обробки черги відео-заявок
При обробці заявок типу "данні”, якщо вільні сервера
відповідного типу відсутні, відбувається пошук вільних серверів, призначених
для обробки голосових і відео-заявок.
not flag then // якщо вільний сервер для обробки заявок типу
"данні" не знайденоi: =1 to Num_of_voS do // перебираємо усі сервера
для обробки відео-заявокvo_s [i] =0 then // якщо сервер не використовувався_s
[i]: =2; // сервер зайнятий обробкою заявки типу "данні”_vo: =i;_vo
[z_vo]: =true;
// встановлюємо параметри таймеру, що відповідає за обробку
голосових заявок_vo [z_vo]: =ttimer. create (nil);_vo [z_vo]. Interval: =10;_vo
[z_vo]. Enabled: =true;
// генеруємо інтервал обробки заявки типу
"данні”_obr_data: =round (abs (randg (data_x,sqrt (data_x)))
/mashtab*1000);
// час, який сервер, що призначений для обробки голосових
заявок, був зайнятий обробкою заявок типу "данні”_data_buf [z_vo]: =round
(int_obr_data);_obr_voice: =0;
// викликаємо процедуру обробки заявки_vo [z_vo]. OnTimer:
=Tomer_voiceTimer;: =true; // заявки прийнята; // вихід із циклу;
На рис.4.6 наведена блок-схема алгоритму цієї процедури.
Аналогічним чином, здійснюється пошук вільних серед серверів,
що призначені для обробки відео-заявок. Якщо немає жодного вільного серверу,
заявка стає до черги.
not flag then // якщо немає жодного вільного сервера:
=od+1;_och_da [od]: =1;
// створюємо таймер для обробки черги_data_o [od]: =ttimer.
create (nil); timers_data_o [od]. Interval: =10;_data_o [od]. Enabled: =true;
// викликаємо процедуру обробки черги_data_o [od]. OnTimer:
=Timer_d_ocheredTimer;;
Рис.4.6 Алгоритм процедури пошуку вільних серверів для
обробки голосових заявок
В процесі моделювання всі поточні дані виводяться на екран з
інтервалом оновлення 1000 мілісекунд. Для цього використовується власний
компонент-таймер.
Tprocess. Timer1Timer (Sender: TObject);
_n_tranz. Caption: =inttostr (n_tranz); // вивід кількості
заявок, що надійшли
// кількість заявок, що надійшли для кожного з
типів_n_tranz_vo_p. Caption: =inttostr (n_tranz_vo_p);_n_tranz_vi_p. Caption:
=inttostr (n_tranz_vi_p);_n_tranz_da_p. Caption: =inttostr (n_tranz_da_p);
// кількість виконаних заявок_n_tranz_vo. Caption: =inttostr
(n_tranz_vo);_n_tranz_vi. Caption: =inttostr (n_tranz_vi);_n_tranz_da. Caption:
=inttostr (n_tranz_da);
// поточне завантаження серверів_zagr_vo. Caption:
=floattostrf (zagr_vo,fffixed,5,2);_zagr_vi. Caption: =floattostrf
(zagr_vi,fffixed,5,2);_zagr_da. Caption: =floattostrf (zagr_da,fffixed,5,2);
// кількість заявок, що знаходяться в черзі_kol_och_vi.
Caption: =inttostr (kol_och_vi);_kol_och_da. Caption: =inttostr (kol_och_da);
// кількість заявок, що знаходяться в обробці_kol_vobr_vi.
Caption: =inttostr (kol_vobr_vi);_kol_vobr_vo. Caption: =inttostr
(kol_vobr_vo);_kol_vobr_da. Caption: =inttostr (kol_vobr_da);
// кількість відмов (для голосових заявок)_otkaz. Caption:
=inttostr (otkaz);
// кількість серверів голосових та відео-заявок, що
обробляють заявки типу "данні”_kol_s_vo_d. Caption: =inttostr
(kol_s_vo_d);_kol_s_vi_d. Caption: =inttostr (kol_s_vi_d);
// процент виконання процесу моделювання. Caption: =inttostr
(round (n_tranz/kol_tranz*100)) +' %';. Position: =round
(n_tranz/kol_tranz*100);;
Після завершення процесу моделювання відбувається розрахунок
та вивід на екран показників ефективності системи.
Tprocess. BitBtn4Click (Sender: TObject);: integer;_o,d_o:
real; // загальний час, що заявки провели у черзі_obsl,d_obsl: real; //
загальний час, проведений заявками на обслуговуванні. Visible: =false;.
Visible: =true;
// вірогідність відмови в обслуговуванні голосових заявок:.
Caption: =floattostrf (otkaz/n_tranz_vo_p,fffixed,5,2);. Visible: =false;.
Visible: =true;
// знаходимо загальний час, що відео-заявки провели у черзіi:
=1 to n_tranz_vi_p do_o: =vi_o+vremya_och_v [i];
// середній час очікування відео-заявки в черзі_vi_och. Caption:
=floattostrf (vi_o/n_tranz_vi_p,fffixed,5,2);
// знаходимо загальний час, проведений відео-заявками на
обслуговуванніi: =1 to n_tranz_vi_p do_obsl: =vi_obsl+vremya_obsl_v [i];
// середній час обслуговування відео-заявки_vr_obsl_v.
Caption: = floattostrf (vi_obsl/n_tranz_vi_p,fffixed,5,2);
// середній час знаходження відео - заявки в
системі_vr_sys_v. Caption: =floattostrf
(vi_o/n_tranz_vi_p+_obsl/n_tranz_vi_p,fffixed,5,2);. Visible: =false;. Visible:
=true;
// знаходимо
загальний час, що заявки типу "данні" провели у черзіi: =1 to
n_tranz_da_p do_o: =d_o+vremya_och_d [i];
// середній час
очікування заявки типу "данні" в черзі_vi_och. Caption: =floattostrf
(d_o/n_tranz_da_p,fffixed,5,2);
// знаходимо
загальний час, проведений заявками типу "данні" на обслуговуванніi:
=1 to n_tranz_da_p do_obsl: =d_obsl+vremya_obsl_v [i];
// середній час
обслуговування заявки типу "данні”_vr_obsl_d. Caption: = floattostrf
(d_obsl/n_tranz_da_p,fffixed,5,2);
// середній час
знаходження заявки типу "данні" в системі_vr_sys_d. Caption:
=floattostrf (d_o/n_tranz_da_p+_obsl/n_tranz_da_p,fffixed,5,2);;
Побудова графіків
відбувається за допомогою компоненту Chart.
4.5 Опис
інтерфейсу користувача
Загальний вигляд робочого вікна системи після її запуску
представлений на рис.4.7 Початкові параметри моделювання користувач має в змозі
зберігати у зовнішньому текстовому файли. Завантажити або зберегти дані можна
за допомогою пунктів меню "Файл”.
Рис.4.7 Загальний вигляд робочого вікна системи після її
запуску
Спочатку необхідно вказати кількість транзакцій, яка пройде
через систему за один цикл моделювання. Оскільки моделювання проводиться в
режимі реального часу, користувачеві потрібно також визначити коефіцієнт
масштабування в часі. Додатковий параметр - частота оновлення даних - дозволяє
налаштувати оновлення даних у вікні "Процес моделювання”.
На наступному етапі задаються окремо параметри кожного з типу
заявок:
· середнє навантаження серверів, %;
· величина середнього часу знаходження
заявок в сервері на обробці, с;
· кількість серверів для обробки заявок.
Усі ці параметри користувач має в змозі завантажити із
зовнішнього файлу за допомогою меню. Після натискання кнопки
"Моделювання" на екрані з’явиться вікно, в якому відображений процес
моделювання (рис.4.8).
Рис.4.8 Вікно відображення процесу моделювання
Тут окремо для кожного з типів заявок відображені данні про
хід моделювання: кількість заявок, що надійшло, кількість опрацьованих заявок,
заблокованих та тих що знаходяться в обробці та черзі. Також відображається
середнє завантаження серверів. В нижній частині вікна відображається хід
виконання процесу.
Після закінчення процесу моделювання необхідно натиснути
кнопку "Показники”. Вікно системи приймає вигляд, зображений на рис.4.9
Тут ми бачимо розраховані параметри ефективності досліджуваної СМО, а саме:
· вірогідність відмови в обслуговуванні
голосових заявок;
· середній час очікування заявки в черзі
(для відео і заявок типу "данні”);
· середній час обслуговування заявки;
· середній час знаходження заявки в системі.
Рис.4.9 Відображення параметрів ефективності
Результати моделювання можна зберегти в зовнішньому файлі
tezult. dat, натиснувши кнопку "Зберегти в файл”. В цьому файлі
накопичуються статистичні дані, що дозволяють побідувати наступні залежності:
· вірогідності блокування голосової заявки
від кількості серверів, призначених для обробки голосових заявок;
· середнього часу очікування відео-заявки в
черзі від кількості серверів, призначених для обробки відео-заявок;
· середнього часу очікування заявки типу
"данні" в черзі від загальної кількості серверів.
Ці графіки ми можемо побачити, натиснувши кнопку
"Показати графіки”. На рис.4.10, 4.11 та 4.12 наведений їх вигляд.
Рис.4.10 Графік залежності вірогідності блокування голосової
заявки від кількості серверів, призначених для обробки голосових заявок
Рис.4.11 Графік залежності середнього часу очікування
відео-заявки в черзі від кількості серверів, призначених для обробки
відео-заявок
Рис.4.12 Графік залежності середнього часу очікування заявки
типу "данні" в черзі від загальної кількості серверів
5. Економічне
обґрунтування доцільності розробки програмного продукту
Метою даної дипломної роботи є розробка системи, що дозволяє
змоделювати і одержати статистичні звіти про процеси в системах, побудованих за
принципом Triple Play. Дослідження систем такого роду відноситься до завдань,
що вирішуються в одному з розділів теорії систем масового обслуговування,
званому теорією телетрафика.
Розроблена система може бути корисна інженерам, що займаються
розробкою і аналізом мереж Triple Play-сервісу.
В ході розробки програмного продукту було використане
програмне забезпечення Turbo Delphi 2006 Explorer, яке є безкоштовним.
Визначення витрат на створення програмного продукту
Оскільки середа розробки є безкоштовною, витрати на створення
програмного продукту складаються з витрат по оплаті праці розробника програми і
витрат по оплаті машинного часу при відладці програми:
Зспп=Ззпспп +Змвспп
де
Зспп - витрати на створення програмного продукту;
Ззпспп - витрати на оплату праці розробника програми;
Змвспп - витрати на оплату машинного часу.
Витрати на оплату праці розробника програми (Ззпспп)
визначаються шляхом множення трудомісткості створення програмного продукту на
середню годинну оплату програміста (з урахуванням коефіцієнта відрахувань на
соціальні потреби):
Ззпспп=tTчас
Розрахунок трудомісткості створення програмного продукту.
Трудомісткість розробки програмного продукту можна визначити
таким чином:
= to+ tа+ tб+ tп+ tд+ tот,
де- витрати праці на підготовку опису завдання;а - витрати
праці на розробку алгоритму рішення задачі;б - витрати праці на розробку
блок-схеми алгоритму рішення задачі;п - витрати праці на складання програми по
готовій блок-схемі;д - витрати праці на підготовку документації завдання;от -
витрати праці на відладку програми на ЕОМ при комплексній відладці завдання.
Складові витрат можна виразити через умовне число операторів
Q. У нашому випадку число операторів у відлагодженій програмі Q=950.
Розрахунок витрат праці на підготовку опису завдань.
Оцінити витрати праці на підготовку опису завдання не
можливо, оскільки це пов'язано з творчим характером роботи, натомість оцінимо
витрати праці на вивчення опису завдання з урахуванням уточнення опису і
кваліфікації програміста:
= QB/ (75…85K),
де:- коефіцієнт збільшення витрат праці унаслідок
недостатнього опису завдання, уточнень і деякої недоробки, B=1,2…5;- коефіцієнт
кваліфікації розробника, для тих, що працюють до 2 років K=0,8;
Коефіцієнт В приймаємо рівним 3.
Таким чином отримаємо:
= 9503/ (780,8) = 45,67 (люд-год).
Розрахунок витрат праці на розробку алгоритму.
Витрати праці на розробку алгоритму рішення задачі:
а = Q/ (60…75K)а = 950/ (700,8) =16,96 (люд-год).
Розрахунок витрат праці на розробку блок-схеми.
Витрати праці на розробку блок-схеми алгоритму рішення задачі
обчислимо таким чином:
б= Q/ (60…75K)б = 950/ (710,8) =16,73 (люд-год).
Розрахунок витрат праці на складання програми.
Витрати праці на складання програми по готовій блок-схемі
обчислимо таким чином:
п= Q/ (60…75K)п = 950/ (720,8) =16,49 (люд-год).
Розрахунок витрат праці на відладку програми.
Витрати праці на відладку програми на ЕОМ при комплексній
відладці завдання:
от=1.5tAот,
де tAот - витрати праці на відладку програми на ЕОМ при
автономній відладці одного завдання;
от= Q/ (40…50K)от = 950/ (480,8) =24,74 (люд-год)
Звідси tот=1,524,74=37,11 (люд-год).
Розрахунок витрат праці на підготовку документації.
Витрати праці на підготовку документації по завданню
визначаються:
д= tдр+ tдо,
де:др - витрати праці на підготовку матеріалів в рукопису;до
- витрати на редагування, друк і оформлення документації;
др= Q/ (150…200K), tдр = 950/ (1800.8) = 6,59
(люд-год)до=0.75tдрдо =0.756,59=4,95 (люд-год)
Звідси:
д=6,59+4,95=11,54 (люд-год).
Отже, загальну трудомісткість розробки програмного продукту
можна розрахувати:
= to+ tа+ tб+ tп+ tд+ tот,=
45,67+16,96+16,73+16,49+11,54+37,11 = 144,5 (люд-год).
Розрахунок середньої зарплати програміста.
Середня зарплата програміста в сучасних ринкових умовах може
варіюватися в широкому діапазоні. Для розрахунку візьмемо середню годинну
оплату праці програміста, яка складає Тчас. =10 грн/година. Це означає, що
вартість розробки буде становитиму 1445 грн.
Витрати на оплату праці програміста складаються із зарплати
програміста і нарахувань на соціальні потреби. Нарахування на соціальні потреби
включають:
Єдине соціальне нарахування становить 37,2%.
Тобто 1 445 грн37,2%=537,54 грн
Звідси витрати на оплату праці програміста складають:
Ззпспп= 1445+537,54= 1982,54 грн.
Витрати на оплату машинного часу.
Витрати на оплату машинного часу при відладці програми
визначаються шляхом множення фактичного часу відладки програми на ціну
машино-години орендного часу:
Змвспп =СчасtЕОМ,
де:
Счас - ціна машино-години, грн/год;ЕОМ - фактичний час
відладки програми на ЕОМ;
Розрахунок фактичного часу відладки.
Фактичний час відладки обчислимо за формулою:
еом = tп + tдо + tот;еом =16,49 +4,95 +37,11 = 58,55 години
Розрахунок ціни машино-години.
Ціну машино-години знайдемо по формулі:
Сгод = Зеом/Теом,
де:
Зеом - повні витрати на експлуатацію ЕОМ на протязі року;
Теом - дійсний річний фонд часу ЕОМ, год/рік.
Розрахунок річного фонду часу роботи ПЕОМ.
Загальна кількість днів в році - 365. Число святкових і
вихідних днів - 114 (10 святкових і 522 - вихідні).
Час простою в профілактичних роботах визначається як
щотижнева профілактика по 3 години.
Разом річний фонд робочого часу ПЕОМ складає:
Теом = 8 (365-114) - 523=1852 год.
Розрахунок повних витрат на експлуатацію ЕОМ.
Повні витрати на експлуатацію можна визначити по формулі:
Зеом = (Ззп+ Зам+ ЗЕЛ+ Здм+ Зпр+ Зін),
де:
Ззп - річні витрати на заробітну плату обслуговуючого
персоналу, грн/рік;
Зам - річні витрати на амортизацію, грн/рік;
ЗЕЛ - річні витрати на електроенергію, споживану ЕОМ,
грн/рік;
Здм - річні витрати на допоміжні матеріали, грн/рік;
Зпр - витрати на поточний ремонт комп'ютера, грн/рік;
Зін - річні витрати на інші і накладні витрати, грн/рік.
Амортизаційні відрахування.
Річні амортизаційні відрахування визначаються по формулі:
Зам=СбалНам,
де: Сбал - балансова вартість комп’ютера, грн/шт.;
Нам - норма амортизації, %;
Нам =25%.
Балансова вартість ПЕОМ включає відпускну ціну, витрати на
транспортування, монтаж устаткування і його відладку:
Сбал = Срин +Зуст;
де:
Срин - ринкова вартість комп’ютеру, грн/шт.,
Зуст - витрати на доставку і установку комп'ютера, грн/шт;
Комп'ютер, на якому велася робота, був придбаний за ціною
Срин =5000 грн, витрати на установку і наладку склали приблизно 10% від
вартості комп'ютера.
Зуст = 10%Срин
Зуст =0.15000=500 грн.
Звідси, Сбал = 5000 +500 =5500 грн. /шт.;
а Зам=55000,25= 1375 грн/год.
Розрахунок витрат на електроенергію.
Вартість електроенергії, споживаної за рік, визначається по
формулі:
Зел = Реом Теом Сел А,
де:
Реом - сумарна потужність ЕОМ,
Теом - дійсний річний фонд часу ЕОМ, год/рік;
Сел - вартість 1кВтгод електроенергії;
А - коефіцієнт інтенсивного використання потужності машини.
Згідно технічному паспорту ЕОМ Реом =0.22 кВт, вартість
1кВтгод електроенергії для споживачів Сел =0,2436 грн., інтенсивність
використання машини А=0.98.
Тоді розрахункове значення витрат на електроенергію:
Зел = 0.22 18520.24360.30 = 29,78 грн.
Розрахунок витрат на поточний ремонт.
Витрати на поточний і профілактичний ремонт приймаються
рівними 5% від вартості ЕОМ:
Зпр = 0.05Сбал, Зпр = 0.055500 = 275 грн.
Розрахунок витрат на допоміжні матеріали.
Витрати на матеріали, необхідні для забезпечення нормальної
роботи ПЕОМ, складають близько 1 % від вартості ЕОМ:
Звм =0,015500 =55 грн.
Інші витрати по експлуатації ПЕОМ.
Інші непрямі витрати, пов'язані з експлуатацією ПЕОМ,
складаються з вартості послуг сторонніх організацій і складають 5% від вартості
ЕОМ:
Зпр = 0,055500 =275 грн.
Річні витрати на заробітну плату обслуговуючого персоналу.
Витрати на заробітну плату обслуговуючого персоналу
складаються з основної заробітної плати, додаткової і відрахувань на заробітну
плату:
Ззп = Зоснзп +Здопзп +Зотчзп.
Основна заробітна плата визначається, виходячи із загальної
чисельності тих, що працюють в штаті:
Зоснзп =12 ∑Зіокл,
де
Зіокл - тарифна ставка і-го працівника в місяць, грн;
- кількість місяців.
У штат обслуговуючого персоналу повинні входити інженер-електронщик
з місячним окладом 1500 грн. і електрослюсар з окладом 1200 грн. Тоді,
враховуючи, що даний персонал обслуговує 20 машин, маємо витрати на основну
заробітну плату обслуговуючого персоналу, які складуть:
Зоснзп = 12 (1500+1200) /20=32 400 грн.
Додаткова заробітна плата складає 60 % від основної
заробітної плати:
Здопзп = 0.6 32 400 = 19 440 грн.
Відрахування на соціальні потреби складають 37,2% від суми
додатковою і основною заробітних плат:
Зотчзп = 0,372 (32 400 + 19 440) = 19 284,48 грн.
Тоді річні витрати на заробітну плату обслуговуючого
персоналу складуть:
Ззп = 32 400 +19 440 +19 284,48 = 71 124,48 грн.
Повні витрати на експлуатацію ЕОМ в перебігу року складуть:
Зеом = 71 124,48 + 1375+ 29,78 + 55 + 275+ 275= 73 134,26
грн.
Тоді ціна машино-години часу, що орендується, складе
Сгод = 73 134,26 /1852 = 39,49 грн.
А витрати на оплату машинного часу складуть:
Змвспп =Сгодtеом
Змвспп = 39,49 58,55 = 2312,14 грн.
Розрахунок економічного ефекту.
Зспп=Ззпспп +Змвспп, Зспп =1 928,96+ 2 312,14 = 4 241,10 грн.
Тобто собівартість програмного продукту 4 241,10 грн.
А зараз визначимо ціну програмного продукту:
Ц = Зспп + Р,
где Ц - ціна програмного продукту; Р - 15% від витрат на
створення програмного продукту.
Ц = 4 241,10 + 636,17= 4 877,27 грн.
Ціна програмного продукту дорівнює 4 877,27 грн.
В порівнянні з іншими програмними продуктами, які виконують
аналогічні функції та мають вартість орієнтовно $2000, розроблена програма за
умови тиражування обійдеться значно дешевше, ніж аналоги.
,0 - курс долара Національного банку України
ЕК = $2000 * 8,0 - 4 877,27 = 11 122,73 грн.
6. Охорона
праці
Вивчення і рішення проблем, пов'язаних із забезпеченням
здорових та безпечних умов, в яких протікає труд людини - одна з найбільш
важливих завдань у розробці нових технологій та систем виробництва. Вивчення та
виявлення можливих причин виробничих нещасних випадків, професійних
захворювань, аварій, вибухів, пожеж, і розробка заходів та вимог, спрямованих
на усунення цих причин дозволяють створити безпечні та сприятливі умови для
праці людини.
В Україні діють закони, які визначають права й обов'язки її
громадян, а також організаційну структуру органів влади і промисловості. Конституція
України декларує рівні права й свободи всім жителям країни: вільний вибір
роботи, що відповідає безпечним і здоровим умовам, на відпочинок, на соціальний
захист у випадку втрати працездатності й старості. Всі закони й нормативні
документи повинні узгоджуватися, базуватися й відповідати статтям Конституції.
Законодавча база охорони праці України має ряд законів,
основним з яких є Закон України "Про охорону праці" і Кодекс законів
про працю (КЗпП). До законодавчої бази також належать Закони України: "Про
загальнообов'язкове страхування від нещасних випадків на виробництві й
професійних захворювань, які викликали втрату працездатності", "Про
охорону здоров'я", "Про пожежну безпеку", "Про забезпечення
санітарного й епідеміологічного добробуту населення", "Про
використання ядерної енергії й радіаційну безпеку", "Про дорожній
рух", "Про обов'язкове страхування у зв'язку з тимчасовою втратою
працездатності й витратами, обумовленими народженням й похоронами". Їх
доповнюють державні галузеві й міжгалузеві нормативні акти - це стандарти,
інструкції, правила, норми, положення, статути й інші документи які мають
статус правових норм, обов'язкових для виконання всіма установами й
працівниками України.
Найбільш повним нормативним документом по забезпеченню
охорони праці користувачів ПК є "Державні санітарні правила й норми роботи
з візуальними дисплейними терміналами (ВДТ) електронно-обчислювальних
машин" ДСанПіН 3.3.2.007-98.
В Україні затверджене положення про створення державних
нормативних актів по охороні праці ДНАОП. Це норми, інструкції, вказівки й інші
види державних нормативних актів по охороні праці обов'язкові по виконанню й
керівництво підприємствами й установами, на які поширюється сфера дії цих
актів.
6.1 Аналіз
небезпечних й шкідливих виробничих факторів
Комфортні та безпечні умови праці-одна з основних факторів,
що впливають на продуктивність службовців обчислювальних центрів. Робота
співробітників обчислювальних центрів безпосередньо пов'язана комп'ютером, а
відповідно з додатковим шкідливим впливом цілої групи факторів, що істотно
знижує продуктивність їх праці.
Приміщення, в якому виконувалась науково-дослідна робота - це
інформаційно-обчислювальний центр (ІОЦ). У інформаційно-обчислювальному центрі
знаходиться 14 комп’ютерів з 14 робочими місцями. Розміри ІОЦ такі: довжина -
13 м, ширина - 7 м, висота - 3,2 м, таким чином, загальна фактична площа
складає 91 м2, загальний об’єм приміщення - 291,2 м3.
Наведені розміри відповідають необхідним нормам СН 512-78 и
ДСанПіН 3.3.2.007-98, виходячи з яких, площа повинна бути не менше 6 м2 на одне
робоче місце, об’єм не менше 20 м3, таким чином, площа робочого місця у
приміщенні складає 6,5 м2, а об’єм 20,8 м3.
Робота з комп'ютером характеризується значною розумовою
напругою і нервово-емоційним навантаженням на людину, високою напруженістю
зорової роботи і достатньо великим навантаженням на м'язи рук при роботі з
пристроями введення комп'ютера. Велике значення має раціональна конструкція і
розташування елементів робочого місця, що важливе для підтримки оптимальної
робочої пози людини. Небезпечні і шкідливі виробничі чинники, класифікуються на
підставі ДОСТ 12.0.003-74. У таблиці 6.1 наведені небезпечні і шкідливі
чинники, які мають місце при роботі з ПЕОМ з вказівкою дії на організм людини.
Таблиця 6.1
Небезпечні і шкідливі чинники при роботі з ПЕОМ
|
№ п/п
|
Назва фактора
|
Джерела виникнення
|
Характер дії
|
|
1
|
Підвищення значення напруги в електричному
ланцюзі
|
Мережа електричного струму (380/220 В)
|
Небезпечний
|
|
2
|
Підвищений рівень статичної електрики
|
Екран дисплея і діелектричні поверхні
|
Небезпечний
|
|
3
|
 Підвищена іонізація
повітря
|
Статична електрика
|
Шкідливий
|
|
4
|
Підвищені рівні шуму та вібрації
|
Пристрої охолодження ЕОМ, друкувальні пристрої
|
Шкідливий
|
|
5
|
Пряме та відбите світло
|
Зовнішні джерела світла, діючі на екран
|
Шкідливий
|
|
6
|
Підвищена пульсація світлового потоку
|
Лампи денного світла (люмінесцентні), екран
монітора
|
Шкідливий
|
|
7
|
Розумове перенапруження
|
Тривала розумова праця
|
Шкідливий
|
|
8
|
Підвищена запиленість повітря
|
Стан системи кондиціонування і вентиляції,
перевантаженість робочих місць
|
Шкідливий
|
|
9
|
Перенапруження аналізаторів
|
Тривале знаходження перед монітором, шум
обладнання
|
Шкідливий
|
|
10
|
Монотонність праці
|
Тривале виконання однотипної праці, рідка зміна
пози
|
Шкідливий
|
|
11
|
Емоційне перевантаження
|
Стреси, що виникають від монотонної праці,
загальної емоційної напруги, непередбачуваних невдач та проблем під час
виконання завдань
|
Шкідливий
|
Робота на ІОЦ, у відповідності до ДСН 3.3.6.042-99,
відноситься до категорії важкості робот 1б - легка. Енерговитрати складають
141-175 Вт (121-150 ккал/год.). Оптимальні значення параметрів мікроклімату для
теплого і холодного періодів року з урахуванням категорії робіт, приведені у
таблиці 6.2 згідно з вимогами ДОСТ 12.1.005-88 та ДСН 3.3.6.042-99.
Таблиця 6.2
Оптимальні значення параметрів мікроклімату
|
Період року
|
Категорія робіт за енерговитратами
|
Температура, оС
|
Відносна вологість, %
|
Швидкість руху повітря, м/с
|
|
Холодний
|
1б
|
21-23
|
40-60
|
<0,1
|
|
Теплий
|
1б
|
22-24
|
40-60
|
<0,2
|
Норми рівнів іонізації повітря відповідно до СН 2152-80 [20,
27, 28] приведені у таблиці 6.3.
Таблиця 6.3
Рівні іонізації повітря приміщення при роботі з ЕОМ
|
Рівні іонізації
|
Кількість іонів у  повітря
|
|
 
|
|
|
Максимально необхідні
|
400
|
600
|
|
Оптимальні
|
1500-3000
|
3000-5000
|
|
Допустимі
|
50000
|
50000
|
Поверхня підлоги в приміщеннях експлуатації ПЕОМ повинна бути
рівною, без вибоїн, неслизького, зручного для очищення і вологого прибирання,
володіти антистатичними властивостями.
Відповідно до ДСанПіН 3.3.2.007-98. встановлюються гігієнічні
вимоги, які регламентують допустиме значення поверхневого електростатичного
потенціалу не більше 500 В, а напруженість електростатичного поля 15 кВ/м.
Експлуатовані ЕОМ є однофазними споживачами трьохфазної
чотирьохпроводної мережі з глухозаземленою нейтраллю із напругою 380/220 В і
частотою 50 Гц. Приміщення ІОЦ по ступеню небезпеки ураження людей електричним
струмом згідно з ПУЕ-87 належить до категорії приміщень з підвищеною
небезпекою, оскільки робочі місця розташовані таким чином, що існує можливість
одночасного дотику до металевих корпусів електроустаткування та до
металоконструкцій будівлі, що мають з'єднання з землею.
Джерелами шуму на ІОЦ є принтери та охолоджувальна система ЕОМ.
Згідно норм у приміщенні ІОЦ рівні звуку не повинні перевищувати 50 дБА. Згідно
ДОСТ 12.1.012-90 рівень вібрації для категорії 3, тип В, в умовах
"комфорту” не повинен перевищувати 75 дБ. Нормою коефіціенту пульсації
світлового випромінювання є 10-20%. Концентрація пилу у приміщенні не повинна
перевищувати 4 
. У світлий час доби на ІОЦ
використовується бокове одностороннє природнє освітлення, а у темний час -
загальне рівномірне штучне. Освітлення повинне забезпечувати необхідний
спектральний склад світла. Значення нормативного показника КПО має бути не менш
1,5% при роботі з ЕОМ згідно нормам НПАОП 0.00-1.31-99.
Розряд зорової роботи, а також нормовані показники природного та
штучного освітлення відповідно до ДБН В.2.5-28-2006 приведені у таблиці 6.4.
Таблиця 6.4. Нормовані показники природного та штучного
освітлення
|
Характеристика зорової роботи
|
Розряд зорової роботи
|
Розмір об’єкта розпізнавання, мм
|
Під розряд зорової роботи
|
Характеристика фону
|
Контраст об’єкта розпізнавання з фоном
|
Освітлення
|
|
|
|
|
|
|
Штучне, загальне, E, лк
|
Природне, бокове, КПО,%
|
|
Середньої точності
|
IV
|
0,5 - 1
|
г
|
світлий
|
великий
|
200
|
1,3
|
6.2 Заходи
щодо нормалізації небезпечних і шкідливих факторів
Для забезпечення нормальних метеоумов в ІОЦ встановлений
кондиціонер, що постійно підтримує задані кліматичні параметри в робочому
просторі. У зимовий період у доповненні до центрального опалення використаються
електрообігрівачі масляного типу. У літній період при зниженні в повітрі
кількості водяної пари (низкою вологості повітря) застосовується зволожувач
повітря.
Основними джерелами шумів в приміщенні, де робота
здійснюється за допомогою ПЕОМ, є шум від самих ПЕОМ, розмова людей, система
кондиціонування, шум від працюючої друкарської техніки і шум з вулиці,
коридору.
Для пониження рівня шумів в приміщенні можна використовувати
наступні заходи:
. Одним з головних джерел шуму є автотранспорт, що рухається
на вулиці, тому для його пониження використовуються звукоізоляційні пластикові
вікна.
. Для зниження ефекту від шумів, що створюються усередині
приміщення стелі і стіни покриваються спеціальними звукопоглинальними
матеріалами.
. Основним джерелом шуму в ПЕОМ є встановлені в системному
блоці вентилятори, тому слід забезпечити таку систему охолоджування, яка
створювала б мінімум шуму, наприклад, використовувати вентилятори більшого
діаметру, використання пасивного охолоджування усередині ПЕОМ.
. Використання безшумної клавіатури і миші, сучасна
периферійні пристрої (принтер, сканер) теж значно тихіше раніше випущених
моделей
Розрядні струми статичної електрики найчастіше виникають при
дотику до будь-якого з елементів ПЕОМ. Такі розряди небезпеки для людини не
представляють, але окрім неприємних відчуттів вони можуть привести до виходу з
ладу ПЕОМ. Для зниження величини виникаючих зарядів статичної електрики в
приміщенні покриття технологічної полови слід виконувати з одношарового
полівінілхлоридного антистатичного лінолеуму. Іншим методом захисту є
нейтралізація заряду статичної електрики іонізованим газом. У промисловості
широко застосовуються радіоактивні нетралізатори. До загальних заходів захисту
від статичної електрики в приміщенні можна віднести зволоження повітря.
Відповідно до правил пристрою електроустановок для заземлення
електроустановок потужністю менш 1кВ рекомендується використовувати заземлення
з опором 4 Ом.
Таким чином, для захисту від дії статичної електрики
впроваджуються наступні заходи:
− заземлення електроприладів;
− протирання зовнішньої поверхні монітора,
клавіатури і інших пристроїв, вологою серветкою;
− щоденне вологе прибирання приміщення;
− покриття підлоги спеціальним антистатичним
лінолеумом.
Для захисту від поразки електричним струмом у разі
пошкодження ізоляції повинні бути застосовані окремо або в поєднанні наступні
заходи захисту при непрямому дотику:
− захисне заземлення;
− автоматичне відключення живлення;
− зрівнювання потенціалів;
− вирівнювання потенціалів;
− подвійна або посилена ізоляція;
− наднизька напруга;
− захисне електричне розділення ланцюгів;
− ізолюючі приміщення зони або майданчики.
При правильно розрахованому і виконаному освітленні очі
працюючого за комп’ютером протягом тривалого часу зберігають здатність добре
розрізняти предмети не втомлюючись. Це сприяє зниженню професійного
захворювання очей, підвищується працездатність. Раціональне освітлення
відповідає ряду вимог:
− достатнє, щоб очі без напруги могли розрізняти
деталі;
− постійна напруга в мережі не коливається більше
ніж на 4%;
− рівномірно розподілено по робочим поверхням,
щоб очам не приходилося зазнавати різкого контрасту кольорів;
− не викликає дії, яка сліпить органи зору
працюючого (зменшення блищання джерел, що відбивають світло, досягається
застосуванням світильників, які розсіюють світло);
− не викликає різких тіней на робочих місцях.
Задачею розрахунку є визначення необхідної потужності
електричної освітлювальної установки для створення у виробничому приміщенні
заданої освітленості. При проектуванні освітлювальної установки необхідно
вирішити наступні основні питання:
− вибрати тип джерела світла - рекомендуються
газорозрядні лампи, за винятком місць, де температура повітря може бути менш
+5°С і напруга в мережі падати нижче 90 % номінального, а також місцевого
освітлення (у цих випадках застосовуються лампи розжарювання);
− визначити систему освітлення (загальна
локалізована або рівномірна, комбінована);
− вибрати тип світильників з урахуванням
характеристик світорозподілення, умов середовища (конструктивного виконання) та
інше;
− розподілити світильники і визначити їх
кількість (світильники можуть матися в своєму розпорядженні рядами, в шаховому
порядку, ромбоподібно);
− визначити норму освітленості на робочому місці.
Для розрахунку штучного освітлення використовують в основному
три методи. Найчастіше її розраховують по світловому потоку. Для цього
визначається світловий потік кожної лампи по нормуючій мінімальній
горизонтальній освітленості Еmin (лк) з вираження:
= (Emin·S·K·z) / n1·n·N, (6.1)
де F - світловий потік лампи в світильнику, лм;- площа
приміщення, м2;- коефіцієнт запасу;- коефіцієнт нерівномірного освітлення;-
коефіцієнт використання світлового потоку;- кількість ламп в світильнику;-
число світильників.
Якщо освітлення здійснюється рядами люмінесцентних ламп, те
вираження вирішується відносно N. Значення коефіцієнта n1 визначається по
довіднику в залежності від типу світильника, коефіцієнтів відбивання стін Рс,
стелі Рп, робітничій поверхні і від розмірів приміщення. Показник приміщення fi
визначається з виразу:
= А·В/Нр· (А+В), (6.2)
де А і В - довжина і ширина освітленого приміщення, м;
Нр - висота підвісу світильника над робітничою поверхнею, м.
У випадку застосування люмінесцентних ламп потрібна кількість
світильників N, яка визначається за формулою:
=Emin·S·K·z/F·n1·n (6.3)
Поділивши число світильників N на число вибраних рядів
світильників, визначають число світильників у кожному ряду.
Нехай зал має розміри А=13 м, В=7 м, h=3.2 м, стеля
обладнується світильниками Л201Б з люмінесцентними лампами ЛБ80.
Рівень робітничої поверхні над полом 0,8 м, при цьому Нр=2,4
м.
Показник приміщення рівний:
=40/2,4 (8+5) =1,3986
По довіднику визначаємо значення коефіцієнта n1 (для значень
Рс=0,5, Рп=0,3): n1=0,7. Значення коефіцієнта нерівномірного освітлення
приймаємо рівним 1,1, а коефіцієнта запасу - 1,5. При загальному типі
освітлення значення Emin=400 лк. Знаючи значення світлового потоку кожної
лампи, можемо визначити необхідну кількість світильників:
=400·8·5·1,5·1,1/5220·0,7·2=3 (штук)
Загальна потужність освітлювальної установки рівна:
Р=2·80·3=480 (Вт)
По результатах проведених розрахунків можна зробити висновок
про те, що небезпечні і шкідливі виробничі чинники, діючи в робочій зоні,
знаходяться в межах допустимих норм і їхній вплив на організм працюючих не
приносить істотної шкоди здоров’ю.
6.3 Пожежна
безпека
Безпечна евакуація людей при пожежі має першорядне значення в
комплексі заходів щодо забезпечення пожежної безпеки. Досвід показує, що
недооцінка важливості або неправильне розуміння цього моменту може привести до
трагічних наслідків. Важливим і обов'язковим елементом забезпечення; безпечній
евакуації людей при пожежі і інших надзвичайних ситуаціях є грамотно
розроблений і правильно виконаний план евакуації.
Згідно БНіП 2.09.02-85, в будівлях і спорудах (окрім житлових
будинків) при одноразовому знаходженні на поверсі більше 10 чоловік повинні
бути розроблені і на видних місцях вивішені плани евакуації людей на випадок
пожежі, а також передбачена система сповіщення людей про пожежу.
На об'єктах з масовим перебуванням людей на додаток до
схематичного плану евакуації людей при пожежі повинна бути розроблена
інструкція, що визначає дії персоналу по забезпеченню безпечної і швидкої
евакуації людей, по якій не рідше за один раз в півріччя повинні проводитися
практичні тренування всіх задіяних для евакуації працівників.
Плани евакуації складаються, зважаючи на особливості
поведінки людей при пожежі, об'ємно-планувальні рішення будівлі (розміри і тип
комунікаційних шляхів і т.п.), потужності сформованих людських потоків, режим
експлуатації будівлі, що склався, активні і пасивні системи пожежної безпеки.
План розміщується на видному, доступному місці.
В електронно-обчислювальній техніці пожежну небезпеку
створюють прилади, що нагріваються, електро- і радіотехнічні елементи. Вони
нагрівають навколишнє повітря і близько розташовані деталі і провідники. Все це
може призвести до займання означених елементів, руйнування ізоляції і короткого
замикання.
Для гасіння пожеж передбачена наявність первинних засобів
пожежегасіння, (згідно так і пожежні крани із брезентовими рукавами, пожежні
щити (1 щит на 5000м2). В кімнаті знаходиться вогнегасник (ВВ-5). При
розміщенні вогнегасників виключений безпосередній вплив на них сонячних
променів, опалювальних і нагрівальних пристроїв. За конструкцією, матеріалами,
методами контролю, умовами змісту, обслуговуванням вогнегасник відповідає
вимогам Правил пристрою і безпечної експлуатації судин, що працюють під тиском.
Пожежа в приміщенні обчислювального центру відноситися до
класу Е - пожежі, пов'язані з горінням електроустановок, що знаходяться під
напругою. Відповідно до "Правил пожежної безпеки в Україні" при
захисті приміщень ЕОМ, слід використовувати порошкові та вуглекислові вогнегасники
з урахуванням гранично допустимої концентрації вогнегасної речовини. Заряди
вогнегасників слід перевіряти не рідше за один раз на рік зважуванням з
точністю до 10г. Розміщення вогнегасників в коридорах, проходах не повинно
перешкоджати безпечній евакуації людей. Їх слід розташовувати на видних місцях
поблизу від виходів з приміщень на висоті не більше 1,5 м.
Висновки
Імітаційне моделювання - це метод дослідження, при якому
система, що вивчається, замінюється моделлю з достатньою точністю описує
реальну систему і з нею проводяться експерименти з метою отримання інформації
про цю систему. Експериментування з моделлю називають імітацією. Імітаційне
моделювання - це окремий випадок математичного моделювання. Існує клас
об'єктів, для яких з різних причин не розроблені аналітичні моделі, або не
розроблені методи рішення одержаної моделі. В цьому випадку математична модель
замінюється імітатором або імітаційною моделлю.
На відміну від аналітичного імітаційне моделювання знімає
більшість обмежень, пов'язаних з можливістю відображення в моделях реального
процесу функціонування системи, яку досліджують, динамічної взаємної
обумовленості поточних і наступних подій, комплексного взаємозв'язку між
параметрами і показниками ефективності системи тощо. Хоч імітаційні моделі в
деяких випадках не такі лаконічні як аналітичні, проте вони можуть бути як
завгодно близькими до системи, яку моделюють, і простими у використанні. Це дає
змогу застосовувати імітаційне моделювання як універсальний підхід для
прийняття рішень в умовах невизначеності, враховуючи в моделях навіть ті
чинники, які важко формалізувати, а також використовувати головні принципи
системного підходу для розв'язування практичних задач.
Результатом виконання дипломної роботи є побудова моделі
розподілу ресурсів в мережах сервісу Triple Play та програмна реалізація
системи, що дозволяє отримувати основні показники ефективності досліджуваної
СМО і будувати графіки залежності на основі статистичних даннях.
Розроблена система ілюструє особливості застосування теорії
систем масового обслуговування стосовно вирішення задач телекомунікації та може
бути корисна інженерам, що займаються розробкою і аналізом мереж Triple
Play-сервісу.
Список
літератури
1. Вентцель
Е. С, Овчаров Л.А. Прикладные задачи теории вероятностей. - М., 1983
2. Гаевский
А. Разработка программных приложений на Delphi 7 - М.: Киев, 2003.
. Глинский
Я.Н., Анохин В.Е., Ряжская В.А. Turbo Pascal 7.0 и Delphi. Учебное пособие.
СПб.: ДиаСофтЮП, 2003.
. Грэхем
И. Объектно ориентированные методы. - М.: Издательский дом "Вильямс",
2004
. Дарахвелидзе
П.Г., Марков Е.П. Delphi - среда визуального программирования. СПб.: BHV -
Санкт-Петербург, 2009.
. Жериовий
Ю.В. Марковські моделі масового обслуговування. - Львів. 2004.
. Жерновин
Ю.В. Імітаційне моделювання систем масового обслуговування: Практикум. - Львів:
Видавничий центр ЛНУ. 2007.
. Ивченко
Г. К, Каштанов В.Л., Коваленко И.Н. Теория массового обслуживания. - М. 1982.
. Климова
Л.М. "Delphi 7. Самоучитель. М.: ИД КУДИЦ-ОБРАЗ, 2005.
. Корнышев
Ю.Н., Пшеничников А.П., Харкевич А.Д. Теория телетрафика: Учебник для вузов. -
М.: Радио и связь, 1996.
. Крылов
В.В. Теория телетрафика (Основы теории систем массового обслуживания для задач
телекоммуникаций) - Н. Новгород: НГТУ, 2000.
. Крылов
В.В., Самохвалова С.С. Теория телетрафика и ее приложения. - СПб.:
БХВ-Петербург, 2005.
. Кудрявцев
Е.М. Основы имитационного моделирования различных систем. - М. 2004.
.
Мадрел Тео. Разработка пользовательского интерфейса/ Пер. с англ. - М.: ДМК,
2001.
.
Немнюгин С.А. Программирование - CПб.: Питер, 2000.
. Орлов
И.А. Эксплуатация и ремонт ЭВМ, организация работы ВЦ. Москва - 2001.
. Ревнич
Ю.В. Нестандартные приемы программирования на Delphi. - СПб.: БХВ-Петербург,
2005.
. Ремизов
Н. Delphi - CПб.: Питер, 2007.
. Таненбаум
Э. Компьютерные сети.4-е изд. - СПб.: Питер, 2003.
. Фараонов
В. Система программирования Delphi. CПб.: БХВ-Петербург, 2005.
.
Ханекамп Д. Вилькен П. Программирование под Windows/ Пер. с нем. - М.: ЭКОМ,
2006.
. Шварц
М. Сети связи: протоколы, моделирование и анализ. В 2-х с англ. - М: Наука,
1992.
. Artifex
4.2 Modeling Guide. - ARTIS Software corporation.
. Cooper
R. B. Introduction to queueina theory. - New York. 1981.
. Leland
W. E., Taqqu M. S., Willinger W., Wilson D. V. On the self-similar nature of
Ethernet traffic // IEEE Transaction on networking. - Vol.12. - 1994. - № 1. -
P.2-15.
. Medhi
J. Stochastic models in queueing theory. - Academic Press, 2003.
. Norros
Ilkka. A storage model with self-similar input. - Queueing Systems, 1994.
28. j@alba.ua
<mailto:j@alba.ua> - адрес автора
. <http://www.intuit.ru>
// Интернет-университет информационных технологий
. http://ru.
wikipedia.org <http://ru.wikipedia.org> // Свободная
Интернет-энциклопедия
. http://algolist.
manual.ru <http://algolist.manual.ru> // Исходные коды и книги по
алгоритмам
. <http://www.delphisources.ru>
// Программирование на Delphi
. <http://www.delphimaster.ru>
// Мастера Delphi