3.4.3. Підходи до моделювання ПрО мовними засобами dsl

Останні роки сформувался предметно–орієнтований підхід до опису проблематики деякої предметної області за допомогою мови DSL, проблемно–орієнтованого проектування DDD (Domain–Driven Design) та збирання ПС з готових КПВ, тощо. Підходу DDD відповідає систематичний підхід до розробки ПС для складних ПрО, що дозволяє створити базовану на моделі ПрО спільну мову (ubiquitous language) [2] для розробників СПС, як мова спілкування різних категорій розробників, так і мовою документування усіх етапів ЖЦ, метою якого є проведення вдосконалення (рефакторінгу) системи не на рівні коду, а на рівні базованих на ПрО моделей вимог, проектування, архітектури. При цьому модельним класам присвоюються наймення та повноваження реальних класів понять реального світу, які мають бути достатніми для організації їхньої взаємодії задля вирішення покладених на них задач. Спільна мова визначає ключові моменти:

– визначення ядра складної ПрО та визначення її ключових відмінностей;

– визначення неявних понять ПрО та перетворення їх на явні;

– визначення ЖЦ об`єктів моделювання вподовж розробки як бази трасування вимог на об`єкти кодування;

– застосування патернів для аналізу ПрО [3];

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

Вирішення наведених проблем дозволить задати єдину мову аналізу, документування та обміну думками між членами команди розробників протягом ЖЦ розробки моделі ПрО.

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

– представлення – відповідає за надання послуг, відображення даних, обробку подій, спричинених користувацьким інтерфейсом (клацання миші, клавіатури), обслуговування сітьових звернень, підтримку функцій командної стрічки та API пакетного виконання;

– домен – відповідає за бізнес–логіку прикладного застосування;

– джерело даних – відповідає за звернення до баз даних, обмін повідомленнями, управління транзакціями.

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

Модель ПрО тестується як бізнес–правила у формі дотримання вимог. Таким чином підхід DDD поєднається з підходом керованого тестами проектування TDT (Test Driven Design).

Процес розроблення ПС або домену включає багаторівневий аналіз ПрО для встановлення єдиної термінології, вживаної розробниками сімейства і його членів (рис.3) та визначення компонентів, як готових ресурсів [12, 29, 30].

Готові програми зберігаються в багаточисельних бібліотеках (Matlab, IP, Demral і тому подібне), в репозітаріях e-science, Інтернеті, в названих системах загального призначення і (Rational Rose .NET, Sun IBM, Microsofts і ін.), а також у фірмах і організаціях розробників [3–7].

Із загальної точки зору, такі програми – ці готові ресурси (компоненти, сервіси, агенти, сервіси і ін.) для інтеграції їх в системи або сімейства систем, а також для організації обчислення завдань (фізичних, математичних, біологічних і тому подібне) у сучасних середовищах з використанням прикладних, проблемних і наукових бібліотек .Проте при організації обчислень на нових комп'ютерах, майнфреймах і кластерах виникають проблеми несумісності ЯП, старих і нових програмних ресурсів по організації в них фундаментальних структур і типів даних [8–13].

Вона набуває особливої актуальності ще по наступних причинах [3, 14, 15]:

Рис.3. Рівні аналізу домену

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

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

3. Широке поширення Інтернет технологій привів до створення нових мов опису даних і документів (XML, RDF, OWL і ін.) вимагає глибокого осмислення завдань передачі, перенесення і обробки даних в нових мережевих умовах типа Grid.

.На більш високому рівні аналізу доменів визначаються спільні архітектурні рішення для сімейства систем домену, ще вище – множина компонентів повторного використання (КПВ) для частини або всіх систем у сімействі. І, нарешті, він має забезпечувати часткову або повну підготовку КПВ для автоматизованої зборки компонентів із застосуванням генераторів і/або конфігураторів, включаючи для цього не програмні артефакти (тести, настанови тощо). На найвищому рівні процесу проектування ПС створюється опис моделі домену мовою DSL, яка повинна автоматизовано генеруватися відповідними інструментальними засобами [12. 21].

Опис ПрО мовою DSL

Предметна область може бути описана загальними мовами GPL (General-Purpose Language) або DSL (Domain Specific Language).

