Сучасні технології та засоби розробки програмного забезпечення

Размещено на Allbest.ru

Сучасні засоби розробки програмного забезпечення та технології дозволяють створення і розвиток надзвичайно складних, розподілених програмних систем, що взаємодіють з різними зовнішніми агентами. Еволюцію такої системи не в силах повністю контролювати окремий розробник, який вважає ся лише на приватні емпіричні знання про її структуру та функції. У той же час складної програмної системі, як і будь-який інший системі, притаманні певні загальні закономірності, вивчаються в загальній теорії систем [1]. Подальше збільшення складність, численність підсистем з суперечливими цілями і велике число взаємозв'язків призводить до появи в області проектування, розробки та експлуатації програмних систем метасистемного переходу [2].

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

Знання подібних загальносистемних принципів дозволяє ефективно організовувати проектування і розробку складного програмного забезпечення. При використанні найвищого доступного на даний момент рівня абстракції (рівня управління системою) з'являється можливість отримання більш ефективних результатів (в кількісному вирахуванні. Це набір реалізованих функцій, а також більш повне задоволення не функціонованим вимогам безпеки, переносимості і т. п.), при тому ж використанні інтелектуальної сили розробників. Однак побічним ефектом, який слід брати до увагу, є збільшення накладних витрат на роботу системи. Кожне підвищення рівня абстракції і рівня управління вимагає залучення додаткових ресурсів (більше число уявлень, витрати на реалізацію відображень і т. п.). У програмісткою практиці це означає, що використання більш абстрактних системних рівнів призводить до більшого розміру коду і меншою продуктивності програм. Якби ми порівнювали дві програмні системи з тими ж (або приблизно тими ж) функціями користувача, то меншим розміром і більшою продуктивністю мала б та, при проектуванні і розробці якої використовувалися менш абстрактні кошти. Наочний приклад такої ситуації - оцінка ресурсів, необхідних для виконання найпростіших алгоритмів у віртуальній машині Java. Для віртуальної машини Wonka [3] потрібно не менше 4Мб оперативної пам'яті тільки для розгортання машини.

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

Однак зараз запаси по зростанню продуктивності процесорів і збільшення обсягу первинної, вторинної, третинної пам'яті ще більші. Тому для багатьох прикладних задач зростанням накладних витрат можна поки зневажити. Як показує приклад перспективних розробок компанії Intel [4], незважаючи на наближення до технологічної межі в 65 нм у виробництві окремих процесорів, існують схемотехнічні рішення, які забезпечать подальший підвищення продуктивності і зниження енергоспоживанням. Для більшості прикладних задач сама ефективна стратегія - використання найбільш абстрактного рівня в системі технологій і найбільш абстрактного рівня в системі проектування. Потрібно знати, на якому рівні знаходиться зараз кожна з цих систем і які конкретно параметри знаходяться в розпорядженні розробника.

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

Результат дослідження. Напрямок розвитку системного програмного забезпечення (ПО). компонентні системи. В даний час лідируючим методом проектування і розробки програмного забезпечення є об'єктно-орієнтований підхід [5]. За багато років широкого використання цей метод показав свої можливості при моделюванні різних предметних областей і в реалізації різних категорій ПО - від операційних систем до систем управління складними технологічними об'єктами.

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

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

забезпечення ефективної розподіленої роботи безлічі об'єктів;

підтримка транзакцій;

безпеку об'єктно-орієнтованої системи;

довговічне збереження даних;

дозвіл нелокальних ефектів поведінки об'єктів в контексті складної розподіленої системи. Поки вибір і реалізація таких рішень покладається на конкретного розробника, ефективність розподілених об'єктно-орієнтованих технологій залишається невисокою, так як її надто складно використовувати, здійснювати підтримку і розвиток в кожному конкретному випадку. Приклад - технологія розподілених об'єктів CORBA, створена OMG [6]. Така складність на руку окремим розробникам. Мало хто з них стають експертами в цій галузі і можуть монополізувати процес розробки ПЗ, що призводить до неефективного використання ресурсів в рамках системи «користувач-програмний продукт-розробник». Тому за межами індивідуального людського розуму ця система еволюціонує до нового рівня організації, на якому всі (або більшість) перерахованих системи завдань одноманітно вирішуються в рамках об'єктивізованих процесу роботи метасистеми, параметрами якого тільки і може керувати розробник. Ця еволюція призводить до появи такого поняття програмної архітектури, як серверний компонент, і до виникнення нового різновиду системного ПО - моніторів компонентного взаємодії (монітор компонентних транзакцій).

