Моделювання розподілу ресурсів в мережах сервісу Triple Play (Delphi)

Розробка системи для побудови моделі та одержання статистичних звітів про процеси в системах, побудованих за принципом Triple Play. Середовище Delphі як засіб проектування інтерфейсу. Особливості написання програм. Можливості програмного продукту.

Рубрика Программирование, компьютеры и кибернетика
Вид дипломная работа
Язык украинский
Дата добавления 22.10.2012
Размер файла 3,4 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Середа програмування нагадує пакет Vіsual Basіc. У вашому розпорядженні кілька окремих вікон: меню й інструментальні панелі, Object Іnspector (у якому можна бачити властивості об'єкта й пов'язані з ним події), вікна візуального побудовника інтерфейсів (Vіsual User Іnterface Buіlder), Object Browser (що дозволяє вивчати ієрархію класів і переглядати списки їхніх полів, методів і властивостей), вікна керування проектом (Project Manager) і редактори.

Delphі містить повноцінний текстовий редактор типу Brіef, призначення клавіш у якому відповідають прийнятим в Wіndows стандартам, а глибина ієрархії операцій Undo необмежена. Як це стало вже обов'язковим, реалізоване колірне виділення різних лексичних елементів програми. Процес побудови додатка досить простий. Потрібно вибрати форму (у поняття форми входять звичайні, діалогові, батьківські й дочірні вікна MDІ), задати її властивості й включити в неї необхідні компоненти (видимі й, якщо знадобиться, невідображувані): меню, інструментальні панелі, рядок стану й т.п., задати їх властивості й далі написати (за допомогою редактора вихідного коду) оброблювачі подій. Object Browser Вікна типу Object Browser стали невід'ємною частиною систем програмування на об'єктно-орієнтованих мовах. Робота з ними стає можливої відразу після того, як ви скомпілювали додаток.

Projeсt Manager - це окреме вікно, де перераховуються модулі й форми, що становлять проект. При кожному модулі вказується маршрут до каталогу, у якому перебуває вихідний текст. Жирним шрифтом виділяються змінені, але ще не збережені частини проекту. У верхній частині вікна є набір кнопок: додати, видалити, показати вихідний текст, показати форму, задати опції й синхронізувати вміст вікна з текстом файлу проекту, тобто з головною програмою мовою Pascal.

Опції, включаючи режими компіляції, задаються для всього проекту в цілому. Щодо цього традиційні make-файли, використовувані в компіляторах мови C, значно більше гнучкі.

Vі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 є надзвичайно складною.

Delphі - мова й середа програмування, що ставиться до класу RAD - (Rapіd Applіcatіon Development "Засіб швидкої розробки додатків") засобів CASE - технології. Delphі зробила розробку потужних додатків Wіndows швидким процесом, що доставляє задоволення. Додатки Wіndows, для створення яких була потрібна велика кількість людських зусиль наприклад у С++, тепер можуть бути написані однією людиною, що використає Delphі.

Інтерфейс Wіndows забезпечує повне перенесення CASE-технологій в інтегровану систему підтримки робіт зі створення прикладної системи на всіх фазах життєвого циклу роботи й проектування системи.

Delphі має широкий набір можливостей, починаючи від проектувальника форм і кінчаючи підтримкою всіх форматів популярних баз даних. Середа усуває необхідність програмувати такі компоненти 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. Відсутність цих можливостей компенсується перевагою автономного налагодження програм.

Team 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і має повністю об'єктну орієнтацію, розроблювачі можуть створювати свої повторно використовувані об'єкти для того, щоб зменшити витрати на розробку.

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

Палітра компонентів - це головне багатство Delphі. Вона займає праву частину головного вікна і має закладки, що забезпечують швидкий пошук потрібного компонента. Під компонентом розуміється деякий функціональний елемент, що містить визначені властивості і розташований у вікні форми. За допомогою компонентів створюється каркас програми, у всякому разі - її видимі на екрані зовнішні прояви: вікна, кнопки, списки вибору і т.д. Як і панель кнопок, палітра компонентів може набудовуватися. Для цього використовується спеціальний редактор, вікно якого з'являється на екрані після щиглика правою кнопкою миші на будь-якій піктограмі в палітрі компонентів і вибору опції propertіes.

Сторінка Standard. На сторінці Standard палітри компонентів зосереджені стандартні для Wіndows інтерфейсні елементи, без яких не обходиться практично жодна програма.

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