Мова DSL призначенаий для опису синтаксису об’єктів МПі трансформації цього опису до описів Exсel, HTML, SQL, Matlab тощо. Їх спільною рисою є прив`язка їх виразних засобів до конкретної ПрО, тобто використання понятійної бази та нотації, звичних для певної ПрО, шляхом звуження сфери застосування, завдяки чому досягається більша виразність та зручність інтерфейсів користувача, зокрема, візуальних і, як наслідок, підвищення продуктивності праці та зменшення вартості супроводження.

Мова DSL є специфічною для визначеної ПрО, вона на відміну від універсальних мов програмування – General Purpose Language або GPL оперує понятійними об’єктами ПрО. Вона базується на ідеї створення бібліотеки компонентів для прикладних застосувань відповідної ПрО та розробки інтерфейсів для її використання, які би базувалися на притаманній ПрО термінології для назв класів об`єктів та методів (операцій або функцій), до яких користувач міг би звернутися після створення об`єкту. Але це не завжди можливо з ряду причин:

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

– абстракції та конструкції ПрО не мають прямої відповідності з окремими компонентами або фрагментами GPL;

DSL є своєрідною формою представлення знань про КПВ для вирішення прикладних задач в межах конкретної ПрО. До таких знань у DSL, зокрема належать такі:

– виразні засоби мови користувача – граматика, формати виразів. інтерфейси;

– абстракції моделі ПрО;

– проектні рішення реалізації моделі, а саме архітектура, генератори коду.

ЖЦ з використання DSL включає традиційні процеси аналізу ПрО з метою виявлення властивостей і характеристик об`єктів та пошуку за ними готових. Створення моделі ПрО містить визначення:

– словнику понять та онтології відповідних їм об`єктів;

– опис змісту понять;

– моделі характеристик, які визначають спільні для ПрО властивості понять, властивості, які можна варіювати для окремих конкретних екземплярів понять (об`єктів), та їх взаємозалежності.

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

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

Зараз існує нізка засобів підтримки DSL – Eclipce? Protégé, Tool DSL MS.Net тощо. Кожний з них має:

– власний склад інструментальних засобів (редактор, аналізатор, верифікатор, генератор коду тощо), які при змінах ПрО мусять забезпечити еволюцію, моніторинг змін ПрО та здатність до зміни деякиї елементів ПрО;.

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

Одним із сучасних підходів по опису ПрО є генераційне програмування []. В ному є засоби опису ПрО – простір проблем (абстракції, притаманні ПрО) і простір рішень (абстракції реалізацій понять ПрО). Їх зв’язує GDM модель і виконує відображення цих просторів за моделями характеристик. Простір задач містить у собі поняття ПрО майбутній ПС, нові компоненти та КПВ за відповідними об'єктами і їх характеристиками. Основою простора проблем є модель функціональних характеристик щодо компонентів і об’єктів, змінювані параметри різних членів сімейства та проектні рішення, зв'язані з операціями взаємодії членів сімейства між собою і з середовищем.

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

Результати опису домену у цих просторах об’єднує конфігураційна база знань, в якої зберігаються зв’язки й характеристик (функціональні або не функціональні) членів сімейства, операції конструювання та об’єднання компонентів у спільну систему за моделлю GDM. В базисі конфігурації відображені знання про конфігурацію системи у вигляді абстракцій загального і спеціального призначення, а також елементів типу КПВ. В ньому зберігаються технологічні знання про виробництво нових компонентів, засоби їх експертизи, тестування, вимірювання та оцінювання. На базисі конфігурації визначаються завдання ПрО та їх опис у відповідної мові.

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

Ці два простору перетворюються конфігураційним або трансформаційним способом. Конфігураційний спосіб базується на конструкторських правилах, які оптимізують концепції, особливості та характерні риси домену й перевіряють їхні комбінації в моделі GDM. Результат – конфігурація членів сімейства у вигляді конфігураційного файла. Опис специфіки домену може трансформуватися в опис МП компонентів для простору задач з подальшим їх генеруванням засобами теорії мов і мовних перекладів. Тобто, модель СПС, що описана сучасними мова типу DSL, може бути доведена до вихідного коду з використанням моделей конфігураційного або трансформаційного типу [29, 30].

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

Рис.4. Модель конфігураційного типу для реалізації домену

Після відображення цей простір містить множину компонентів (КПВ, reuse), схеми зборки готових компонентів, варіанти архітектур деяких членів сімейства.

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

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

Трансформаційна модель. Модель домену, що описана мовою DSL, перетворюється з простору проблем в простір рішень шляхом трансформації DSL–специфікації моделі домену або систем сімейства у реалізацію окремих їх членів МП (рис. 5).

Головним механізмом переходу від опису наведених моделей до вихідного результату є трансформація описів понять ПрО (домену) у проміжну мову DSL простору рішень, а далі у мову реалізації окремих компонентів з урахуванням платформи, де розташовані готові компоненти і/або нові реалізовані мовами задачі з простору

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

Рис. 5. Модель трансформаційного типу для домену

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