К. М. Лавріщева програмна інженерія підручник Київ, 2008
 Скачать 5.23 Mb.
|
|
in | out | inout (вхідний, вихідний, разом вхідний і вихідний). Тип даних описується засобами мов програмування (C++, Pascal і т.п.) і забезпечує взаємодію між процесами, а параметри <вид параметра> можуть бути: in – вхідний параметр, out – вихідний параметр, inout – параметр, через який передаються та повертаються дані. Приклад фрагменту мови опису інтерфейсу наближений до опису в мові IDL для середовища CORBA. Interface Vlst ( status add_item ( in identifier item_name in type code item_type in long value_len ); statгs free_memory ( ); statгs get _count ( out long count ); ); 8.2. Прикладна інженерія та інженерія предметної області Інженерія програмування заснована на інженерії КПВ, що розглянуто вище, містить у собі ще прикладну інженерію і інженерію ПрО. Вони використовують готові КПВ, унікальні програми після інженерії КПВ, а також окремі частини сімейства систем з компонентів багаторазового застосування та прикладні системи із сімейства. [2–5, 13]. Як уже зазначалося, прикладна інженерія, або інженерія застосувань – це інженерія побудови прикладної системи (Application) на основі її Розділ 8 221 моделі, вибраних готових КПВ та заново розроблених компонентів, що реалізують окремі задачі цієї системи, а інженерія ПрО орієнтована на створення архітектури ПрО – каркаса (framework), що містить у соб КПВ, компоненти багаторазового застосування з сімейства програм різних доменів і інтерфейси компонентів, а також готові застосування, розроблені методами прикладної інженерії, як готові члени сімейства. Кожний член сімейства повинен мати відображення своєї специфіки на мові високого рівня – DSL (Domain Specific Language), яка зараз широко використовується розробниками ПрО. На загальному рівні ця мова складається з трьох частин: – метамодель, що відображає абстрактно синтаксис при визначенні специфіки ПрО і правила опису специфіки ПрО, необхідної для розробки моделі генерації GMD (Generative Model Development); – конкретного синтаксису МП для опису нотацій моделі GMD та інших моделей ПрО; – семантичного опису змісту всіх моделей. Моделі ПрО, описані за допомогою однієї DSL, можуть бути трансформовані в моделі, що описані за допомогою іншої DSL. Це дозволяє інтегрувати між собою різні частини системи, написані на різних DSL. ПрО може бути описана на одному рівні абстракції, а потім перетвориться на більш низькі рівні абстракції, що дозволяє доповнювати модель GMD на різних процесах розробки системи. Мова DSL дає можливість автоматизувати реструктуризацію, інтеграцію і розгортання системи на основі опису специфіки моделі домену, набудованої на деяку МП. Ця модель може містити у собі інформацію про збирання артефактів, використаних у ній, а також установлювати залежності між артефактами, включаючи конфігурацію програм, що виконуються, обсяги апаратних і програмних ресурсів, необхідних цим програмам. 8.2.1. Прикладна інженерія Інженерія застосувань (applications), або прикладна інженерія, входить до інженерії ПрО, як складова її частина. Сутність цієї інженерії полягає у виробництві окремих членів сімейства або нових КПВ, багаторазово використовуваних проектних рішень при генерації окремих членів сімейства систем. Ця інженерія компонентних застосувань містить у собі процеси створення прикладної системи і їхній менеджмент. Процес створення починається з аналізу предметної області, задачі якої автоматизуються, побудови концептуальної моделі, на основі якої створюється компонентна модель, що вміщує проектні рішення з пошуку і збирання компонентів, використання різних типів шаблонів, зв'язків між ними й операцій розгортки ПС у середовищі функціонування. Будь-яка інженерія, як колективна діяльність, потребує менеджмент. Менеджмент – це керування створенням прикладної системи, яке складається з розподілу робіт між кожним учасником, створення графіка цих робіт для контролю їхнього виконання відповідно до заданих термінів і оцінювання якості як окремого компонента, так і сукупності компонентів, що взаємодіють. Перелічимо етапи інженерного процесу створення ПС з компонентів, враховуючи, що компоненти розміщуються в репозитарії. 222 Розділ 8 1. Пошук, вибір КПВ і розроблення нових компонентів, виходячи із системи класифікації компонентів і їхньої каталогізації, формалізоване визначення специфікацій інтерфейсів, поведінки і функціональності компонентів, а також їхнього анотування і розміщення в репозитарії системи або в Інтернеті. 2. Розроблення вимог (Requirements) до ПС, тобто – це формування й опис функціональних, нефункціональних і інших властивостей ПС. 3. Аналіз поведінки (Behavioral Analysis) ПС – визначення функцій системи, деталей проектування і методів реалізації функції, кожний з яких має відповідну поведінку. 4. Специфікація інтерфейсів і взаємодій компонентів (Interface and Interaction Specification) відбиває розподіл ролей компонентів, інтерфейсів, їхню ідентифікацію і взаємодію через робочі потоки (workflow). 5. Збирання застосувань і повторне використання компонентів (Application Assembly and Component Reuse) ґрунтується на підборі й адаптації КПВ, визначенні сукупності правил, умов інтеграції і побудові конфігурації каркаса системи. 6. Тестування компонентів і середовища (Component Testing) ґрунтується на методах верифікації і тестування для перевірки правильності як окремих компонентів і КПВ, так і інтегрованої з компонентів ПС. 7. Розгортка (System Deployment) містить у собі оптимізацію плану компонентної конфігурації з урахуванням середовища, розгортання окремих компонентів і створення цільової компонентної конфігурації для функціонування ПС. 8. Супровід ПС (System Support and Maintenance) складається з аналізу помилок і відмов при функціонуванні ПС, пошуку і виправленні помилок, повторного його тестування й адаптації нових компонентів до вимог і умов інтегрованого середовища. Цей процес є ітераційним. У ньому можна повертатися на попередні етапи у випадку невиконання деякого правила або вимоги. На кожному з названих процесів проводиться менеджмент, тобто перевіряється правильність його виконання і відповідність вимогам, що сформульовані для системи. Виявлення помилок на останньому процесі може призвести до повторення деяких перелічених пунктів, коли або з’являються нові обставини у замовника, або усуваються деякі помилки. 8.2.2. Інженерія сімейства систем домена Інженерія домену або ПрО призначена для побудови сімейства систем з урахуванням задач домену, загальних і змінюваних характеристик представників сімейства в моделі характеристик. Вибрані КПВ або одиночні програмні застосування знаходять в репозитарії і вбудовують у нові члени сімейства ПС. Інженерія ПрО базується на різних видах мови опису специфіки предметної області в мові DSL [4, 6, 13]. Мова DSL має виразну особливість, спрямовану на відображення специфіки предметної області. Тоді як мови загального призначення (Java, C++ і ін.) створювалися для задоволення будь-якого типу програм. Мова DSL не є новим винаходом, оскільки в неї були вбудовані загальні абстракції програмування. І хоча мова DSL створюється багато років для кожних нових ПрО, систематичне її Розділ 8 223 застосування для специфікації особливостей ПрО ще не є загальноприйнятою практикою. Будь-яка мова має свою визначену область застосування, мова DSL є більш спеціалізованою, ніж інші мови програмування (Паскаль або Кобол), які створювалися з визначеною метою. Порівнянно з ними DSL близька до спеціалізованих мов, таких, як HTML, XML. Характеристика мови DSL для опису специфіки ПрО. Прівнянно з мовами загального призначення ця мова має [6]: – абстракції, які забезпечують визначення концепцій і абстрактних понять із предметної області; – синтаксис, призначений для природного представлення понять домену і запобігання синтаксичній неузгодженості понять ПрО; – опис в DSL вимагає наявності спеціалізованих статичних аналізаторів для перевірки синтаксису, щоб знайти помилки в описі специфікації моделі, і подати з них відомості уією мовою; – оптимізація коду за описом в DSL базується на знаннях про цю область і це не доступно компіляторам МП загального призначення; – інструменти підтримки DSL вимагають оточення, наприклад, середовища, редактора, засобу контролю версій і т.п.; – предметні абстракції в мовах програмування базуються на використанні бібліотек програм і КПВ, визначених користувачем функцій, класів і структур даних. Специфікована в DSL модель ПрО є загальною моделлю генерації домену GDM, що відбиває: – поняття, характеристики ПрО і членів сімейства в просторі проблем; – набір членів сімейства і їхніх специфікацій у мовах типу DSL, RSL, CSP і ін.; – задачі ПрО в просторі задач для їхньої реалізації компонентами і з наступним збиранням їх у конфігурацію визначених членів сімейства; – знання про конфігурацію (Configuration knowledge) відбивають характеристики членів сімейства і їхнє об’єднання в конфігурації; – модель характеристик (feature models) відображає загальні, змінювані і незмінні характеристики членів сімейства, а також правила конструювання систем сімейства з урахуванням їхніх взаємозв’язків і залежності від КПВ; – архітектуру (каркас) сімейства систем; – реалізацію компонентів архітектури у мовах програмування. При проектуванні каркаса або моделі ПрО у вигляді моделі GDM можуть задаватися механізми змінювання, синхронізації, безпеки з використанням аспектного програмування. Головною частиною моделі ПрО є моделі характеристик, що призначені для подання вимог до сімейств ПС, різних характеристик систем, що входять до складу ПрО та застосування КПВ. Ці моделі поділені на дві категорії [6]: – моделі характеристик FODA (Feature-oriented Development Architecture), FORM (Feature-oriented Reuse Method), RSEB (Reuse-Driven Software Engineering Business), FeatureRSEB (з інтеграцією у RSEB–діаграм характеристик з FODAcom) тощо [13], – моделі варіантів сценаріїв використання (Use Case Variants) [14]. 224 Розділ 8 У першу категорію потрапляють традиційні методології моделювання, використовувані при побудові ПС, у другу – методології, засновані на аналізі сценаріїв діяльності потенційних користувачів ПС у ПрО, що будуються за допомогою UML (Sequence diagrams та Activity diagrams). Про трансформацію DSL опису моделей ПрО. Як було сказано раніше, модельпредметної області М про є загальною моделлю GDM домену, який складається з декількох моделей окремих прикладних систем М про1 , М про2 , ..., М проN Кожна з цих моделей відображає поняття і специфіку відповідної системи із сімейства систем домену. На їхньому перетині існують загальні поняття, характеристики і обмеження, які відображаються у моделі характеристик ПрО. Опис кожної моделі М проi виконується відповідною проблемно-орієнтованою DSL i мовою. Цей опис трансформується безпосередньо у відповідну МП i , тобто мову реалізації (рис.8.3), або у іншу DSL j мову, яка потім трансформується у МП. Рис. 8.3. Схема трансформація моделей прикладних систем Після трансформації опис моделей М про1 , М про2 , ..., М проN , що отриманий у МП, транслюється до вихідного коду того середовища, де цей код буде функціонувати. Крім того, вибрані КПВ і знову розроблені компоненти для окремих функцій простору проблем також описуються відповідними МП, і отже, можуть розглядатися як елементи реалізації завдань у просторі задач. Перебудова до вихідного коду залежить також від платформи, коцепція якої буде розглянута нижче. Даний підхід подання моделей ПрО відповідає відомій модельно-керованій розробці MDD (Model Driven Development). Відповідно до цієї моделі архітектури системи моделюються на двох рівнях – платформа незалежного рівня за моделлю PIM (Platform Independent Model) і платформа залежного рівня за моделлю PSM (Platform Specific Models). Концепції дворівневого моделювання архітектури MDA (Model Driven Architecture) і відображення PIM→PSM безпосередньо відповідають наведеній ідеології побудови сімейства ПрО, які базуються на відображенні опису М проi моделей прикладних систем (Application model) у DSL-мовах у МП (рис.8.4). Відповідно до підходу MDD моделі прикладних систем у моделі сімейства ПС відображають члени сімейства. Вони мають спільні функції, але розрізняються платформами реалізації. Розділ 8 225 Рис.8.4. Схема трансформації прикладної моделі до платформи Вибору альтернативної платформи відповідає точка варіантності у сімействі систем. Ця точка невидима на рівні конкретної ПС і при керуванні варіантами платформ з ней почінається автоматично виконання шляхом трансформації PIM→PSM, розробник не бере участі в цьому. Зазначимо, що члени сімейства розрізняються не лише на рівні платформи реалізації, а й на рівні функцій ПС, вимог до якості, які реалізують альтернативні концепції. У такому випадку до моделі ПрО додається точка, де можуть бути подані необхідні альтернативні концепції. Моделювання архітектури сімейства за характеристиками. Моделювання архітектури сімейства виконується за підходом, орієнтованим на характеристики (feature-oriented approach) її членів. Архітектура сімейства систем містить у собі окремі члени і «успадковує» еталонну архітектуру у просторі рішень (реалізації) генерувального програмування. Ця архітектура формується у просторі проблем таким чином, щоб різні комбінації характеристик цієї архітектури могли бути застосовані як компоненти реалізації простору рішень та і у кінцевому програмному продукту сімейства. Архітектура сімейства може бути подана у вигляді генерувальної предметно-орієнтованої мови зразка, яка визначає архітектурний стиль ПС сімейства за інваріантами систем, механізмами мінливості та еволюційного її розвитку через подання комбінацій відповідних шаблонів проектування цієї архітектури. При цьому доменна модель ПС сімейства розширюється шляхом залучення до неї інваріантних понять та характеристик членів системи відповідно до певних їх критеріїв та предметно-орієнтованого опису цієї моделі засобами відповідного DSL для опису проблем або задач, що створюють область перспектив. При аналізі завдань домену досліджуються інформаційні джерела простору проблем, будується модель характеристик (feature model), що відображає загальні і змінні характеристики членів систем в сімействі, їх властивості і сполучення, а також опис проблем кожного члена мовою DSL (рис.8.5). Ця модель використовується для подання архітектури системи і визначення компонентів для деяких задач домену. 226 Розділ 8 Інформаційні джерела домену Модель характеристик Архітектура і компоненти ПрО Аналіз домену Область задач Мови DSL для опису проблем Область проблем Рис.8.5. Схема побудови моделі характеристик ПрО Характеристика – це властивість членів сімейства, яка доступна користувачу системи и можуть бути обов’язковою, необов’язковою або альтернативною. До них відносять інтерфейсні, проектні, продуктивні та реалізаційні характеристики. Вони відображаються у моделі характеристик відповідними діаграмами орієнтованого графа домену. Ця модель відбуває область дії сімейства систем і здатність до змінювання архітектури і її компонентів. В ній містяться знання щодо конфігурації системи, яка застосовується при автоматизованому виробництві членів сімейства. Доменна модель може розглядатись як метамодель предметно-орієнтованих описів моделей сімейства DSL з механізмами підвищення рівня абстракцій подання сімейства ПС для запровадження цих механізмів до реалізації окремих членів сімейства. При цьому інструментальні засоби повинні забезпечувати відображення характеристик членів сімейства з простору проблемних задач у простір рішень з трасуванням таких відображень. Розроблення архітектури домену виконується у просторі проблем і є їхньою проекцією на модель характеристик. Цей простір конкретизується на прикладних і аспектних характеристиках, які виконуються у компонентах простору рішень. У моделі характеристик прикладними можуть бути архітектурні шаблони, які слугують реалізації архітектури сімейства систем. Методологія розробки домену. На основі мови DSL створено методологію розробки домену MDD, що базується на генеративної моделі домену GDM (Generative Domain Model), яка специфікується [7]. Методологія містить у собі: – модельно-керовану архітектуру MDA, що використовує мову моделювання UML для подання архітектури системи і її конкретні профілі для різних платформ; – модельно-інтегровану обробку MIC (Model-Integrated Computing) для реалізації елементів системи і їхніх зв'язків за допомогою засобів предметно- орієнтованої мови моделювання DSML (Domain-Specific Modeling Language) і перетворення цього опису у платформозалежні артефакти. Архітектура MIC поєднує: – предметно-орієнтовані мови моделювання DSML, за допомогою яких формалізується структура, поведінка і вимоги до застосувань усередині ПрО, а також визначаються зв'язки між її поняттями, семантика й обмеження щодо використовування поняття; Розділ 8 227 – трансформаційні процесори і генератори, що аналізують задані аспекти моделей і синтезують вихідний код у XML-опис, включаючи схеми розгортки, позгодження між реалізаціями і зафіксованими у моделі вимогами до функцій системи з відповідною якістю. При проектуванні каркаса або моделі ПрО у вигляді моделі GDM можуть задаватися механізми змінювання, синхронізації, безпеки з використанням аспектного програмування. Технологія розробки сімейства програм вміщує три види базових процесів: – розробка ПрО з унікальних, одиночних програм і інших компонентів; – інженерія повторного використання програмних ресурсів; – менеджмент домену. Розробка ПрО належить до конвеєрної з повторним використанням компонентів. Для ПрО планується створення базових ресурсів, що можуть повторно використовуватися: компоненти, генератори, DSL-описи, моделі аналізу, КПВ, документація й ін. Розробка предметної області – це більш складний виробничий процес, що містить у собі такі загальні етапи: аналіз, проектування і впровадження в ПрО одиночних програм або КПВ. Аналіз області містить у собі аналіз усього сімейства, яке треба побудувати, визначаючи в ньому загальні і різні риси, створюючи структурні і поведінкові специфікації сімейства. Аналіз ПрО починається з вибору вимог і їхньої специфікації для системи як членів сімейства. Специфікація вимог – це вхідні дані для ручного або автоматичного створення домену з готових ресурсів. Інженерія повторного використання – це пошук і аналіз КПВ для їхнього повторного використання під час розв’язання задач ПрО. Вони відображаються в загальній архітектурі сімейства і в архітектурі всіх членів (тобто прикладних систем) сімейства цієї ПрО. Такими членами можуть бути одиночні прикладні системи, що вироблені методами прикладної інженерії, або готові КПВ. Впровадження або реалізація ресурсів – це повторне використання в ПрО готових компонентів, одиночних програм, генераторів, DSL-описів й ін. Об’єднання цих ресурсів у зв’язану сукупність виконується за допомогою генераторів або конфігураторів готових ресурсів. Згенерировані продукти сімейства можуть мати не програмні артефакти, наприклад, інструкції з користування DSL та задач домену й ін. Менеджмент домену – це керування технологією конвеєрної розробки з повторним використанням різних програмних ресурсів. Вона містить у собі планування і контроль підбору типових для ПрО ресурсів, їхню оцінку і перевірку відповідності вимогам. У задачу менеджменту входить також перевірка можливості застосування тих чи інших готових ресурсів для реалізації специфіки ПрО і програмування компонентів простору задач відповідно до потреб клієнтів домену. Таким чином, інженерія ПрО складається з таких процесів: – аналіз ПрО, виявлення об'єктів і зв’язків між ними; – визначення області дій об'єктів ПрО; – визначення загальних функціональних і змінюваних характеристик для побудова моделі характеристик з встановленими залежностями між різними членами сімейства; 228 Розділ 8 – створення базису для інженерії виробництва конкретних прикладних членів сімейства з механізмами змінювання незалежно від засобів їхньої реалізації; – підбір і підготовка компонентів багаторазового застосування для різних задач ПрО; – генерація окремих членів сімейства або домену в цілому. Процеси в цій схемі забезпечують формування моделі ПрО і моделі характеристики, як елементів простору проблем. Вони трансформуються в архітектуру системи й опис її компонентів. При цьому проводиться підбір готових компонентів і їхня генерація для одержання програм, що розв’язують задачі ПрО у просторі задач. Таким чином, дана схема приводить до генерації доменної моделі GMD для сімейства ПС і породженню готових підсистем або окремих членів сімейства [4]. Для забезпечення гнучкості і змінюваності деяких членів сімейства технологічна схема інженерії ПрО може мати додаткові етапи: – коректування процесів виробництва в зв'язку з включенням у систему нових проектних рішень або при зміні складу КПВ; – моделювання змінності і залежностей між компонентами шляхом зміни елементів доменної моделі GMD, інших моделей (об'єктної, взаємодії й ін.), додавання нових вимог і понять, а також фіксації їх у моделі характеристик і в конфігурації системи; – розроблення інфраструктури КПВ – опис, збереження, пошук, оцінювання й об'єднання готових КПВ, що розміщаються в репозитарію системи; – фіксація залежностей між характеристиками моделі, яка позбавляє розробників від деяких конфігураційних операцій, що виконуються, як правило, вручну; – створення репозитарію КПВ і компонентів багаторазового використання в класі завдань ПрО; – забезпечення безпеки, захисту даних, змін тощо; – забезпечення синхронізації і взаємодії КПВ. Таким чином, при генерації моделі ПрО для сімейства ПС використовується модель характеристик і набір компонентів для реалізації завдань ПрО. Використовуючи дану модель, знання про конфігурацію і специфікацію домену в мові DSL і компонентів в МП, що беруть участь у цьому процесі, можна автоматизовано згенерувати окремий член сімейства, а також ПС для систем сімейства ПрО. |