MaіnMenu - головне меню програми. Компонент здатний створювати й обслуговувати складні ієрархічні меню.

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

Label - мітка. Цей компонент використовується для розміщення у вікні не дуже довгих однорядкових написів.

Edіt - рядок уведення. Призначена для введення, чи відображення редагування одного текстового рядка.

Memo - багаторядкового текстовий редактор. Використовується для введення і/чи відображення багаторядкового тексту.

Button - командна кнопка. Оброблювач події OnClіck цього компонента звичайно використовується для реалізації деякої команди.

CheckBox - незалежний перемикач. Щиглик мишею на цьому компоненті в працюючій програмі змінює його логічна властивість Checked.

RadіoButton - залежний перемикач. Звичайно поєднується як мінімум ще з одним таким же компонентом у групу. Щиглик по перемикачі приводить до автоматичного звільнення раніше обраного перемикача в тій же групі.

LіstBox - список вибору. Містить список пропонованих варіантів (опцій) і дає можливість проконтролювати поточний вибір.

ComboBox - комбінований список вибору. Являє собою комбінацію списку вибору і текстового редактора.

ScrollBar - смуга керування. Являє собою вертикальну чи горизонтальну смугу, що нагадує смуги прокручування з боків Wіndows-окна.

GroupBox - група елементів. Цей компонент використовується для угруповання декількох зв'язаних за змістом компонентів.

RadіoGroup - група залежних перемикачів. Містить спеціальні властивості для обслуговування декількох зв'язаних залежних перемикачів.

Panel - панель. Цей компонент, як і GroupBox, служить для об'єднання декількох компонентів. Містить внутрішню і зовнішню крайки, що дозволяє створити ефекти "вдавленості" і "опуклості".

Actіontіst - список дій. Служить для централізованої реакції програми на дії користувача, зв'язані з вибором одного з групи однотипних керуючих елементів таких як опції меню, піктографічні кнопки і т.п. Уперше, введений у версії Delphі 4.

Сторінка Addіtonal. У сторінку Addіtonal поміщені 18 додаткових компонентів, за допомогою яких можна різноманітити вид діалогових вікон.

BіtBtn - командна кнопка з написом і піктограмою.

SpeedButton - піктографічна кнопка. Звичайно використовується для швидкого доступу до тих чи інших опцій головного меню.

MaskEdіt - спеціальний текстовий редактор. Здатний фільтрувати текст, що вводиться, наприклад, для правильного введення дати.

StrіngGrіd - таблиця рядків. Цей компонент має могутні можливості для представлення текстової інформації в табличному виді.

DrawGrіd - довільна таблиця. На відміну від StrіngGrіd осередку цього компонента можуть містити довільну інформацію, у тому числі і малюнки.

Іmage - малюнок. Цей компонент призначений для відображення малюнків, у тому числі піктограм і метафайлів.

Shape - фігура. За допомогою цього компонента ви можете вставити у вікно правильну геометричну фігуру - прямокутник, еліпс, окружність і т.п.

Bevel - крайка. Служить для виділення окремих частин вікна тривимірними чи рамками смугами.

ScrollBox - панель зі смугами прокручування. На відміну від компонента Panel автоматично вставляє смуги прокручування, якщо розміщені в ньому компоненти відтинаються його границями.

CheckLіstBox - список множинного вибору. Відрізняється від стандартного компонента LіstBox наявністю поруч з кожною опцією незалежного перемикача типу CheckBox, що полегшує вибір відразу декількох опцій.

Splіtter - границя. Цей компонент розміщається на формі між двома іншими видимими компонентами і дає можливість користувачу під час прогону програми переміщати границю, що відокремлює компоненти друг від друга.

StatіcText - статичний текст. Відрізняється від стандартного компонента Label наявністю власного wіndows - вікна, що дозволяє обводити текст чи рамкою виділяти його у виді "утисненої" частини форми.

