ДонНТУ

Компонентно-базована розробка моделюючого програмного забезпечення для розподілених паралельних моделюючих середовищ (РПМС)

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

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

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

    Дана проблема вимагає рішення наступного ряду задач:

• розгляд парадигм розробки програмного забезпечення;
• вивчення компонентно-базованого підходу програмування;
• аналіз архітектури класичного розподіленого паралельного моделюючого середовища;
• поділ розподіленого паралельного моделюючого середовища на підсистеми;
• зіставлення підсистем моделюючого середовища і компонент;
• реалізація компонент розподіленого паралельного моделюючого середовища.

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

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

    IT-сфера  — одна з індустрій, що розвиваються найбільш швидко. Постійно змінюються вимоги, які пред’являються до моделюючих середовищ: складність, об'єкт моделювання, закони опису моделі.

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

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

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

    Локальний (за матеріалами викладачів, аспірантів і магістрантів ДонНТУ). Розглядом проблем, пов'язаних з реалізацією розподілених паралельних моделюючих середовищ, займалися:

1. Feldmann L. P.,Svjatnyj V. A., Resch M., Zeitz M. FORSCHUNGSGEBIET: PARALLELE SIMULATIONSTECHNIK.
У цій доповіді розглядається архітектура РПМС, принципи його створення та декомпозиція на підсистеми

2. Войтов А.В. Тема магістерської роботи «Розробка паралельного MIMD-симулятора, 2 рівень розпаралелювання»

3. Степанов І.С. Тема магістерської роботи «Розподілене паралельне моделююче середовище»

4. Назаренко К.С. Тема магістерської роботи «MIMD-симулятор і оптимізатор паралельних моделей дискретних динамічних систем»

5. Зима К.М. Тема магістерської роботи «ПАРАЛЕЛЬНЕ МОДЕЛЮЮЧЕ СЕРЕДОВИЩЕ ДЛЯ ДИСКРЕТНИХ СИСТЕМ»

    При пошуку розробок за даною темою на національному рівні було знайдено наступне джерело:

6. Томашевський В.М. Моделювання систем.  — К.: Видавнича група BHV, 2005  — c. 9-14.
У книзі розглядаються питання моделювання систем, систем масового обслуговування та імітаційного моделювання

    На світовому рівні знайдені наступні публікації за темою:

7. Jozsef Tick, Special Aspects of Component Based Software Development

8. Crnkovic I., Larsson M. Component-Based Software Engineering – New Paradigm of Software Development
Останні два джерела описують компонентно-базоване програмування: його принципи, переваги, історію, алгоритми створення додатків.

9. Feldmann L. P.,Svjatnyj V. A., Resch M., Zeitz M. FORSCHUNGSGEBIET: PARALLELE SIMULATIONSTECHNIK.

    З моменту появи програмування як окремої галузі науки і промисловості, його постійно переслідують різні зміни і нововведення. Це пов'язано з тим, що людина ще не знайшла ідеальної технології розробки програмних і апаратних комплексів. Тому час від часу на програмування, як хвилі, набігають ідеї кардинальних змін, пошуку панацеї. Вчені виділяють кілька етапів еволюції у напрямках створення програмного забезпечення. Наприклад, в [7] автор пропонує наступну структуру:

• мови машинного рівня;
• мови програмування низького рівня;
• мови програмування високого рівня.

    Мови з перших двох груп зараз не використовуються, або мають дуже вузьке коло застосування. Найбільше поширення мають мови програмування високого рівня. Їх використання є найбільш зручним для виконання більшості завдань. Вони створені таким чином, щоб людина інтуїтивно могла розуміти тексти програм. Але й серед них є велика різноманітність ідей у написанні коду. В [2] виділяється наступна класифікація мов програмування високого рівня:

• «Спагеті код» (Фортран). Цей період прийшов на зміну мов програмування низького рівня. У той час це був прорив у галузі, нова ера. Але зараз ми скоріше побачимо недоліки цього етапу: надто малий функціонал, складна компіляція, код, що погано читається. Однак, це був старт нової епохи.
• «Розділяй і володарюй». Програми стали занадто великі і складні у розумінні. Рішення проблеми знайшлося у розділенні коду на частини. Ними стали процедури, функції, модулі. На деякий час це дало спокій вченим і програмістам. Але згодом, з розвитком техніки, і цього перестало вистачати.
• «Світ структурований» (Паскаль, Ада, С). Цей період настав у сімдесятих роках минулого сторіччя. Вчені остаточно зрозуміли, що програмування повинно бути структурованим. Мови програмування були збагачені новими технологіями, які давали рішення проблем протягом декількох десятиліть.
• «Думай об'єктно-орієнтовано» (С++, Java, C#). Ця нова парадигма настала після ери структурованого програмування. Вона встановила новий, вищий рівень інтеграції між даними та операціями над ними, що дозволило поєднувати їх в логічні одиниці.
• «Компонентно-базовані технології». Подальший розвиток науки дав життя ще одній ідеї. Насправді, вона не була новою. Вперше її висловили на відомій конференції НАТО присвяченій розробці програмного забезпечення в 1968 році в Гарміші (Німеччина). Але був потрібний час, щоб ця парадигма втілилася в життя. Вона витікала з ідеї об'єктно-орієнтованого програмування. Програма повинна як і раніше складатися з частин. Але їм надається інше призначення та важливість. Компоненти стають окремими багатофункціональними модулями, які можуть працювати окремо, повторно використовуватися. В даний час це абсолютно нова парадигма в програмуванні, що дозволило зробити новий крок у розвитку цифрових технологій.

    У [3] наводиться наступне визначення для напрямку компонентно-базованого програмування:

    «Компонентно-орієнтоване програмування (англ. component-oriented programming)  — одна з парадигм програмування, виникла як свого роду дисципліна, тобто набір певних обмежень, що накладаються на механізм об'єктно-орієнтованого програмування (ООП), коли стало зрозуміло, що безконтрольне застосування ООП призводить до виникнення проблем з надійністю великих програмних комплексів. Це так звана проблема крихких базових типів (англ. fragile base class problem): проявляється при спробі змінити реалізацію базового типу (базового класу), коли порушується функціонування класів-нащадків.»

    Окрема компонента – це програмний пакет або модуль, який вміщує в собі певний набір функцій або даних.

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

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

    Коротко основні особливості та переваги використання компонентно-базованого підходу у програмуванні можна сформулювати наступним чином [2]:

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

    Цикл розробки компонентно-базованого програмного забезпечення має певні етапи, дотримання яких робить роботу більш економічною та продуктивною [4]:

1. Пошук компонент, що можуть бути використаними у проекті. На цьому етапі робиться перелік всіх можливих варіантів для подальшого розгляду;
2. Вибір компонент, що найбільш підходять вимогам проекту;
3. Розробка компонент, які не були знайдені серед вже розроблених раніше;
4. Повна адаптація всіх компонент до вимог, які є у проекті;
5. Збір та запуск проекту;
6. Етап перевірки та тестування. Заміна, встановлення або усунення деяких компонент. Це може стати потрібним, якщо під час тестування було виявлено недоліки, було додано нові функції. Цей етап поступово переходить у повномасштабне використання проекту.

    Описану методику зображено на рис. 1.

Рисунок 1  — Методика компонентно-базованої розробки проектів (Анімація складається з 5 кадрів з затримкою 700 мс між кадрами; затримка до повторного відтворення становить 1200 мс; кількість циклів відтворення обмежено 7-а, розмір 770*264, 109 кБ, створено в MP GIF Animator)

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

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

    У [5] наведено структуру РПМС, зображену на рис. 2. РПМС розглядається як складна HW/SW-система. Воно може бути розділене на відносно незалежні та паралельно працюючі підсистеми, залежно від функцій, які вони виконують. Це дає змогу по іншому уявити процес розробки таких моделюючих середовищ.

    Беручи за основу структуру РПМС, зображену на рисунку 2, можна виділити наступні компоненти, виділені згідно функцій, покладених на них, [5]:

