49299 (666218), страница 3
Текст из файла (страница 3)
Слід зазначити, що в самій специфікації UML існує багато огріхів і протиріч: так, у роботі [27] (Genova G., Llorens J., Quintana V. Digging into Use Case) розглядаються відносини включення й розширення для варіантів використання, в [29] (Gogolla M., Henderson-Sellera B. Analysis of UML Stereotypes within the UML Metamodel) аналізуються стандартні стереотипи метамоделі UML. У роботі [30] (Naumenko A., Wegmann A. A Metamodel for the Unified Modeling) пропонується використовувати RMODP ((Reference Model Open Distributed Processing) [31] (RM-ODP Open Distributed Processing - Reference) для рішення проблем мови. Відзначу, що відповідно до специфікації UML модель RM-ODP виступає структурою, що безпосередньо впливає на архітектуру метамодели мови (розділ “Preface: Relationships to Other Models”). Крім того RM-ODP використовується в MOF (Meta-Object Facility) для керування типами. В [30] (Naumenko A., Wegmann A. A Metamodel for the Unified Modeling) ідентифікуються три проблеми метамоделі UML і пропонується їхнє рішення на базі RM-ODP:
- структурний хаос семантики мови - “висока техніка, лаконічність і складність для розуміння новачками”; рішення: використання структури RM-ODP і теорії типів Б. Расела;
- відсутність декларативної семантики, суперечливість семантики мови при описі відносин між моделями, побудованими з використанням мови, і безпосередньо суб'єктів моделювання; рішення: реалізація базової концепції моделювання (Basic Modeling Concept);
- недостатнє теоретичне обґрунтування використовуваної метамоделі мови UML; рішення: пропонована в статті концепція моделювання на основі RM-ODP, теорії типів Б. Расела до інтерпретації формальних вирахувань уважається повністю обґрунтованою.
У багатьох роботах, присвячених формалізації моделі й метамодели мови UML, розглядається не сама мова, а деяка його підмова, формальна й строго структурований. Так, в [32] / (Paige R., Ostroff J. Metamodelling and Conformance Checking with PVS) розглядаються BON (Business Object Notation, об’єктно-орієнтована мова моделювання, по суті співпадаюча з підмовою діаграм класів UML [33] (Walden K., Nerson J.-M. Seamless Object-Oriented Software Development) і PVS (Prototype Verification System, мова специфікацій, розроблена для автоматичного аналізу метамоделей мов моделювання [34]( Owre S., Shankar N., Rushby J., Stringer-Calvert D. The PVS Language Reverence Version 2).
Результатом цієї роботи є повна формальна специфікація метамодели об’єктно-орієнтованого мови моделювання у формі, придатної для автоматичного аналізу. Однак 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]
З розширенням областей застосування моделей програмного забезпечення й систем з'явилася термінова потреба в керуванні складною еволюцією змін усередині подання моделей. У розроблювачів повинна бути можливість швидкої й простої перевірки різних проектних альтернатив серед незліченних і різнотипних конфігураційних можливостей.
В ідеалі інструментальний засіб повинний був б робити імітаційне моделювання кожної нової проектної конфігурації для визначення того, яким образом деякий аспект конфігурації (наприклад, комунікаційний протокол) впливає на спостережувану властивість (наприклад, на пропускну здатність). Для забезпечення такого рівня підтримки еволюції моделей інструментальний засіб повинний забезпечувати дві категорії змін, які в цей час виконуються розроблювачами вручну й звичайно з поганими результатами.
Першу категорію становлять зміни, що перетинають ієрархію подання моделі. Прикладом є ефект зміни пропускної здатності на якість обслуговування компонентів авіаційного електронного встаткування, які повинні відображати в реальному часі відео-потік. Щоб оцінити наслідки такої зміни, розроблювач вручну обійти ієрархію моделі, рекурсивно клікая по кожної подмоделі. Цей процес стомлюючий і чреватий помилки, оскільки моделі систем часто містять ієрархії глибиною в кілька рівнів.
Друга категорія змін включає збільшення масштабу частин моделі, що доставляє особливі занепокоєння при розробці великомасштабних убудованих систем реального часу, що містять тисячі крупномодульних компонентів. Для цього типу зміни потрібне створення декількох модельних елементів і з'єднань між ними. При роботі з інструментом моделювання для масштабування базової моделі з декількох елементів до моделі з тисячами елементів потрібно разюче велика кількість дій з мишею й клавіатурою. При виконанні цього процесу легко робляться помилки, наприклад, можна забути встановити з'єднання між двома задубльованими елементами. Зрозуміло, що ручне масштабування впливає не тільки на ефективність моделювання, але й на коректність представлення.
Обидві ці категорії еволюції змін істотно виграли б від автоматизації. Із цією метою автори розробили узагальнений процесор трансформацій для маніпулювання моделями, названий ними C-Saw (Constraint-Specification Aspect Weaver). C-Saw – це - модуль, що підключається, для GME (див. вище огляд статті "Розробка додатків з використанням керованих моделями середовищ розробки").
Для роботи зі змінами, що перетинають ієрархію, в C-Saw використовується кілька принципів аспектно-орієнтованого підходу. Комбінація трансформації моделі з компонуванням аспектів забезпечує потужну технологію для швидкого перетворення успадкованих систем на основі високорівневих властивостей, описуваних моделлю. Далі, шляхом застосування аспектно-орієнтованих методів і перетворення програм невеликі зміни на модельному рівні можуть ініціювати дуже великі трансформації на рівні вихідного коду.
Останню статтю тематичної добірки - "Модельно-модельно-орієнтована розробка з використанням UML 2.0: обіцянки й прорахунки" ("Model-Driven Development Using UML 2.0: Promises and Pitfalls") - написали Роберт Франс, Судипто Гош, Трунг Динх-Тронг і Арнор Солберг (Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, Colorado State University, Arnor Solberg, SINTEF). [10.5]
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