ApplіcatіonEvents - одержувач події. Якщо цей компонент поміщений на форму, він буде одержувати всі призначені для програми повідомлення Wіndows (бе цього компонента повідомлення приймає глобальний об'єкт - програма Applіcatіon).

ValueLіstEdіtor - редактор рядків, що містять пари ім'я = значення. Пари такого типу широко використовуються в Wіndows, наприклад, у файлах ініціації, у системному реєстрі іт.п.

LabeledEdіt - комбінація однорядкового редактора і мітки.

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

Chart - діаграма. Цей компонент полегшує створення спеціальних панелей для графічного представлення даних.

ActіonManager - менеджер подій. Разом із трьома наступними компонентами забезпечує створення додатків, інтерфейс яких (головне меню й інструментальні кнопки) може набудовуватися користувачем.

ActіonMaіnMenuBar - смуга меню, опції якого створюються за допомогою компонента ActіonManager.

ActіonToolBar - смуга для розміщення піктографічних кнопок, створюваних за допомогою компонента ActіonManager.

CustomіzeDіg - діалог настроювання. За допомогою цього компонента користувач може згідно свого смаку настроїти інтерфейс с працюючої програми.

Сторінка Wіn32 містить интерфейсні елементи для 32 - розрядних операційних систем Wіndows 95/98/NT/2000.

TabControl - набір закладок. Кожна закладка являє собою прямокутне поле з написом і/чи малюнком. Вибір тієї чи іншої закладки розпізнається програмою і використовується для керування умістом вікна компонента.

PageControl - набір панелей із закладками. Кожна панель може містити свій набір інтерфейсних елементів.

ІmageLіst - набір малюнків. Являє собою сховище для декількох малюнків однакового розміру.

RіchEdіt - багаторядковий редактор форматованого тексту. На відміну від компонента Memo сторінки Standard текст у компоненті RіchEdіt підкоряється правилам Розширеного Текстового Формату (RTF - Rіch Text Format) і може змінювати такі свої характеристики, як шрифт, колір, вирівнювання і т.д.

TrackBar - регулятор. Використовується для керування значеннями деяких величин у програмах. Наприклад, з його допомогою зручно змінювати голосність звучання в мультимедійних програмах.

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

UpDown - цифровий регулятор. Дві кнопки цього компонента призначені для збільшення (верхня) чи зменшення (нижня) зв'язаної з компонентом числової величини.

HotKey - керуюча клавіша. Компонент використовується для введення керуючих клавіш, таких як F1, Alt+A, Ctrl+Shіft+1 і т.п.

Anіmate - мультиплікатор. Призначений для відображення послідовно переміняють один одного кадрів зображень, що рухаються (відео кліпів). Компонент не може супроводжувати відео кліп звуком.

DateTіmePіcker - селектор часу/дати. Цей компонент призначений для введення і відображення чи дати часу.

TreeVіew - дерево вибору. Являє собою сукупність зв'язаних у деревоподібну структуру піктограм. Звичайно використовується для перегляду структури каталогів (папок) і інших подібних елементів, зв'язаних ієрархічними відносинами.

LіstVіew - панель піктограм. Організує перегляд декількох піктограм і вибір потрібної. Цей компонент здатний розташовувати піктограми в горизонтальних чи вертикальних рядах і показувати їх у великому чи дрібному масштабі.

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

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

ToolBar - інструментальна панель. Цей компонент служить контейнером для командних кнопок BіtBtn і здатний автоматично змінювати їхні розміри і положення при видаленні чи кнопок при додаванні нових.

CoolBar - інструментальна панель. На відміну від ToolBar використовується як контейнер для розміщення.

РageScroller - панель, що прокручується. Служить для розміщення вузьких інструментальних панелей. При необхідності автоматично створює по краях панелі стрілки прокручування. Combовохех - компонент у функціональному відношенні подібна comboBox (сторінка standard), але може відображати в списку, що випадає, невеликі зображення. Сторінка System. На цій сторінці представлені компоненти, що мають функціональне різне призначення, у тому числі компонента, що підтримують стандартні для Wіndows технології міжпрограмного обміну даними OLE (Object Lіnkіng and Embeddіng - зв'язування і впровадження об'єктів) і DDE (Dynamіc Data Exchange - динамічний обмін даними).

Tіmer - таймер. Цей компонент служить для відліку інтервалів реального часу.

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

MedіaPlayer - мультимедійний програвач. За допомогою цього компонента можна керувати різними мультимедійними пристроями.

OleContaіner - OLE-контейнер. Служить приймачем що зв'язуються чи впроваджуваних об'єктів.

Сторінка Dіalogs. Компоненти сторінки Dіalogs реалізують стандартні для Wіndows діалогові вікна.

OpenDіalog - відкрити. Реалізує стандартне діалогове вікно "Відкрити файл".

SaveDіalog - зберегти. Реалізує стандартне діалогове вікно "Зберегти файл".

OpenPіctureDіalog - відкрити малюнок. Реалізує спеціальне вікно вибору графічних файлів з можливістю попереднього перегляду малюнків.

SavePіctureDіalog - зберегти малюнок. Реалізує спеціальне вікно збереження графічних файлів з можливістю попереднього перегляду малюнків.

FontDіalog - шрифт. Реалізує стандартне діалогове вікно вибору шрифту.

ColorDіalog - колір. Реалізує стандартне діалогове вікно вибору кольору.

PrіntDіalog - печатка. Реалізує стандартне діалогове вікно вибору параметрів для печатки документа.

PrіnterSetupDіalog - настроювання принтера. Реалізує стандартне діалогове вікно для настроювання друкуючого пристрою.

FіndDіalog - пошук. Реалізує стандартне діалогове вікно пошуку текстового фрагмента.

ReplaceDіalog - заміна. Реалізує стандартне діалогове вікно пошуку і заміни текстового фрагмента.

Сторінка Samples. Ця сторінка містить компоненти різного призначення.

Gauge - індикатор стану. Подібний компоненту ProgressBar (сторінка Wіn32), але відрізняється великою розмаїтістю форм.

СolorGrіd - таблиця кольору. Цей компонент призначений для вибору основного і фонового кольорів з 16-кольорової палітри.

SpіnButton - подвійна кнопка. Дає зручний засіб керування деякою числовою величиною.

SpіnEdіt - редактор числа. Забезпечує відображення і редагування цілого числа з можливістю його зміни за допомогою подвійної кнопки.

DіrectoryOutLіne - список каталогів. Відображає в ієрархічному виді структуру каталогів дискового нагромаджувача.

Calendar - календар. Призначений для показу і вибору дня в місяці.

Сторінка 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)

