Результатом цієї роботи є повна формальна специфікація метамодели об’єктно-орієнтованого мови моделювання у формі, придатної для автоматичного аналізу. Однак BON у порівнянні з UML більше формалізований і “підігнаний” під умови розв'язуваного завдання.
Аналогічний підхід використаний в [35] (Overgaard G. Formal Specification of OO Modeling), де як платформа для формалізації обраний формалізм Boom, що складається з метамоделі й мови формальних специфікацій Odal - простого строго типізованої мови, семантика якого задана в термінах так званого π -вирахування. В [36]( Clark T., Evans A., Kent S. The Metamodelling Language Calculus: Foundation Semantics for UML) на основі [37] (Cardeli L, Abadi M. A theory of Objects) розглядається формалізація мови MML (Metamodelling Language), що є підмножиною UML; ця формалізація запропонована авторами як база для всього UML 2.0.
Нарешті, у роботі [38] (Lellahi K. Conceptual Data Modeling: An Algebraic Viewpoint) демонструється застосовність алгебраїчного підходу для формального опису ER-Діаграм (Entity-Relationship diagrams), що є аналогами діаграм класів UML.
Статті в комп'ютерних журналах.
Зупинюся докладніше на огляді лютневого, 2005 р. номера журналу Computer (IEEE Computer Society, V. 38, No 2, February 2005).
Темою лютневого номера журналу є "Керована моделями розробка програмного забезпечення" ("Model-Driven Software Development"). Представлено повноцінну тематичну добірку статей із запрошеним редактором, Дугласом Шмідтом (Douglas C. Schmidt, Vanderbilt University). [10]
Об'ємна вступна замітка редактора називається "Керована моделями інженерія" ("Model-Driven Engineering"). У статті дається докладний аналіз залежності ручної праці розроблювача програмного забезпечення від рівня абстракції мови програмирвания. Обговорюються фактори виникнення програмного забезпечення з комп'ютерною підтримкою (Computer-Aided Software Engineering, CASE),його переваги й недоліки. Піднімається питання складності популярних платформ проміжного програмного забезпечення J2EE, .NET і CORBA. Ситуацію не рятує навіть використання описів розгортання мовою XML. Багатообіцяючим підходом, спрямованим на рішення цих проблем, є розробка технологій інженерії, керованої моделями, (Model-Driven Engineering, MDE).[10.1]
Перша основна стаття тематичної добірки називається "Розробка додатків з використанням керованих моделями середовищ розробки" ("Developing Applications Using Model-Driven Design Environments"). Автори статті - Krishnakumar Balasubramanian, Aniruddha Gokhale, Gabor Karsai, Janos Sztipanovits, Sandeep Neema, Vanderbilt University. [10.2]
Історично методології розробки програмного забезпечення фокусуються більшою мірою на вдосконалюванні засобів розробки систем, а не на створенні інструментів, що допомагають конструювати й інтегрувати системи. Компонентне програмне забезпечення проміжного шару (Enterprise Java-Beans (EJB), Microsoft .NET і CORBA Component Model (CCM)) сприяють підвищенню рівня повторного використання програмного забезпечення на основі абстракції компонента.
Однак при прийнятті розроблювачами на озброєння цих комерційних, готових до використання технологій виникає розривши між такими доступними й зробленими засобами розробки, як компілятори й отладчиками, і засобами, використовуваними розроблювачами для компонування, аналізу й тестування закінченої системи або системи систем. У результаті розроблювачі продовжують виконувати системну інтеграцію з використанням підручних методів без підтримки засобів автоматизації.
Розробка, керована моделями (Model-Driven Development, MDD) - це парадигма, що розвивається, вирішальні численні проблеми композиції й інтеграції великомасштабних систем і опирається при цьому на наявні досягнення в області технологій розробки програмного забезпечення (зокрема, на компонентне проміжне програмне забезпечення). MDD дозволяє перевести розробку програмного забезпечення на більше високий рівень абстракції в порівнянні з тим, що можливий при використанні мов третього покоління. Для подання елементів системи і їхніх зв'язків у підході MDD використовуються моделі. Моделі служать вхідними й вихідними даними на всіх стадіях розробки, впритул генерації закінченої системи.
Автори визнають, що популярним варіантом MDD є модельно-керована архітектура (Model-Driven Architecture, MDA), запропонована й розвиваєма консорціумом Object Management Group (OMG).У підході MDA системи представляються з використанням мови моделювання загального призначення Unified Modeling Language (UML)і її конкретних профілів. Ці моделі перетворяться в артефакти, виконувані на різноманітних платформах, зокрема, на EJB, .NET і CCM. [10.2]
Наступна стаття написана Adam Childs, Jesse Greenwald, Georg Jung, Matthew Hoosier, John Hatcliff, Kansas State University. Назва статті - "CALM і Cadena: метамоделювання для заснованої на компонентах розробки продуктового ряду" ("CALM and Cadena: Metamodeling for Component-Based Product-Line Development").[10.3]
Великомасштабні роботи зі створення програмного забезпечення все частіше ґрунтуються на продуктових лініях. У таких процесах розробки розроблювачі створюють програмне забезпечення для подібних сімейств продуктів на основі повторно використовуваної архітектури й загальних прикладних компонентів.
У підході продуктових ліній особливе значення надається систематичному повторному використанню, і проходження цьому підходу може скоротити час розробки й впровадження у виробництво, а також загальну вартість більш ніж в 10 разів. Підхід продуктових ліній підтримується використанням компонентного проміжного програмного забезпечення за рахунок забезпечення правильно певних інтерфейсів, які запобігають зайвій прив'язці клієнтського коду до низкорівневих реалізацій, і спрощення додавання й вилучення модулів, що сприяє повторному використанню й розвитку системи.
Розробка на основі підходу продуктових ліній з використанням компонентних каркасів успішно зарекомендувала себе в численних прикладних областях: від великомасштабних розподілених систем реального часу й убудованих систем, систем керування електромережами, систем керування виробничими процесами до операційних систем користувальницького рівня й систем інтеграції додатків персональних комп'ютерів.
Це явний поділ інфраструктури й модулів додатка, а також можливість простого компонування цих модулів, наводить на природну думку про наявність у розробці трьох ролей. Архітектор продуктової лінії формує архітектуру системи, вибирає інфраструктурні платформи й організує процес розробки, розроблювач компонентів створює модулі бізнес-логіки, і інтегратор компонентів збирає компоненти в систему.
Платформа підтримки розробки Cadena разом з її основним засобом моделювання CALM (Cadena Architecture Language with Metamodeling) дозволяє перебороти цей недолік на рахунок забезпечення адаптивного середовища моделювання з потужною, гнучкою й розширюваною інструментальною підтримкою. CALM - це мова опису архитектур, що підтримує строго типізоване моделювання платформ, компонентів цих платформ і складань компонентів конкретних сценаріїв. Мова також підтримує засновану на спадкуванні ієрархічну організацію платформ із використанням механізмів аспектів для включення в загальні архітектурні описи атрибутів конкретних платформ. Cadena забезпечує різноманітну підтримку створення, редагування, запиту, перегляду й перетворення CALM-Моделей. CALM-моделі зв'язуються з каркасами компонентного проміжного програмного забезпечення, а також із засобами генерації коду через підключаються модулі, ЩоМ, Cadena.
Стаття "Автоматизація еволюції змін у модельно-модельно-керованій інженерії" ("Automating Change Evolution in Model-Driven Engineering") написана Джефом Гріємо, Джейн Лін і Джинг Жанг. [10.4]
З розширенням областей застосування моделей програмного забезпечення й систем з'явилася термінова потреба в керуванні складною еволюцією змін усередині подання моделей. У розроблювачів повинна бути можливість швидкої й простої перевірки різних проектних альтернатив серед незліченних і різнотипних конфігураційних можливостей.
В ідеалі інструментальний засіб повинний був б робити імітаційне моделювання кожної нової проектної конфігурації для визначення того, яким образом деякий аспект конфігурації (наприклад, комунікаційний протокол) впливає на спостережувану властивість (наприклад, на пропускну здатність). Для забезпечення такого рівня підтримки еволюції моделей інструментальний засіб повинний забезпечувати дві категорії змін, які в цей час виконуються розроблювачами вручну й звичайно з поганими результатами.
Першу категорію становлять зміни, що перетинають ієрархію подання моделі. Прикладом є ефект зміни пропускної здатності на якість обслуговування компонентів авіаційного електронного встаткування, які повинні відображати в реальному часі відео-потік. Щоб оцінити наслідки такої зміни, розроблювач вручну обійти ієрархію моделі, рекурсивно клікая по кожної подмоделі. Цей процес стомлюючий і чреватий помилки, оскільки моделі систем часто містять ієрархії глибиною в кілька рівнів.
Друга категорія змін включає збільшення масштабу частин моделі, що доставляє особливі занепокоєння при розробці великомасштабних убудованих систем реального часу, що містять тисячі крупномодульних компонентів. Для цього типу зміни потрібне створення декількох модельних елементів і з'єднань між ними. При роботі з інструментом моделювання для масштабування базової моделі з декількох елементів до моделі з тисячами елементів потрібно разюче велика кількість дій з мишею й клавіатурою. При виконанні цього процесу легко робляться помилки, наприклад, можна забути встановити з'єднання між двома задубльованими елементами. Зрозуміло, що ручне масштабування впливає не тільки на ефективність моделювання, але й на коректність представлення.