1. Підсистема діалогу  — призначена для презентації РПМС. Виконує наступні задачі: діалог та навчання розробника та користувача; взаємодія з усіма ресурсами середовища; узгодження завдань симуляції, планування та керування цим процесом.
2. Підсистема топологічного аналізу  — словесний та графічний опис кодування для первинних топологій; декомпозиція та апроксимація отриманих вторинних топологій; формування актуальних векторів та матриць; перетворення топологічних даних в форму, придатну для генерування рівнянь; видача результатів аналізу топології.
3. Підсистема генерування рівнянь  — комунікація з підсистемою топологічного аналізу; перетворення результатів її роботи у векторно-матричний вигляд; генерування дискретних симуляційних моделей для вирішення чисельними засобами, якими володіє середовище; візуалізація результатів.
4. Підсистема віртуальних паралельних симуляційних моделей  — інтерактивне відображення ієрархії віртуальних паралельних симуляційних моделей в залежності від можливих варіантів розпаралелювання; топології, створені в підсистемі топологічного аналізу, приводяться у відповідність рівням віртуальної паралельної симуляційної моделі; формування систем рівнянь для всіх рівнів моделі; інтерактивна підготовка способів реалізації дискретної віртуальної паралельної симуляційної моделі.
5. Підсистема паралельного вирішення рівнянь  — взаємодія з підсистемами топологічного аналізу та віртуальної паралельної симуляційної моделі; видача способів реалізації дискретних моделей; вирішення систем рівнянь за допомогою паралельних бібліотек; визначення збіжності, стабільності, точності, оптимізація варійованих параметрів; перетворення результатів вирішення для наочного представлення.
6. Підсистема обміну даними  — включає список компонентів та ресурсів РПМС; обмін даними за сигналом від компонент; відображення потоків даних за ініціативою користувача; система тестування для визначення параметрів мережі передачі даних; оптимізація паралельної програми за допомогою обмінних операцій.
7. Система балансування навантаження  — визначення рівня навантаження між віртуальними процесами та процесорами; балансування навантаження між ними; порівняльний аналіз підходів розпаралелювання за критеріями розподілу навантаження.
8. Підсистема візуалізації  — інтеграція з GUI та підсистемою вирішення рівнянь; підготовка результатів симуляції для візуалізації; інтерактивне відображення графіків під час та після проведення симуляційного експерименту.
9. Підсистема зберігання даних  — взаємодіє з усіма підсистемами та зберігає всю можливу інформацію про середовище (дані про ПЗ та апаратну архітектуру, користувацькі дані, дані про моделювання, перетворення та симулювання систем); архівація деяких послідовних та паралельних програм, що пригідні для можливого використання; дані про тести, заплановані експерименті та архівація їх результатів.
10. Підсистема IT-підтримки  — організація розподілених обчислювальних, комунікаційних та симуляційних ресурсів згідно з технологіями сучасних мереж; віддалений WEB-базований додаток для моделювання та симуляції; функціонування ланцюгів «WEB-клієнт (розробник моделі)  — WEB-сервер  — PARSIMULATOR (паралельний симулятор)» та «WEB-клієнт (розробник моделі)  — WEB-сервер  — DATABASE (сервер баз даних)»; інтеграція з іншими підсистемами.

Рисунок 2 – Системна організація РПМС

   Розподілені паралельні моделюючі середовища набувають більш складних рис. Їх розробка та експлуатація стають набагато складнішими. Тому для розробки РПМС потрібно використовувати нові технології, які враховуватимуть властивості як програмного забезпечення, так і апаратної частини.

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

1. Томашевський В.М. Моделювання систем.  — К.: Видавнича група BHV, 2005  — c. 9-14.
2. Tick J. Special Aspects of Component Based Software Development / Інтернет ресурс.  — Режим доступу: http://citeseerx.ist.psu.edu/viewdoc/download~.pdf
3. Компонентно-орієнтоване програмування / Вікіпедія / Інтернет ресурс.  — Режим доступу: http://uk.wikipedia.org/wiki/Компонентно-орієнтоване_програмування
4. Crnkovic I., Larsson M. Component-Based Software Engineering  — New Paradigm of Software Development. / Malardalen University Sweden / Інтернет ресурс.  — Режим доступу: http://www.mrtc.mdh.se/publications/0293.pdf
5. Feldmann L. P., Svjatnyj V. A., Resch M., Zeitz M. FORSCHUNGSGEBIET: PARALLELE SIMULATIONSTECHNIK. / Сайт национальной библиотеки им. В.И. Вернадского / Інтернет ресурс.  — Режим доступу: http://www.nbuv.gov.ua/portal/natural/Npdntu/Pm/2008/08flpfps.pdf
6. Что такое компонентно-ориентированное программирование (краткая справка) / РОССИЙСКАЯ АКАДЕМИЯ НАУК Институт ядерных исследований / Інтернет ресурс.  — Режим доступу: http://www.inr.ac.ru/~info21/info/qtocop.htm
7. История развития языков программирования / Сайт программирования / Інтернет ресурс.  — Режим доступу: http://life-prog.ru/view_articles.php?id=41
8. Эволюция языков программирования / Школьные страницы / Інтернет ресурс.  — Режим доступу: http://schools.keldysh.ru/sch444/MUSEUM/LANR/evol.htm
9. История языков программирования / Википедия / Інтернет ресурс.  — Режим доступу: http://ru.wikipedia.org/wiki/История_языков_программирования
10. Component-based software engineering / Wikipedia / Інтернет ресурс.  — Режим доступу: http://en.wikipedia.org/wiki/Component-based_software_engineering
11. Компонентно-ориентированное программирование / Википедия / Інтернет ресурс.  — Режим доступу: http://ru.wikipedia.org/wiki/Компонентно-ориентированное_программирование

Copyright © Стародубцев Д.М. 2010 ДонНТУ