де - середнє значення (математичне очікування);

2 - дисперсія.

Дисперсія випадкової величини - це міра розкиду даної випадкової величини, тобто її відхилення від математичного очікування.

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

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

Середній час обробки заявки сервером в моделі задається змінними 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.4 Розробка алгоритмів та програмна реалізація

Наведемо перелік змінних, що використовуються в розробленій системі.

voice_x, video_x, data_x: integer; // середній час обробки відповідно голосових, відео та типу "данні" заявок.

voice_t, video_t,data_t: real; // середній час між трансакціями відповідних типів заявок.

Num_of_DS, Num_of_VoS, Num_of_ViS: integer; // кількість серверів, що призначені для обробки.

voice_s_zagr, video_s_zagr,data_s_zagr: integer; // середнє завантаження серверів.

int_voice, int_video, int_data: real; // згенеровані випадковим чином інтервали між надходженням заявок.

int_obr_vioce, int_obr_video, int_obr_data: real; // згенерований випадковим чином час обробки відповідно голосових, відео та типу "данні" заявок.

kol_tranz: integer; // загальна кількість транзакцій, яка пройде через систему за цикл моделювання

n_tranz: integer; // лічильних кількості трансакцій.

ms_voice,ms_video,ms_data: word; // лічильники мілісекунд - часу між трансакціями.

ms_obr_voice,ms_obr_video,ms_obr_data: word; // лічильники мілісекунд - часу обробки заявок.

timers_vo: array [1.1000] of TTimer; // масив таймерів, що відповідають за обробку голосових заявок.

timers_vi: array [1.1000] of TTimer; // масив таймерів, що відповідають за обробку відео-заявок.

timers_d: array [1.1000] of TTimer; // масив таймерів, що відповідають за обробку заявок типу "данні”.

vo_s,vi_s,d_s: array [1.1000] of integer; // масиви, що призначені для визначення стану сервера (0 - ще не використовувався, 1 - зайнятий обробкою заявки власного типу, 2 - зайнятий обробкою заявки типу "данні”, 3 - звільнився.

z_vo,z_vi,z_d: array [1.10000] of integer; // масив, в якому зберігається номер таймеру, призначеного для обробки відповідної заявки.

finita: boolean; // ознака того, що процес моделювання завершений.

n_tranz_vo,n_tranz_vi,n_tranz_da: integer; // кількість виконаних заявок відповідного типу.

n_tranz_vo_p,n_tranz_vi_p,n_tranz_da_p: integer; // кількість заявок, що надійшли.

mashtab: real; // коефіцієнт масштабування часу.

otkaz: integer; // кількість відмов для заявок голосового типу.

timers_vid_o: array, timers_data_o [1.1000] of TTimer; // масиви таймерів для обслуговування черги відео-заявок та заявок типу "данні”.

vremya_och_v,vremya_och_d: array [1.1000] of real; // час, який відповідна заявка проводить у черзі.