Найбільш поширена практична реалізація серверних компонентів і моніторів компонентного взаємодії - J2ЕЕ технологія Enterprise Java Beans [7]. Широкого розповсюдження набула JЕВ технологія, що вільно розповсюджується продукт JBOSS [8], і комерційний продукт BEA WebLogic.

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

В технології EJB закладено новий принцип організації розподіленої системи з набору незалежно створених компонент. Функціональність, раніше створювалася заново (у вигляді дії), тепер (з точки зору прикладного розробника) представляється в формі параметрів метасистеми. Усе (або майже все) питання життєвого циклу, іменування компонентів, безпеки, довговічності, прозорого мережевого доступу об'єктивно визначені правилами взаємодії серверного ЕJВ компонента і монітора компонентних взаємодій. Розробник може розглядати функціонування своєї системи в термінах уявлень набагато більш високого рівня абстракції і проводити настройку ЕJВ компонентів шляхом зміни їх атрибутів в декларативному вигляді, реалізуючи на практиці так зване програмування на основі атрибутів (attribute-based programming). Це дозволяє ефективніше пов'язувати систему з іншими системами (зовнішнім світом), міркувати про функції і можливості створеного програмного забезпечення.

Найбільш очевидне нововведення технології EJB - створення нового рівня абстракції доступу до довготривало зберігаємим даними програми. Цей рівень називається «управління довготривалим зберіганням» (Container Managed Persi stence, CMP) [9] і дозволяє розробнику використовувати поняття «постійних» об'єктів (persistent object), абстрагуючись від раніше вимагають уваги питань з'єднання з базами даних, формування SQL запитів, визначення моментів доступу до баз і т. п. “Проектування” властивостей ЕJB компонента на модель використовуваної бази даних проводиться декларативним способом в процесі розгортання на моніторі компонентного взаємодії. Тому один і той же EJB компонент в різних розподілених системах може представляти різні бази даних.

Розвиток інструментальних засобів

В результаті використання можливостей компонентного програмування і моніторів компонентного взаємодії користувач (прикладний програміст) звільняється від необхідності детального знання специфіки реалізації таких важливих функцій, як життєвий цикл, сталість даних, транзакції і ін. Однак тепер він стає перед необхідністю детального знання і розуміння всіх деталей синтаксису і семантики параметрів об'єктивізованих процесу управління компонентами. При наявності великої кількості незалежних реалізацій технології EJB і несталих стандартів володіння усіма інструментами конфігурації для конкретного EJB сервера стає скрутним. Тепер потрібно створювати допоміжні Java? Інтерфейси (home, remote, local), які безпосередньо до прикладного завдання не мають ніякого відношення.

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

засіб автоматизації побудови ANT [15]. Це засіб, реалізоване на мові Java, багато в чому нагадує відому утиліту make, але в ньому з'явилися нові риси. Важливою мотивацією створення ANT було звільнення від особливостей програмування в різних командних оболонках UNIX при створенні make файлів. Замість використання можливостей командних оболонок ANT використовує власний командний розширювана мова, програма на якому виражається у формі XML файлу. Це дозволяє переносити і розширювати можливості ANT без прив'язки до конкретного типу командної оболонки, використовуваної на даному комп'ютері;

програмна система XDOCLET [16] реалізує концепцію літерального програмування включенням особливого роду коментарів до складу програм на мові Java. З використанням цього засобу розробник звільняється від детального знання синтаксису XML конфігураційних файлів, потрібних для налаштування і розміщення серверних компонентів (причому для різних EJB серверів), і необхідність створення додаткових артефактів EJB технології (наприклад, інтерфейсів). При використанні кошти XDOCLET в його розпорядженні виявляється група ключових слів, які прямо перед вимагає специфікації елементом (класом, методом) дозволяють задати необхідні параметри. Після завершення роботи над текстовим файлом алгоритми системи XDOC LET (реалізовані у вигляді розширення ANT) виробляють перепроцесорну обробку, знаходячи службові коментарі XDOCLET і використовуючи інформацію з них для генерації дескрипторів розгортання і допоміжних класів і інтерфейсів EJB;

