К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
– система, написана мовою Java, для створення розподілених ПС; Weave.NET – проект реалізації механізму підтримки АОП без прив'язки до конкретної МП усередині компонентної моделі .NET Framework і ін. Розділ 5 121 У процесі створення ПС із застосуванням аспектів можуть використовуватися: ІP-бібліотека розширень, що містить у собі їх коди, а також активні бібліотеки, мова програмування SmallTalk, розширені засоби опису аспектів [17]. В ІР-бібліотецірозміщені деякі функції компіляторів, методів, засобів оптимізації, редагування, відображення тощо. Наприклад, бібліотека матриць, за допомогою якої обчислюються вирази з масивами, забезпечує швидкість виконання, надання пам'яті й т.п. Використання таких бібліотек у розширених середовищах програмування називають родовим програмуванням, а вирішення проблем економії, перебудови компіляторів під кожне нове мовне розширення, використання шаблонів і результатів попередньої обробки відносять до області ментального програмування [17]. Бібліотека IP містить у собі: окремі функції компіляторів, засоби оптимізації, редагування, відображення понять, перебудови окремих компонентів компіляторів під нове мовне розширення, а також засоби програмування на основі шаблонів і т.п. Бібліотеки з такими можливостями одержали назву бібліотек генерації. Інший вид бібліотек АОП – активні бібліотеки, які містять у собі не тільки базовий код реалізації понять ПрО, а й цільовий код забезпечення оптимізації, адаптації, візуалізації й редагування. Активні бібліотеки поповнюються засобами й інструментами інтелектуалізації агентів, за допомогою яких забезпечується розроблення спеціалізованих агентів для реалізації конкретних задач ПрО. 5.1.6. Генерувальне (порождувальне) програмування Генерувальне програмування (generative programming) – це методи і засоби генерації сімейств систем і застосувань з окремих компонентів, аспектів, КПВ, каркасів і ін. Базис цього програмування – ООП, доповнене механізмами генерації багаторазових елементів і КПВ, а також властивостями їхньої змінюваності, взаємодії й ін. [17]. Це програмування є новим видом програмування, в ньому використовуються різні методи інженерії складних ПрО для розроблення сімейств ПС із різних виготовлених раніше програмних продуктів, згенерованих програмних застосувань і систем, сімейств систем, члени яких задовольняють певні показники якості. Головний продукт інженерії ПрО – це сімейство ПС, яке генерується на основі загальної генерувальної моделі домену GDM (Generative Domain Model), що містить у собі засоби визначення окремих членів (представників) сімейства, до яких відносять предметно-орієнтовану мову DSL (Domain Specific Language), методи генерації окремих членів і їх збирання у сімейство, а також базу конфігурації для розгортання сімейства або його членів у середовищі. Кожен член сімейства створюється з окремих компонентів. Це створення планується, контролюється й оцінюється після інтеграційного тестування на якість, а також обліку витрат на використання КПВ, у тому числі готових, узятих, наприклад, з активної бібліотеки [17]. Елементи цієї бібліотеки – цільовий код засобів забезпечення компіляції, налагодження, візуалізації й ін. Фактично компоненти бібліотеки – це інтелектуальні агенти, що генерують нові агенти в розширюваному середовищі програмування для розв’язання конкретних задач ПрО. У ньому містяться спеціальні метапрограми, тобто програми, що генерують інші програми, і 122 Розділ 5 компоненти бібліотеки для здійснення збирання згенерованих компонентів і поповнення ними цього середовища для майбутнього створення нових членів сімейства з компонентів багаторазового використання. Задачі простору проблем предметної області або окремих членів сімейства, як правило, визначаються різними предметно-орієнтованими мовами. В даному випадку термін «мова» використовується в загальному розумінні. Тобто така мова може бути подана як засіб опису специфічних понять ПрО, різних аспектів функціонування задач за допомогою операції взаємодії членів сімейств або їх складових і т.п. Поняття ПрО можуть бути поданні також процедурами, функціями, методами, як в ООП. Вони, як відомо, зберігаються в бібліотеках або вбудовуються в універсальну мову програмування (наприклад у С++, С# тощо). Коли в таку мову додаються різного типу абстракції опису різних задач ПрО, її називають модульною предметно-орієнтованою мовою. Задачі можуть бути функціонального (наприклад, бухгалтерські, кадрові тощо) та системного (наприклад, захист даних, безпека, взаємодія тощо) типів. Специфікація задач домену може виконуватися декількома предметно– орієнтованими мовами, кожній з них притаманна своя специфічна мова. До предметно-орієнтованих мов відносять такі: – мова опису специфіки домену; – мова опису функціональних задач домену; – мова опису аспектів взаємодії, синхронізації компонентів у середовищі; – мова опису захисту даних та безпеки виконання сімейства систем; – мова опису інтерфейсів (PDL, IDL тощо). Предметно-орієнтована мова – DSL. Вона вналежить до класу мов опису специфіки ПрО або домену, властивої саме цьому домену. Опис кожного члена сімейства може містить мову опису специфіки задач домену і генеруючої моделі домену GDM (Generative Domain Model), яка відображає склад домену із членів сімейства, специфікованих також у предметно-орієнтованих мовах. Мова DSL не є новим винаходом, оскільки загальні абстракції програмування були визначені й вбудовані в мови загального призначення. І хоча мова DSL створюється багато років і для кожної ПрО є свій варіант мови, її застосування для специфікації особливостей ПрО не забезпечує формування повного уявлення про предметну область, оскільки вона дає лише засоби визначення загальних рис ПрО. Відомо, що будь-яка мова має визначену область застосування, проте мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль, Кобол), що створювалися для розв’язання конкретних типів задач (обчислювальних, економічних). Порівняно з ними, DSL близька до описових мов, таких, як HTML, XML. Вона має специфічні особливості порівняно з мовами загального призначення, а саме: – абстракції DSL забезпечують визначення концепцій і абстрактних понять у предметній області; – синтаксис мови DSL може надавати засоби природного опису понять домену і запобігати синтаксичній неузгодженості, що буває при використанні мови загального призначення; – перевірка опису в DSL вимагає статичних аналізаторів, що можуть знайти більше помилок, ніж аналізатори загального призначення, і дати повідомлення про них цією ж мовою, що є більш зрозумілим для фахівців у предметній області; Розділ 5 123 – оптимізація коду за описом в DSL базується на знаннях, що не є доступними компілятору з мови загального призначення; – інструменти підтримки DSL потребують відповідного оточення, наприклад, середовища, редактора, контролера версій тощо. Специфікована в DSL модель ПрО є загальною моделлю GDM (рис.5.10). Простір рішень - прості компоненти - їхнє сполучення - взаємодія - адаптація Знання про конфігурації - зв’язки характеристик - залежності - правила конструювання - варіанти оптимізації Простір проблеми - предметні поняття ПрО - поняття системи - характеристики об’єктів - готові компоненти Рис.5.10. Структура генерувальної моделі GDM Модель відображає: – поняття, характеристики ПрО і членів сімейства в просторі проблем; – набір членів сімейства і їхніх специфікацій у мовах типу DSL, RAISE (Rigorous Approach to Industrial Software Engineering), RSL (RAISE Specification Language) і ін.; – задачі ПрО в просторі задач для їхньої реалізації компонентами і з наступним їхнім збиранням в конфігурацію визначених членів сімейства; – знання про конфігурацію (Configuration knowledge), що відображають характеристики членів сімейства, і їхнє поєднання в конфігурації; – модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства і правила конструювання систем сімейства з урахуванням їхньої залежності один від одного і від компонентів типу КПВ; – архітектуру (каркас) сімейства систем; – реалізацію компонентів архітектури у мовах програмування. Генерувальне програмування чітко поділяється на дві частини дослідження і проектування продукту ПрО – формування опису простору проблеми і простору розв’язків задач ПрО [5]. Перша частина призначена для проведення аналізу ПрО, виявлення її задач, які потрібно реалізувати, а друга – для розроблення засобів реалізації цих задач. Ці частини об’єднує конфігураційна і трансформаційна база знань про конфігурацію, тим самим утворюючи структуру моделі генерації у ПрО (або GDM) розроблюваних ПС (див. вищі рис.5.10). Простір проблеми (problem space) містить у собі поняття ПрО та майбутньої системи, що будується за допомогою компонентів та КПВ, об'єкти та їхні характеристики тощо. Основою простору проблем є модель функціональних характеристик, властивості компонентів і об’єктів, змінювані параметри різних членів сімейства, а також проектні рішення, обумовлені особливостями взаємодії членів сімейства між собою і з середовищем. У базисі конфігурації відображені знання про конфігурацію системи подані звязками, правилами конструювання і характеристиками загального і спеціального призначення, а також елементів з активної бібліотеки багаторазового використання. Крім того, у ньому зберігаються технологічні знання про виготовлення 124 Розділ 5 компонентів, засоби їхнього тестування, планування, налагодження і вимірювання. В базисі конфігурації визначаються задачі ПрО і дається їх опис у відповідній мовній парадигмі. Простір рішень (solution space) – це компоненти, каркаси, шаблони проектування ПрО, а також засоби їхнього з'єднання або вбудування в ПС і оцінки повноти. Елементи цього простору реалізують розв’язання задач ПрО. Каркас системи або сімейства систем оснащений механізмом зміни параметрів, що вимагають фрагментації множини дрібних методів і класів. Він забезпечує створення багаторазових і використовуваних розв’язків у різних типах ПС, а також використання аспектів синхронізації, взаємодії і захисту даних за допомогою технології JavaBeans та нових механізмів композиції і генерації у деякому середовищі, наприклад, Eclipsе. Простір проблем відбивається у простір задач за допомогою GDM моделі. Простір проблем містить у собі групу абстракцій, залежних від особливостей ПрО, які специфікуються так, щоб виразити поняття ПрО мовою, найбільш близькою до конкретного домену, і які можуть використовуватися для уточнення сутності того або іншого члена сімейства. Абстракції простору впливають на реалізацію компонентів мовою програмування в просторі, де розв’язуються задачі. Вони можуть бути змінені, якщо залежали від специфіки мови опису домену або від змінюваних особливостей області. Перетворення простору проблем у простір задач проводиться конфігураційним або трансформаційним способом. При конфігураційному способі використовують конструкторські правила й оптимізатори для додавання характерних рис до специфікації домену з урахуванням концепції домену, а також для перевірки комбінацій особливостей і залежностей в моделі GDM. Як результат утворюється конфігурація компонентів системи. Опис специфіки домену трансформується в опис мови реалізації компонентів простору розв’язання задач. Тобто перетворення опису ПрО у мову програмування відбувається шляхом генерації з використанням теорії мов і мовних перетворень. Іншим способом перетворення (відображення) між просторами є трансформація DSL-специфікації у реалізацію на мові програмування. Простір проблеми може бути не суцільним, а розділеним за окремими аспектами проблем. Залежно від аспекту проблеми трансформація може відбуватися не лише безпосередньо у мову реалізації, а й у іншу DSL-мову. Оскільки при конфігураційному способі простір проблеми (загальні та особливі характеристики і обмеження) фактично визначає проблемно-орієнтовану мову, а множина компонентів у просторі рішень у мовах програмування можуть розглядатися як елементи реалізації. Конфігураційний спосіб можна інтерпретувати як окремий випадок трансформаційного способу. У генерувальному програмуванні головним об’єктом є КПВ. Він використовується при створенні членів сімейства за двома інженерними напрямами [11–14]: 1) прикладна інженерія (Application Engineering) – процес розроблення конкретних систем, так званих одиночних програм, із КПВ, а також із застосуванням раніше створених незалежних ПС у різних середовищах; 2) інженерія ПрО (Domain Engineering) – побудова архітектури членів сімейства або самого сімейства систем шляхом використання КПВ, які зафіксовані Розділ 5 125 у сховищах, а також частин і членів сімейства систем конкретної ПрО, отриманих за моделлю GDM (більш докладно див. розділ 9). У цих напрямах інженерії моделювання архітектури здійснюється за модельно-орієнтованим підходом і завершується побудовою архітектури MDA (Model Driven Architecture). Моделювання MDA-архітектури відбувається на двох рівнях – платформо незалежному (за допомогою моделі PIM, Platform Independent Model) і платформо залежному (за допомогою моделей PSM, Platform Specific Models). Таке моделювання підтримує концепцію відображення простору у простір задач. Тобто в моделі сімейства ПС члени сімейства можуть мати спільні функції, але вони розрізняються платформами реалізації. Вибір альтернативних платформ – є «точкою варіантності» у сімействі. Ця точка знаходиться над моделлю ПС, тобто вона невидима на її рівні. Керування «точкою варіантності» платформ відбувається через трансформацію PIM→PSM без участі розробника. Члени сімейства ПрО розрізняються не тільки на рівні платформи реалізації, а й на рівні функцій ПС, вимог до якості та інфраструктури, тобто застосовних ресурсів, які реалізують альтернативні концепції. Вибір різних концепцій зумовлює появу різних прикладних моделей (моделей ПС), які автоматично трансформуються в традиційну модель MDА. Головними ресурсами вказаних двох напрямів інженерії є не тільки КПВ, а й різні елементи (активи) сімейства систем, наприклад, описи спільних і різних характеристик представників сімейства в моделі характеристик. Вибрані КПВ вбудовуються в нові чле ни сімейства ПС зі сховищ домену, а саме, з репозитарію. Технологія розробки сімейства програм для ПрО містить у собі три види базових процесів: – розробка ПрО й одиночних програм; – повторне використання ресурсів; – менеджмент домену. Розробка ПрО з КПВ є конвеєрною. Для ПрО плануються базові ресурси, якими можуть бути КПВ, програми, генератори, DSL-описи, моделі аналізу, документація й ін. Проектування в ПрО одиночних програм у прикладній інженерії базується на програмуванні з повторним використанням, де конкретні програми містять у собі різні готові ресурси (assets), які можуть бути і КПВ. Розробка ПрО є більш складним виробничим процесом, який містить у собі загальні етапи: аналіз, проектування і впровадження. Аналіз ПрО зводиться до подання сімейства як множини програмних систем, які треба побудувати, з урахуванням загальних і різних рис, а також структурних і поведінкових специфікацій окремих членів сімейства. Цей аналіз починається з формулювання і специфікації вимог до ПС- членів сімейства і сімейства загалом. Специфікація вимог – це вхідна інформація для ручного або автоматичного створення домену з готових ресурсів. Після специфікації будується архітектура системи, в яку вміщуються запрограмовані члени сімейства та готові прикладні системи. Повторне використання ресурсів стосується різних ресурсів для ПрО і методів їх використання. Ресурси можуть бути повторними і відображатися в загальній архітектурі (моделі) сімейства, а також у всіх членах сімейства ПрО. Сукупність цих ресурсів може бути частково або цілком автоматизована за 126 Розділ 5 допомогою генераторів або конфігураторів готових ресурсів. Згенеровані продукти сімейства можуть містити у собі і методичні артефакти, наприклад, інструкції з користування DSL і компонентами домену. Менеджмент домену – це керування конвеєрним розробленням з повторним використанням ресурсів. Він передбачає планування і контроль підбору типових для ПрО ресурсів, їхню оцінку і перевірку на задоволення вимог. У задачу менеджменту входить також перевірка застосовності готових ресурсів для реалізації специфіки ПрО і організація програмування компонентів простору задач відповідно до потреб клієнтів домену. Таким чином, інженерія ПрО охоплює: – аналіз ПрО і виявлення об'єктів і відношень між ними; – визначення області дій об'єктів ПрО; – визначення загальних функціональних і змінюваних характеристик, побудова моделі характеристик; – створення базису для інженерії виробництва конкретних прикладних членів сімейства з механізмами змінюваності незалежно від засобів їхньої реалізації; – підбір і підготовка компонентів багаторазового застосування для задач ПрО; – генерація окремих членів сімейства або домену в цілому. Етапи цієї схеми забезпечують формування моделі ПрО і моделі характеристик, як елементів простору проблем. Вони трансформуються в архітектуру системи й опис її компонентів, які об’єднуються у окремі системи для забезпечення розв’язання задач ПрО у просторі рішень. Як готові ресурси в інженерії ПрО можуть використовуватися відомі горизонтальні і вертикальні типи компонентів загального призначення , що реалізовані зокрема в моделі CORBA [14]. Горизонтальні типи компонентів – це з агальні системні засоби, що потрібні різним членам сімейства, а саме, графічні інтерфейси користувача, СКБД, бібліотеки розрахунку матриць, контейнери, каркаси і т.п. До вертикальних типів компонентів належать прикладні системи (медичні, біологічні, наукові і т.д.), а також компоненти горизонтального типу з обслуговування архітектури багаторазового застосування компонентів і їхніх інтерфейсів. Приклад системи підтримки інженерії ПрО і застосування горизонтальних методів – система DEMRAL [14, 17], призначена для розробки бібліотек: чисельного аналізу, графових обчислень і т.д. Основні види елементів цієї бібліотеки – абстрактні типи даних (abstract data types) і алгоритми. DEMRAL підтримує інженерію домену за допомогою бібліотек чисельного аналізу, обробки зображень тощо. Крім цього, ця система дозволяє моделювати характеристики ПрО і зображати їх у характеристичній моделі, а також в предметно-орієнтованих мовах опису членів ПС конфігурації. Система конструювання RSEB призначена для використання вертикальних методів, а також КПВ і сценаріїв, як інструментів діаграмного проектування архітектури системи. Методи вертикального типу можуть викликати різні горизонтальні методи, що входять до різних прикладних підсистем. При роботі над окремою частиною сімейства можуть застосовуватися аспекти взаємодії, потоків |