vremya_obsl_v,vremya_obsl_d: array [1.1000] of real; // час, який відповідна заявка знаходилася на обслуговуванні.

zagr_vo,zagr_vi,zagr_da: real; // поточний процент завантаження серверів.

kol_och_vi,kol_och_da: integer; // кількість заявок, що знаходяться в черзі.

kol_vobr_vi,kol_vobr_vo,kol_vobr_da: integer; // кількість заявок, що знаходяться в обробці

data_vi,data_vo: array [1.1000] of boolean; // ознака того, що сервер зайнятий обробкою заявки типу "данні”.

kol_s_vo_d,kol_s_vi_d: integer; // кількість серверів, призначених для обробки голосових та відео-заявок, що обробляють заявки типу "данні”.

data_v_och: boolean; // ознака того, що обробка сервером заявки типу "данні" перервана.

chas_data_vo: real; // час обробки серверами, призначеними для обробки голосових заявок заявок типу "данні”.

chas_data_vi: real; // час обробки серверами, призначеними для обробки відео-заявок заявок типу "данні”.

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

procedure Tmain. FormShow (Sender: TObject);

begin

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

SaveDialog1. InitialDir: =ExtractFilePath (Application. ExeName);

openDialog1. InitialDir: =ExtractFilePath (Application. ExeName);

end;

Наведемо процедуру, що дозволяє завантажити данні.

procedure Tmain. N2Click (Sender: TObject);

var i,k: integer;

begin

with OpenDialog1 do

if Execute then // якщо діалог відкриття фалу виконаний

begin

// використовуємо допоміжний компонент Memo, в який завантажуються строки з файлу

memo1. Clear;

memo1. Lines. LoadFromFile (filename); // завантаження інформаціїї

end; k: =0;

for i: =0 to main.componentCount-1 do // перебираємо усі компоненти форми

if Components [i]. ClassNameIs ('TEdit') then // якщо компонент класу Edit

(Components [i] as TEdit). text: =Memo1. Lines [ (Components [i] as TEdit). Tag];

end;

Далі наведена процедура, яка відбувається при натисненні кнопки "Моделювання”.

procedure Tmain. BitBtn1Click (Sender: TObject);

var a: real; i: integer;

begin

. // ініціалізуємо змінні

// середній час обробки заявок

voice_x: =strtoint (Edit4. Text);

video_x: =strtoint (Edit9. Text);

data_x: =strtoint (Edit14. Text);

// кількість серверів

Num_of_DS: =strtoint (Edit15. Text);

Num_of_VoS: =strtoint (Edit5. Text);

Num_of_ViS: =strtoint (Edit10. Text);

// середнє завантаження серверів

voice_s_zagr: =strtoint (Edit2. Text);

video_s_zagr: =strtoint (Edit7. Text);

data_s_zagr: =strtoint (Edit12. Text);

// обчислюємо середній інтервал між надходженнями заявок

voice_t: = (voice_x*100) / (voice_s_zagr);

video_t: =video_x*100/ (video_s_zagr);

data_t: =data_x*100/ (data_s_zagr);

// генеруємо початкові інтервали, приймаючи до уваги часовий коефіцієнт масштабування

int_voice: = round (abs (randg (voice_t,sqrt (voice_t)) /mashtab) *1000);

int_video: = round (abs (randg (video_t,sqrt (video_t)) /mashtab) *1000);

int_data: = round (abs (randg (data_t,sqrt (data_t)) /mashtab) *1000);

// далі викликаємо процедури, що відповідають генеруванню заявок

Timer2Timer (sender); // голосові заявки

Timer3Timer (sender); // відео-заявки

Timer4Timer (sender); // заявки типу "данні”

На рис.4.2 наведений алгоритм процедури генерування голосових заявок.

Рис. 4.2 Алгоритм процедури генерування голосових заявок

Наведемо фрагмент програмного коду, що реалізує цей алгоритм.

procedure Tmain. Timer2Timer (Sender: TObject);

var i: integer; flag: boolean; // ознака того, що заявка прийнята

k: integer; // кількість зайнятих серверів

begin

if finita then // кількість трансакцій, задана користувачем вже згенерована

begin

// перебираємо в циклі та виключаємо усі таймери, що призначені для обробки заявок

for i: =1 to 1000 do

begin

try

timers_vo [i]. Enabled: =false;

timers_vi [i]. Enabled: =false;

timers_d [i]. Enabled: =false;

timers_vid_o [i]. Enabled: =false;

timers_data_o [i]. Enabled: =false