рішення ANDROMDA [17] більш кардинальне. Цей програмний продукт використовує в якості основи для створення всіх артефактів EJB і відповідних командних файлів програми ANT декларативну об'єктно-орієнтовану модель на мові UML. При створенні цієї моделі використовуються зарезервовані стереотипи для специфікації класів, атрибутів, методів і зв'язків. Ці стереотипи використовуються програмою ANDROMDA для визначення, які з класів моделі повинні бути перетворені в EJB компоненти, які атрибути і методи повинні бути для цих компонент згенеровані. Поки використовується генерація артефактів тільки для EJB сервера JBoss.

Розвиток засобів моделювання

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

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

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

Таким чином, кожна модель - екземпляр мета моделі. Мета модель зазвичай містить: перелік типів дозволених конструктивних елементів разом з атрибутами; опис дозволених типів зв'язків між різними будівельними елементами; іншу корисну інформацію.

Все це разом дозволяє однозначно і в доступній для людини і комп'ютера формі визначити смислове значення (семантику) кожного конструктивного елементу окремо і моделі в цілому.

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

Проілюструвати взаємовідношення між різними рівнями мета моделювання можна на основі стандартів міжнародної організації OMG2. Для моделювання та інтеграції складних об'єктно-орієнтованих програм ця організація пропонує використовувати взаємопов'язану ієрархію мета моделей і моделей з чотирьох рівнів. Ця ієрархія носить назву Meta Object Facility, MOF (Засоби Мета Об'єктів) [28].

Рівні MOF визначаються наступним чином, починаючи з самого конкретного:

рівень користувальницької інформації складається з тієї інформації про реальний світ, яку потрібно описати і безпосередньо використовувати в роботі програми. Цю інформацію зазвичай називають даними;

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

рівень метамоделі складається з описів структури і сенсу (семантики) метаданих (Моделей). Тобто на цьому рівні розташовуються метаметаданние, або як їх частіше називають - мета модель. Мета модель можна вважати єдиною мовою, на якому описуються різні види даних;

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

Вміст рівнів визначається наступним чином:

рівень користувальницької інформації містить конкретні екземпляри записів з інформацією про певні співробітників;

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

рівень метамоделі визначає, що власне означає «бути типом даних Record». Це визначення виражається через вміст метакласом з ім'ям «Record». Він містить два метаатрібута: перший визначать ім'я типу Record, а другий визначає атрибути. Таким же чином особливий метакласом визначає зміст елемента Field.

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

Рис. 1 Принципи автоматизованого перетворення різнорідних даних на основі метамоделювання

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

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

Пропозиції OMG включають не тільки теоретичну концепцію, а й практичні засоби реалізації метамоделювання. OMG рекомендує для створення метамоделей і моделей використовувати один і той же мова об'єктно-орієнтованого моделювання - мова UML. У цьому випадку мета модель визначає модель мови UML на самому високому рівні абстракції і є найбільш компактним її описом - все основні поняття мови UML (клас, атрибут, операція, компонент, асоціація і т. д.), їх атрибути і взаємозв'язку формально визначаються на рівні метамоделі. Повна метамодель мови UML має складну структуру і включає в себе близько 90 метакласом, понад 100 метаасоціацій, організованих в три логічні пакети: основні елементи, елементи поведінки і загальні механізми.

Будь-яка UML модель програмної системи є екземпляром метамоделі. Це означає: для побудови моделі можуть використовуватися тільки поняття, певні в метамоделі, які розробник спеціалізує або конкретизує певним чином.

Таким чином, можливості мови UML практично повністю задовольняють вимогам метамоделювання, дозволяючи створювати узгоджені ієрархії моделей і метамоделей, а також проводити їх трансформації в рамках єдиної метатехнології. Практичний приклад такої метатехнології - підхід Model Driven Architecture - MDA [18], який також розвивається під егідою OMG. Автори цього підходу, вважають, що він дозволяє відокремити специфікацію функціональності системи, що розробляється і стабільне опис концепцій предметної області від специфікації альтернативних методів реалізації з використанням певної програмної технології або платформи.

Слідуючи цьому підходу розробник концентрується на розробці групи моделей (при цьому, як правило, використовується мова UML), які фіксують в абстрактній (що не залежить від особливостей мови реалізації і програмних технологій), об'єктно - орієнтованої формі структуру, функції і поведінку всіх елементів проектованої системи в бізнес контексті. Набір таких моделей називається в термінології MDA платформо незалежної моделлю (PIM - Platform Independent Model).

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

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

Сукупність створених автоматично або вручну артефактів становить єдину модель (або єдину групу моделей), що описує систему вже в зв'язку з конкретними обраними для реалізації технологічних і інженерними рішеннями. Таку модель називають платформо залежної моделю (PSM - Platform Specific Model).

Важлива особливість MDA підходу - великий коефіцієнт повторного використання компонентів моделі. Одні і ті ж моделі можуть бути використані для генерації різних артефактів, в залежності від обраних користувачем мови реалізації, конфігурації, програмних технологій. Така можливість з'являється завдяки тому, що в MDA підході явно виділяється інтерфейс і вимоги до компоненту маппінга, відповідального за генерацію певної PSM моделі по абстрактної PIM моделі. Такий компонент зазвичай носить назву MDA картридж. Окремий MDA картридж є модулем розширення інструментального кошти і вміє проводити генерацію артефактів для якогось конкретного набору параметрів, мов і технологій (Наприклад, бізнес логіка: Java + EJB + WebLogic 6. 1, GUI: Java + JSP + WebLogic 6. 1, засоби підтримки розробки: командні файли для ANT, використання певних бібліотек) [28-30].

Практичною ілюстрацією концепцій MDA є продукт ArcStylertm компанії Interactive Object [19]. Він дозволяє з використанням принципів MDA проводити розробку, моделювання, генерацію, настройку і управління розподіленими програмними системами на основі стандартів J2EE, а також інтегрувати застарілі системи і призначену для користувача інфраструктуру. За допомогою продукту ArcStylertm можна використовувати значно вищий рівень абстракції, ніж при традиційному підході до проектування системи. Але за це доводиться платити додатковими накладними витратами - реалізація найпростішого призначеного для користувача інтерфейсу на основі технології JSP [20] вимагає близько 600 кБ коду.

Трансформація моделей в ArcStylertm реалізована за допомогою поняття MDA картриджа, основним завданням якого є перетворення вихідної платформо незалежність моделі на мові UML в різні артефакти цільової платформо залежною моделі. У більшості випадків артефакти є файлами з вихідним кодом на певній мові програмування і відповідають класам вихідної UML моделі. Внутрішня структура кожного артефактів зумовлена за допомогою так званих секцій артефактів. У разі текстових файлів секція задає місце розташування, можливий зміст певного фрагмента файлу і зв'язок з елементами вихідної моделі (наприклад, які атрибути класів вихідної моделі використовуються для генерації вмісту даної секції). Секції артефактів можуть бути вкладені одна в одну, таким чином повністю визначаючи ієрархічно структурує ванну цільову модель.

В цільової моделі набір артефактів (Artifact Set) об'єднує разом артефакти, які завжди створюються разом в результаті виконання визначеної умови. Ця умова будується на основі вихідної моделі і можливо з використанням додаткової конфігураційної інформації. Наприклад, якщо MDA картридж системи ArcStylertm реалізує трансформацію UML моделі (в якій EJB компонент представляється у вигляді єдиного класу), то для кожного елемента моделі буде створено свій набір артефактів, що складається з файлів з вихідним кодом на мові Java для всіх необхідних в технології EJB інтерфейсів (home, remote), класів реалізації, Bean класів, а також конфігураційних файлів (наприклад, дескрипторів розгортання). Його генерація відбувається в разі появи у вихідній UML моделі елемента, що представляє EJB компонент.

Знання про способи перетворення елементів вихідної метамоделі (зв'язку, операції або атрибути) в форму різних артефактів і секцій артефактів цільової метамоделі в системі Arcstylertm декларативно виражаються у вигляді так званих Ескізів (Blueprints). Наприклад, в разі застосування EJB технології Ескіз для вихідної UML метамоделі буде визначати як метаелементів Opera tion, визначений у вихідній метамоделі UML, представляється у вигляді віддаленого інтерфейсу і Bean класу в цільової метамоделі. Ескізи, взаємопов'язані в складі ієрархії успадкування, дозволяють формально і повністю визначити всі правила трансформації будь-якого елементу вихідної метамоделі.

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

Для широкого поширення принципів модельно-оріентованого проектування і розробки крім однакових принципів використання ієрархій моделей і метамоделей необхідний єдиний текстовий формат уявлення створених UML моделей, щоб можна було звертатися з моделями, створеними незалежно в різних засобах проектування і моделювання. Претендентом на такий єдиний текстовий мова представлення моделей на сьогодні є XMI [26]. Чому саме претендентом? В ході роботи з різними засобами розробки (Rational Rose [22], Together [23], Poseidon [24], MagicDraw [25]) і системами, що підтримують генерацію артіфактів (ANDROMDA, ArcStylertm) виявлена велика відмінність в існуючих версіях XMI. Це призводить до того, що на практиці перенесення моделей з одного засобу в інше на рівні XMI документів вкрай обмежений. Проте XMI - практично єдиний інтероперабельний стандарт уявлення об'єктно-орієнтованих моделей.

Висновки

програмне забезпечення інженерна діяльність

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

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

До числа перспективних напрямків роботи відноситься розробка єдиної теорії алгоритмів перетворення моделей і єдиних принципів побудови програмної архітектури картриджів для генерації артефактів в технології MDA. До сих пір ці аспекти проектування до кінця не стандартизовані. Розробники інструментальних засобів змушені проводити реалізацію приватних походів. Інтерес представляє вивчення глибинних взаємозв'язків об'єктно-орієнтованого моделювання та інших варіантів моделювання (Зокрема, моделей, що описують бізнес процеси, наприклад, IDEF0). У зв'язку з цим згадаємо засіб розробки ArcStylertm, в якому реалізовані можливості інтеграції моделей, створених за допомогою відомого засобу бізнес моделювання ARIS Toolsettm. Повсюдне застосування модельно-орієнтованих методів розробки програмних систем змушує шукати нові принципи колективної роботи різних груп фахівців в ході уточнення вимог, побудови архітектури, реалізації, тестрованія і інтеграції програм. Деякі дослідники покладають великі надії на застосування апарату ASM - машин абстрактних станів - для інтеграції в модельно-орієнтовану технологію самого трудно формалізуемого етапу зі збору та формування вимог.

Література

1. Ван Гиг Дж. Прикладная общая теория систем, т. 1, 2: - М. : Издательство «Мир», 1981. - 336 с.

2. Турчин В. Ф. Феномен Науки: Кибернетический подход к эволюции. - М. : ЭТС, 2000. - 368 с. - ISBN 5-93386-019-0.

3. Wonka - Java2 Virtual Machine Home Page // [Electronic resource]. Access mode URL: https: //opensource. luminis. net/confluence/display/WONKA/Home.

4. Intel Silicon 65 nm Technology // [Electronic resource]. Access mode URL: http: //www. intel. com/technology/silicon/65nm_technology. htm

5. Элиенс А. Принципы объектно-ориентированной разработки программ. Пер. с англ. - М. : «Вильямс», 2002. - 496 с.

6. Ahmed S. A. CORBA Programming Unleashed. Sams Publishing, 1999. - 578 c.

7. МонсонХефел Р. Enterprise JavaBeans. Пер. с англ. - Спб: Символ-Плюс, 2002. - 672 с.

8. Marrs T., Davis S. JBoss at Work: A Practical Guide. O'Reilly Media, Inc, - 2005. - 306 c.

9. Tulachan P. Developing EJB 2. 0 Components. Prentice Hall, 2002. - 656 c.

10. Шеер А. В. Бизнес-процессы. Основные понятия. Теория. Методы. Весть-Метатехнология, 1999. - 152 c.

11. Wiederhold G., Wegner P., Ceri S. Toward Megaprogramming CACM, Volume 35, Issue 1, November 1992. - С. 89 - 99.

12. OBE - Open Business Engine. http: //obe. sourceforge. net/about/introduction. html.

13. JAWE - Open Source Java XPDL Editor // [Electronic resource]. Access mode URL: http: //www. enhydra. org/workflow/jawe/index. Html

Размещено на Allbest.ru