Навигация
Огляд англомовної літератури UML
55929
знаков
1
таблица
0
изображений
5. Огляд англомовної літератури UML
Для того щоб добре орієнтуватися в UML, тобто успішно використовувати його на практиці, треба мати досить глибокі представлення про методи об’єктно-орієнтованого аналізу, проектування й програмування. Приведу список англомовної літератури по UML з коротким описом змісту кожної роботи. Цей список не претендує на повноту, але, по -моєму, дає деяке подання про літературу, що описує UML.
Перша група робіт - [4], [5], [6]
[4], Booch G. Object-oriented analysis and design with applications. Second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.//
[5] Rumbaugh J., Blacha M. Premerlani W., Eddy F. Lorensen W. Object-Oriented Modeling and Design. Prentice-Hall, Inc., 1991
[6] Jacobson I. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley Publishing Company, 1993.
містить опис об’єктно-орієнтованих методологій, які були покладені в основу UML.
[5] є описом методології OMT. Вона вийшла в 1991 році й на справжній момент існує багато CASE-Засобів, у тім або іншому ступені підтримуючих її. До UML ця методологія була однієї з найпоширеніших.
[4] є, очевидно, кращою книгою в цій області. Вийшло два її видання - перше в 1991 році, друге - в 1994. Обоє видання перекладені на російську мову.
[6] містить опис OOSE - об’єктно-орієнтованого підходу до створення програмних систем, заснованого на моделі випадків використання (use case driven approach) і є систематизацією більш ніж 20-літнього досвіду її автора, Айвара Джекобсона, в області створення більших систем. Ця книга вийшла у світло в 1992 році. Модель випадків використання й багато чого, з нею зв'язане, увійшли в UML.
Друга група літератури є канонічним описом стандарту UML
[2] Booch G.,Rumbaugh J. UML 1.1. Semantics. 1997.
і [7] Booch G., Rumbaugh J. UML 2.0. Notation Guide є основними документами по UML. Там описується метамодель UML і дуже мало уваги приділяється семантиці конструкцій. В [8] (A Rational Approach to Software Development Using Rational Rose 4.0 )описується приклад розробки програмної системи (реєстрація студентів на відвідування навчальних курсів) з використанням CASE-Засобу Rational Rose, що реалізує підмножину UML (аналіз і проектування). Всі ці документи вільно доступні і їх можна взяти на web-вузлі OMG.
Оскільки офіційна документація по UML скрутна для розуміння, виходить багато книг, що описують його з різними акцентами. Я відзначу книги, написані головними авторами UML - Г. Бучем, И Джекобсоном, Д. Рэмбо - [1], [11], [12]:
· [1] - G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: детальна інформація про використання UML. Покриває близько 80% мови. Застосування UML описується на великій кількості прикладів;
· [11] Ivar Jacobson, G. Booch, Jim Rumbaugh The Unified Software Development Process - опис процесу об’єктно-орієнтованої розробки ПО;
· [12] - J.Rumbaugh, I.Jacobson, G. Booch Unified Modeling Language Reference Manual: - довідник по UML, що охоплює вся мову.
Крім того, відзначу ще книгу [13] (B.P. Douglass Real-Time UML. Developing Efficient Objects for Embedded Systems), написану співробітником фірми i-Logix Брюсом Дугласом, у якій утримується гарний опис UML у контексті розробки систем реального часу.
Ще одним джерелом інформації з UML є матеріали, що випускаються компанією Rational Software Corp. Це насамперед величезна база даних RUP, що містить більше 1000 статей навколо UML. Крім того, із грудня 1998 року виходить у світло журнал "Rose Architect", що містить багато цікавих статей фахівців фірми Rational Software Corp. про UML, RUP, Rational Rose, про застосування Rational Rose у різних областях розробки ПО.
Нагадаю, початковою метою розвитку UML було забезпечення більш точного опису мови моделювання - підтримка формальної основи для розуміння мови моделювання. Однак дотепер формальна семантика не є частиною стандарту. Огляд декількох підходів, що стосується визначення такої семантики, наведений в [26] (Husman H. Loose Semantics for UML), де розглянуті теоретико-множинний, трансляційний, метамодельний підходи й запропонований так звана “вільна семантика”.
Слід зазначити, що в самій специфікації 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]
Досвід показує, що ефективні механізми керування складністю автоматизують звичайні завдання розробки й забезпечують надійну підтримку поділу відповідальностей. Наприклад, сучасні високорівневі мови програмування й інтегровані середовища розробки забезпечують абстракції, що захищають розроблювачів від складних низькорівневих деталей і підтримують автоматичне перетворення абстрактних представлень вихідного коду в дійсні форми, які виконує машина.
Досягнення в областях розробки програмного забезпечення й технологій обробки інформації привели до спроб створення більш складних програмних систем. Ці спроби демонструють неадекватність абстракцій, забезпечуваних сучасними мовами високого рівня. Виникає потреба в мовах, моделях і технологіях, що підвищують рівень абстракції, на якому замислюються, створюються й розвиваються.
OMG (Object Management Group) відповідає на цю вимогу підготовкою версії 2.01 мови UML і ініціативою MDA (Model Driven Architecture). Проблеми, на рішення яких на початку були націлені розроблювачі UML 2.0, включали очевидне розпухання ранніх версій UML і відсутність правильно певної семантики.
У ході розробки стандарту в число вимог була додана підтримка модельно-модельно-керованої розробки (MDD), а точніше, підходу MDA до MDD. Широка поінформованість про проблеми ранніх версій UML разом зі зростаючим інтересом до MDD породили надії на те, що розроблювачам UML 2.0 удасться зробити версію мови з істотно скороченим набором модельних понять для точного й зручного описів найрізноманітніших додатків.
Очікувалося також, що в цій версії буде бути точна семантика, що могла б полегшити автоматизацію, необхідну для просування MDD за межі традиційних можливостей існуючих CASE-Засобів. Деякі люди очікували, що розроблювачам UML 2.0 удасться зробити срібну кулю мов моделювання або, принаймні, тісно наблизитися до цього.
Ті, хто не знаком із внутрішніми роботами в області, проведеній співтовариством стандартизації мов, знаходять разючими розмір і складність стандарту UML 2.0. Дійсно, кінцеві результати здаються далекими від посилок, які мотивували початок цієї роботи з великого перегляду мови. З погляду очорнителя, численні модельні поняття, погано певна семантика й легковагі механізми розширень затрудняють вивчення мови і його застосування в середовищі MDD. Ці реальні проблеми вимагають рішення, але нам не слід дивуватися тому, що ця мова моделювання першого покоління далека від досконалості.
Як відзначають деякі розроблювачі UML, розробка мов моделювання усе ще переживає період становлення. Для прискорення процесу виявлення знань, пов'язаних з MDD, нам потрібна конструктивна критика UML. У цьому змісті UML 2.0 може зіграти важливу роль як явна форма експерименту з мовою моделювання, що може вивчатися, аналізуватися й критикуватися зацікавленими сторонами.
Захисники UML 2.0 відзначають, що в цьому стандарті відбитий кращий виробничий досвід застосування моделювання. Вони говорять про наступні основні вдосконалення:
· Поліпшено підтримку UML як сімейства мов за рахунок використання профілів і крапок семантичних варіацій (semantic variation point), які позначають частини UML, які навмисне залишені без семантики, щоб можна було навантажити їхньою семантикою, обумовленої користувачами.
· Поліпшено виразність моделювання, включаючи моделювання бізнес-процесів, підтримку класифікаторів повторного використання моделювання й підтримку архитектур розподілених неоднорідних систем.
· Зроблено інтеграцію семантики дій (Action Semantics), що може використовуватися розроблювачами для визначення семантики моделей під час виконання й забезпечує семантичну точність, необхідну для аналізу моделей і їхньої трансляції в реалізації.
На думку авторів, що занадто висока оцінка UML і відповідних технологій MDD може бути настільки ж пагубної, як і несправедлива критика. Це може привести до росту очікувань користувачів до недосяжного в цей час рівня. У своїй статті автори намагаються розвіяти хмари реклами, що оточують UML 2.0, і представити обґрунтовану оцінку забезпечуваної цієї версії мови підтримку MDD [10.4].
Похожие работы
... І Моделювання предметної області є одним з найбільш важливих етапів робіт при проектуванні програмних систем масштабу підприємства. У даній курсовій роботі демонструється можливий підхід до моделювання системи обліку слухачів на курсах з використанням уніфікованої нотації, заснований на застосуванні Уніфікованої Мови Моделювання (Unified Modeling Language) (UML), і гармонійно сполучить у собі ...
... реінжиніринг модулів і бібліотек форматів EXE, DLL, TLB, OCX, підтримку CORBA, IDL, ADO, COM, Java. Висновки Результатом виконання курсового проекту є змодельована система бухгалтерського обліку. Моделювання даної системи дозволяє нам наочно продемонструвати бажану структуру і поведінку системи. Моделювання також необхідно для візуалізації і управління архітектурою системи. Моделі допомагають ...
... ГІС може бути дослідною, охоплювати територію певного регіону, базуватися переважно на векторних форматах просторових даних та мати доступ до корпоративної мережі. 1.3 Геоінформаційні системи в екології Становлення екологічного управління і регулювання екологічних процесів вимагає серйозної технічної підтримки і використання сучасних технологій для вирішення задач різного плану і різного ...
... між усіма парами вершин); • алгоритм Йена (перебування k-оптимальних маршрутів між двома вершинами). Зазначені алгоритми легко виконуються при малій кількості вершин у графі. При збільшенні їх кількості завдання пошуку найкоротшого шляху ускладнюється. Тут на допомогу приходить сучасна техніка. Комп'ютерні засоби та інформаційні технології підвищили можливості такого всеосяжного методу ...
0 комментариев