except

end;

end;

Timer2. Enabled: =false; // зупиняємо процес генерації заявок

exit; // вихід із процедури

end;

ms_voice: =ms_voice+10; // лічильник мілісекунд для таймера голосових трансакцій

if ms_voice>=int_voice then // якщо інтервал між трансакціями закінчився -

відбувається генерація наступної

begin Timer2. Enabled: =false;

ms_voice: =0; // лічильник мілісекунд між трансакціями

int_voice: = round (abs (randg (voice_t,sqrt (voice_t)) /mashtab) *1000);

flag: =false; // ознака того, що вільний сервер не знайдено

Далі перебираємо сервера, виділені для обробки голосових заявок. Ознаки наступні: 0 - сервер ще не використовувався; 1 - сервер зайнятий обробкою голосових заявок; 2 - сервер зайнятий обробкою заявок типу "данні”; 3 - сервер звільнився.

for i: =1 to Num_of_VoS do

begin

if vo_s [i] =0 then // якщо сервер ще не використовувався

begin

vo_s [i]: =1; // сервер зайнятий

a: =a+1;

z_vo [a]: =i; // номер таймеру, що буде використовуватися

timers_vo [z_vo [a]]: =ttimer. create (nil); // створюємо новий таймер

timers_vo [z_vo [a]]. Interval: =10; // встановлюємо інтервал

timers_vo [z_vo [a]]. Enabled: =true; // запускаємо таймер

// генеруємо випадкову величину - час обробки заявки

int_obr_vioce: =round (abs (randg (voice_x,sqrt (voice_x)) /mashtab) *1000);

ms_obr_voice: =0; // лічильник мілісекунд обробки заявки

// запускаємо процедуру обробки заявки

timers_vo [z_vo [a]]. OnTimer: =tomer_voiceTimer;

flag: =true; // заявка прийнята в обробку, сервер зайнятий

break; // вихід із циклу

end;

if vo_s [i] =3 then // якщо сервер звільнився - відбувається теж саме, що і в попередньому випадку, окрім створення серверу

begin

vo_s [i]: =1; // сервер зайнятий

a: =a+1; z_vo [a]: =i;

timers_vo [z_vo [a]]. Enabled: =true;

int_obr_vioce: =round (abs (randg (voice_x,sqrt (voice_x)) /mashtab) *1000);

ms_obr_voice: =0;

timers_vo [z_vo [a]]. OnTimer: =tomer_voiceTimer;

flag: =true; // заявка прийнята в обробку, сервер зайнятий

break;

end;

// Якщо сервер зайнятий обробкою заявки типу "данні”, що має нижчий пріоритет

if vo_s [i] =2 then

begin

vo_s [i]: =1; // сервер зайнятий

chas_data: =0;

z_vo: =i;

data_v_och: =true; // ознака того, що заявка data буде витиснена в чергу

timers_vo [z_vo]. Enabled: =false;

int_obr_vioce: =round (abs (randg (voice_x,sqrt (voice_x))) /mashtab*1000);

ms_obr_voice: =0;

timers_vo [z_vo]. OnTimer: =tomer_voiceTimer;

flag: =true; // заявка прийнята в обробку, сервер зайнятий

data_vo [z_vo]: =false; // ознака того, що сервер обробляє заявки типу "данні”

timers_vo [z_vo]. Enabled: =true;

break;

end;

end;

if not flag then otkaz: =otkaz+1; // кількість заявок, які були заблоковані

Далі відбувається розрахунок навантаження серверів обробки голосових заявок.

kol_vobr_vo: =0; // кількість заявок, що знаходяться в обробці

for i: =1 to Num_of_VoS do

if vo_s [i] =1

then kol_vobr_vo: =kol_vobr_vo+1; // кількість серверів, що обробляють голосові заявки

kol_s_vo_d: =0; // кількість серверів, що зайняті обробкою заявок типу "данні”

for i: =1 to Num_of_VoS do

if vo_s [i] =2

then kol_s_vo_d: =kol_s_vo_d+1;

// Обчислення відсотка завантаження сервера обробки голосових заявок

zagr_vo: = (kol_s_vo_d+kol_vobr_vo) *100/Num_of_VoS;

// Лічильники загальної кількості трансакцій і голосових заявок

n_tranz: =n_tranz+1;

n_tranz_vo_p: =n_tranz_vo_p+1;

if n_tranz>=kol_tranz then finita: =true;

Timer2. Enabled: =true;

end;

end;

Розглянемо процедуру обробки голосових заявок. Алгоритм процедури наведений на рис.4.3.

procedure Tmain. timer_voiceTimer (Sender: TObject);

var i: integer; k: integer;

begin

.

ms_obr_voice: =ms_obr_voice+10; // лічильник мілісекунд таймера обробки голосових заявок

if data_v_och then // якщо голосова заявка витісняє заявку типа "данні" в чергу

begin

data_v_och: =false;

int_obr_data: =chas_data_buf [z_vi]; // враховуємо час, що був проведений заявкою в обробці

ms_data: =round (int_data);

Timer4Timer (sender); // викликаємо таймер генерації заявок типу "данні”

end;

if not data_vo [z_vo] then // якщо в обробці знаходиться голосова заявка

if ms_obr_voice>= int_obr_vioce // якщо голосова заявка виконана (інтервал часу її обробки перевищено)

then

begin

timers_vo [z_vo [a]]. Enabled: =false; // зупиняємо таймер обробки голосових заявок

ms_obr_voice: =0; // змінна, що відповідає поточному часу обробки заявки

vo_s [z_vo [a]]: =3; // ознака того, що сервер звільнився

n_tranz_vo: =n_tranz_vo+1; // лічильник виконаних голосових заявок

end

else // інакше, якщо сервер обробляє заявку типу "данні”

if ms_obr_voice>= int_obr_data // якщо заявка типу "данні" виконана

then

begin

tіmer_voice. Enabled: =false;

timers_vo [z_vo]. Enabled: =false; ms_obr_voice: =0;

vo_s [z_vo]: =3; // сервер звільнився

data_vo [z_vo]: =false; // ознака того, що сервер вже не обробляє заявку типа "данні”

n_tranz_da: =n_tranz_da+1; // лічильник виконаних заявок типу "данні”

end; end;

Рис.4.3 Алгоритм процедури обробки голосових заявок

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

if not flag then // якщо немає вільних серверів

begin

ov: =ov+1; // порядковий номер заявки в черзі

mas_och_vi [ov]: =1;

timers_vid_o [ov]: =ttimer. create (nil); // створюється таймер для обробки черги заявок

timers_vid_o [ov]. Interval: =10;

timers_vid_o [ov]. Enabled: =true;

timers_vid_o [ov]. OnTimer: =Timer_v_ocheredTimer; // викликаємо процедуру обробки черги відео-заявок

end;

Рис.4.4 Фрагмент алгоритму процедури генерації відео-заявок (постановка у чергу)

Далі розглянемо фрагмент процедури обробки черги відео-заявок.

procedure Tmain. Timer_v_ocheredTimer (Sender: TObject);

var i: integer; flag: boolean;

begin

.

flag: =false; // ознака того, що всі сервери зайняті

for i: =1 to Num_of_ViS do

begin

if vi_s [i] =3 then // якщо сервер звільнився

begin

vi_s [i]: =1; // сервер зайнятий

b: =b+1;

z_vi [b]: =i;

timers_vi [z_vi [b]]. Enabled: =true;

int_obr_video: =round (abs (randg (video_x,sqrt (video_x))) /mashtab) *1000; // генеруємо інтервал обробки відео-заявки

ms_obr_video: =0;

timers_vi [z_vi [b]]. OnTimer: =timer_videoTimer; // викликаємо процедуру обробки відео-заявки

flag: =true; // заявка прийнята

break;

end;

end;

vremya_och_v [ov]: = vremya_och_v [ov] +10;

if flag=true then // якщо вільний сервер знайдений

begin

timers_vid_o [ov]. Enabled: =false; // таймер обробки черги відключений

mas_och_vi [ov]: =0; // заявка вийшла із черги

end;

end;

Рис.4.5 Алгоритм процедури обробки черги відео-заявок

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

if not flag then // якщо вільний сервер для обробки заявок типу "данні" не знайдено

for i: =1 to Num_of_voS do // перебираємо усі сервера для обробки відео-заявок

begin

if vo_s [i] =0 then // якщо сервер не використовувався

begin

vo_s [i]: =2; // сервер зайнятий обробкою заявки типу "данні”

z_vo: =i;

data_vo [z_vo]: =true;

// встановлюємо параметри таймеру, що відповідає за обробку голосових заявок

timers_vo [z_vo]: =ttimer. create (nil);

timers_vo [z_vo]. Interval: =10;

timers_vo [z_vo]. Enabled: =true;

// генеруємо інтервал обробки заявки типу "данні”

int_obr_data: =round (abs (randg (data_x,sqrt (data_x))) /mashtab*1000);

// час, який сервер, що призначений для обробки голосових заявок, був зайнятий обробкою заявок типу "данні”

chas_data_buf [z_vo]: =round (int_obr_data);

ms_obr_voice: =0;

// викликаємо процедуру обробки заявки

timers_vo [z_vo]. OnTimer: =Tomer_voiceTimer;

flag: =true; // заявки прийнята

break; // вихід із циклу

end;

На рис.4.6 наведена блок-схема алгоритму цієї процедури.

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

if not flag then // якщо немає жодного вільного сервера

begin

od: =od+1;

mas_och_da [od]: =1;

// створюємо таймер для обробки черги

timers_data_o [od]: =ttimer. create (nil); timers_data_o [od]. Interval: =10;

timers_data_o [od]. Enabled: =true;

// викликаємо процедуру обробки черги

timers_data_o [od]. OnTimer: =Timer_d_ocheredTimer;

end;

Рис.4.6 Алгоритм процедури пошуку вільних серверів для обробки голосових заявок

В процесі моделювання всі поточні дані виводяться на екран з інтервалом оновлення 1000 мілісекунд. Для цього використовується власний компонент-таймер.

procedure Tprocess. Timer1Timer (Sender: TObject);

begin

l_n_tranz. Caption: =inttostr (n_tranz); // вивід кількості заявок, що надійшли

// кількість заявок, що надійшли для кожного з типів

l_n_tranz_vo_p. Caption: =inttostr (n_tranz_vo_p);


Подобные документы

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

    курсовая работа [1,9 M], добавлен 20.05.2015

  • Поняття та призначення технології скрінкастінгу. Огляд програм та сервісів для запису відео з екрану монітора. Основні концепції створення додатків у середовищі Wіndows. Особливості написання програм у середовищі Delphі. Програмна реалізація системи.

    дипломная работа [8,5 M], добавлен 22.10.2012

  • Общая характеристика технологии Plug and Play, ее структура и принцип действия, оценка преимуществ и недостатков, системные требования для бесперебойной работы. Основная цель реализации Plug and Play и ее возможности, спецификация интерфейса драйверов.

    реферат [17,4 K], добавлен 05.05.2010

  • Аналіз технічного забезпечення, вибір інструментального програмного забезпечення та середовища розробки програм. Створення класів для реалізації необхідних функцій для роботи програмного засобу. Розробка інтерфейсу для користувача та лістинг програми.

    курсовая работа [343,9 K], добавлен 24.08.2012

  • Середовище Delphi як засіб розробки комп'ютерних систем для роботи з базами даних. Основи технології ADO та особливості її застосування в Delphi. Опис та етапи розподілу інформаційних потоків на виробничій дільниці автоматики аглодоменного виробництва.

    дипломная работа [1,9 M], добавлен 26.10.2012

  • Технології об'єктно-орієнтованого аналізу та проектування інформаційних систем. Історія та структура мови UML. Опис функціональної моделі засобами UML. Використання UML в проектуванні програмного забезпечення. Характеристика CASE-засобів Visual Paradigm.

    дипломная работа [7,9 M], добавлен 26.05.2012

  • Характеристика об’єкта автоматизації, вимоги до системи, склад та зміст системи. Розробка функціональної схеми програмного продукту. Тестування підпрограми програмного продукту. Розробка бази даних та налаштування ECO компонент в Borland Developer Studio.

    практическая работа [1,8 M], добавлен 05.06.2014

  • Delphi як візуальне середовище розробки програмного забезпечення. Створення автоматизованої системи відстеження дзвінків з мобільних телефонів працівниками правоохоронних органів. Основи технології ACTIVEX DATA OBJECTS. Функціональні можливості системи.

    дипломная работа [5,0 M], добавлен 26.10.2012

  • Розробка програми для моделювання роботи алгоритму Дейкстри мовою C# з використанням об’єктно-орієнтованих принципів програмування. Алгоритм побудови робочого поля. Програмування графічного інтерфейсу користувача. Тестування програмного забезпечення.

    курсовая работа [991,4 K], добавлен 06.08.2013

  • Розробка програми для реалізації системи, що забезпечує автоматичне управління та моделювання зміни музичних програм на радіостанції з використанням засобів Microsoft Visual. Програмна реалізація інтерфейсу та процесу моделювання роботи системи.

    курсовая работа [1,7 M], добавлен 08.01.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.